@EliasG, just wanted to share a process I just recently stumbled upon which is currently working for us with AD and mobile accounts. Before I explain, see our working settings below:
Active Directory Forest = ourdomain.com
Active Directory Domain = ourdomain.com
Computer Account = mycomputer$
Advanced Options - User Experience
Create mobile account at login = Enabled
Require confirmation = Disabled
Force home to startup disk = Enabled
Mount home as sharepoint = Disabled
Use Windows UNC path for home = Enabled
Network protocol to be used = smb
Default user Shell = /bin/bash
Advanced Options - Mappings
Mapping UID to attribute = not set
Mapping user GID to attribute = not set
Mapping group GID to attribute = not set
Generate Kerberos authority = Enabled
Advanced Options - Administrative
Preferred Domain controller = not set
Allowed admin groups = OUR_ADMIN_GROUPS
Authentication from any domain = Disabled
Packet signing = allow
Packet encryption = allow
Password change interval = 0
Restrict Dynamic DNS updates = not set
Namespace mode = domainI followed @bentoms instructions for creating an Applescript application to mount the correct network directory for the user logging in and the Launch Agent to run the application automagically.
Initially based on the suggestions here, I disabled the Use UNC path setting via policy given we were getting the same error message that "User cannot be logged in at this time". However, when I tried logging in with several test AD accounts on a freshly imaged machine I kept getting an error saying that "OSX needs to repair your library to run applications".
Looking a bit closer, I noticed that while the test AD accounts were indeed logging in, a local home directory was not being created in the Users folder on the machine. In System Preferences, too, in Users & Groups, rather than seeing a Settings button for the mobile account I was logged in as, it said Create. So it appeared to not be actually creating the local mobile account. It was doing this just fine before I made this change ...
Running a dsconfigad -show in Terminal I realized that there were two pertinent settings related to home directories - one for determining the UNC path and another for actually mounting the network home folder as a sharepoint. While the UNC path is a checkbox option within Directory Bindings on the JSS, the option for mounting the network home folder as a sharepoint is not, oddly enough. So I changed this manually with a dsconfigad -sharepoint disable in Terminal.
After logging in a second time with the previously tested AD test accounts, it did not give me the "cannot be logged at this time" error, it successfully created the mobile account locally on the machine, and the Launch Agent for mounting the logged in user properly mounted the test user's network folder.
Perhaps this is not the same issue you were experiencing, but for us given my tests and results it appeared the issue was not with the UNC path per-se but when both UNC and mounting a user's home directory as a sharepoint were enabled when a user was logging on a machine for the first time.
UPDATED
This did not end up resolving our issue as we previously thought and had tested. We still see the "user cannot login at this time" message.
