Posted on 05-07-2015 03:38 PM
I am Active Directory user logging into a Mac (OS is 10.10.3) joined to the domain. (Single forest, Single Domain/ Server 2012 )
When attempting to log in I receive "logging in to the account failed because an error occurred".
Looking at the Domain security logs I see that the authentication was successful. It appears to be choking on mounting the home directory. (Gut guess).
In my AD account profile I have a homefolder share of relative UNC path serveruser. The absolute path is serverstaffdocsuser.
Question is: can the Mac parse the relative UNC path or is the absolute path required?
I am told that the intermediate "sharepoint" (staffdocs) needs have at least "read" permissions for the home folders to mount. Granting read permissions to staffdocs to "everyone" is a security issue and not a solution.
Posted on 05-11-2015 01:17 AM
@Adrian_Gillies IIRC the Mac users will need the whole path specified in UNC Path.
I'm guessing that actual share is "staffdocs" with the sub folders being person specific.
Posted on 05-11-2015 07:35 AM
Although I don't think I've tested it another way, I'm pretty sure the Mac will only accept server/sharedfolder/subfolder. You can't miss bits out of the path.
Aren't traverse folder and read folder contents separate permissions? You might be able to get away with traverse only.
Posted on 05-11-2015 09:40 AM
We encounter that from time to time when we setup new users. These are things that matter in our environment. When we correct them, users are then able to login on their Macs:
1) fully qualified domain names for the server name in the path. \servername.company.comusersusername works while \servernameusersusername does not. (yes you have to use the windows path form with instead of /. The AD plugin will understand what it means and adjust accordingly.
2) the target folder must already exist on the server. The folder isn't automatically created by the user logging in
3) permissions on their folder must be correct. The exact permissions may depend on your environment but at a minimum, the user needs RW access to the ...username folder
4) on the Mac, make sure you don't have Directory Utility.app set to Create mobile account at login and do NOT Require confirmation. DO Force local home directory on startup disk.
YMMV, but when a login fails with those symptoms, fixing one of these 4 things works every time for us.
Posted on 10-26-2017 04:15 PM
I know networks can vary from enterprise to enterprise, department to department which can cause a break in many different ways when comes to computer systems. I just want to add my fix for this similar situation like this one. Our AD profile settings are to create a network home drive for each employee. For some reason this can break on a given employee when creating their account for the first time on a Macbook. Changing the Network profile Home folder settings to Local Path by setting to any folder on the local drive will create the folder locally instead of to the network. After this change is made you will be able to log into your Macbook with the problematic profile. Look at the attached if this is your problem.
Setting for this fix include: Joined to domain, with mobile account enabled. Select all Domains to search. Prefer your domain, and add administrator accounts
Posted on 02-08-2019 07:03 AM
This just happened to me. Cause was the search domains weren't set. Mac is joined to the AD domain, has a UNC path to the network share for the user, and requires creation of the mobile account without prompting the user. I couldn't log in a new user whose UNC path for the network folder did not have the FQDN for the server name. Bottom line is this appears to be a name resolution issue that happens during the first login that maps the users network home directory. If the Mac can't find the server on which the home directory is shared by its name, this error appears.
Posted on 01-23-2020 07:39 AM
what mmusante said is very much true. The moment I changed the setting for my adapter and added the FQDN into the search domain, the issue resolved itself.