'logging in to the account failed because an error occured' - UNC path permissions?

New Contributor

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.


Honored Contributor III
Honored Contributor III

@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.

Honored Contributor II
Honored Contributor II

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.

Valued Contributor III

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.

New Contributor

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. 04271fdee63f450594e2437197c6f33c

Setting for this fix include: Joined to domain, with mobile account enabled. Select all Domains to search. Prefer your domain, and add administrator accounts

New Contributor II

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.

New Contributor III

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.