@plawrence

I just tried your robocopy and icacls method and wasn't able to get it login. Do you have a detailed write up by any chance?

I'm getting the "login failed because an error occurred".

@jake.snyder
Hi Jake

Sorry for the late reply, I ran into a few issues with my previous solution, the permissions didn't seem right and it was causing issues with accounts being unable to move items to the Trash.

I am looking to be able to transfer some existing Network Homes from an OS X server across to a Windows Server running Acronis Access Connect (previously ExtremeZ-IP). This has some extra challenges as the home folder that is copied across needs to have its permissions fixed.

Here is a list of my settings that seem to work:

Share permissions
Everyone = read
Authenticated users = change, read
Domain Admins = Full control

On Server Manager, go to File and Storage Services > Shares
Access Based Enumeration = Disabled
Allow Caching of Share = Disabled
Encrypt Data Access = Enabled

Folder Permissions (Security Tab)
SYSTEM = Full Control = This Folder, subfolders and files
Domain Admins = Full Control = This Folder, subfolders and files
Local Server Administrators = Full Control = This Folder, subfolders and files
CREATOR OWNER = Full Control = Subfolders and files only
Domain Users = Read & Execute (Traverse folder, List folder, Read attributes, Read extended attributes, read permissions) = This folder only

Acronis Access Connect Settings
File Server:
Enabled Home Directory Support -> Use Profile Home Directory
Security:
Reset permissions on move (global)
Support UNIX permissions and ACLs -> Support ACLs on all volumes (global)

Volume settings:
Use volume as home directory

rsync exclusions

I have cwrsync installed on the Windows server so I can copy across the existing home folders from the OS X server. Its vital to exclude ~/Library/Containers and the hidden files at the root of the users home folder as I was unable to reliably set the permissions on these files/folders after the content is copied across.

• /*/Library/Containers


• /*/Library/Logs


• //Library/Saved Application State/


• .DS_Store


• .*

Powershell script
I run a powershell script after the folder is copied from the OS X server to remove all the 'bad' permissions and the set the correct inherited permissions from the parent folder.

Import-Module ActiveDirectory



$id = "1234"



#copy user template to new home folder

robocopy e:

sync$id e:homedirs$id /copyall /e /sl /njh /njs /nfl /ndl



#remove bad everyone ACLs

icacls e:homedirs$id /remove:g everyone /t /c /q /l

icacls e:homedirs$id /remove:g none /t /c /q /l

icacls e:homedirs$id /remove:g "Creator Group" /t /c /q /l



#turn on inheritance for new home folder

icacls e:homedirs$id /inheritance:e



#reset inherited permissions

icacls "e:homedirs$id" /q /c /t /l /reset



#set user full control and inheritance on new home folder

icacls e:homedirs$id /grant:r ${id}:"(OI)(CI)(M,RX,DC)" /t /c /q /l



#set user as owner of new home folder

icacls e:homedirs$id /setowner $id /t /c /q /l

Hi all,

I haven't seen this issue on any site before but today it has raised it's head:

10.10.5 built with AutoDMG
NOT Bound to AD - Logged in with local Admin account created with CreateUserPKG

I'll debug and report back if I find the source of the problem.

Hi @Zvordauk ,

We're experiencing the same, in a similar environment to you. Have only just started deploying 10.10.5

10.10.5 built with AutoDMG
AD Bound - via DeployStudio workflow
local Admin account created with CreateUserPKG - installed via DeployStudio workflow
We also have a pkg to customise / modify the default dock, which is also installed via DeployStudio workflow.

Do you 'burn in' your CreateUserPKG in to your DMG? We keep them separate to ensure the default/custom dock is modified before user creation.

Going to re-image a couple of test iMacs with the same workflow, however variations of above will be applied (e.g. roll back to 10.10.4).

What's also interesting is our Downloads folder on the dock for the current user (local admin) is a giant question mark "?". After a repair and reboot the downloads folder is back and all is peachy again.

Our build is doing the same thing. Everything worked great under 9.8 but now it is giving us the ? mark and throwing up messages about repairing our library on first deployment.

Double check the permissions on the home folder for the user you are signed in as. I've found that my admin user is not getting created properly during imaging, and I receive this error. A quick trip out to the Terminal, deleting the contents of the user's home folder and re-creating from the template user, and then finally changing permissions seems to fix it.

    rm -rf /Path/To/User/Home/*

    cp -R /System/Library/User Template/English.lproj/* /Path/To/User/Home/

    chown -R <user>:staff /Path/To/User/Home/

@Zvordauk did you figure this out yet?

Im having the same issues. Created an admin account with createuserpkg and logged in after imaging. I get the pop up: osx needs to repair.

Also, to make sure it was not caused by other packages, i imaged with just: 10.10.5 and the createuserpkg.pkg

I still get this error.

@acorn The home folder for the user is not getting populated from the user template. If you add a post script that does what I listed in my last post, that should fix the issue.

    rm -rf /Path/To/User/Home/*

    cp -R /System/Library/User Template/English.lproj/* /Path/To/User/Home/

    chown -R <user>:staff /Path/To/User/Home/

We have seen this where we have set mobile accounts required, and do not ask, but the user has somehow chosen Do not Create mobile account, and checked the don't ask again box, maybe before the settings took hold? AD environment, we always use mobile accounts.

To fix, I run the following line against the account, replacing USERNAME with the affected user, while they are logged out.

/System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n USERNAME -v

Run as root if using ARD.
I also use this as a script in the JSS that uses $4 and I push that using Remote.

@stevewood
Bingo. Solved my same issue on Monday

Thanks

LSinNY

Was wondering if there's a permanent fix for this issue as we are getting this error on all Yosemite 10.10.5 client. Our staff are logging in with their OD network accounts. As soon as this error comes up, users are no longer able to save, find files or launch some applications.It also asks users to put admin credentials which is not helping at all..So annoying..

Our temp fix was either to logout the user account and reboot the machine and let the user login again until then the error comes back again..

<text deleted>

@stevewood - thanks! this worked perfectly.

@philcebutv

We've been running 10.10.5 successfully using Acronis Access Connect to a Windows SMB Share.

In testing 10.11; seems we're back to the drawing board on network home directories successfully creating via SMB or AFP. Anyone successful with 10.11.x currently? If so, what is your home directory config?

This issue just surfaced on our campus on Macs running 10.11.

We have our Mac computers bound to Active Directory via the Directory Utility and have it set to create a mobile account upon login. Yesterday, I delivered a computer to one of our users -- and when she logged in, she was greeted with the "OS X need to repair your library..." message. I thought this was strange because I had tested this particular machine with 2 different AD user accounts prior to delivery to be sure that it was working. Somehow, a corrupted template was applied to her user folder and she wasn't able to access any folders within her home folder, as well as not being able to run applications. Changing the permissions on the folders by right clicking the folders and using get info didn't work either.

I also attempted to use the script listed above, but unfortunately that hasn't resolved the issue either. Still trying to figure out what is causing the issue, as it's not consistent among our users. It only seems to affect a small number of people with newly imaged computers. So far, we haven't encountered the issue with those who have upgraded from 10.10.

@cesposito

I just had this happen with a local user account.

Ressing the account ACLs with the Reset Password utility from the Recovery Partition didn't work.

So I tried one last thing before just rebuilding the user's account and copying around data.

I deleted the home folder, selecting the "Don't change the home folder" option.

I then renamed the just-deleted home folder to the original name with

sudo mv "username (Deleted)" username

I then recreated the account with the original name & credentials. OS X will use an existing home folder if the names match. Some versions of OS X will ask whether to use the folder, others just use it.

This fixed things right up.

For what it's worth, we've seen this issue when we have a poor network connection. Reimaging on a good, strong network connection seems to resolve the issue here.

It's FEU and FUT's..... Positively!

Ive been through all this and found that certain prefs were packaged by individuals who were logged in as their AD self and bound to AD whilst packaging...

Bearing in mind that the files were actually looking for 'their' home drive.

First thing is to remove all FEU /FUT's in a configuration, Deploy it, and you 'll see no errors..
Then need to go through all those and re-package 'properly'

:-)

@kerouak

Thanks for your suggestion. It ended up being a package that was improperly populating the existing and new user templates. Once we recreated it, it seems to be working fine. Just had to do some process of elimination to see what package was at fault.

We have a policy to fix broken AD bindings by unbinding then rebinding. We do not use a network home location. Oddly, when the policy runs on remote users, it sometimes causes the 'OS X needs to repair your library' message, so it has something to do with the unbinding or binding to AD. Can anyone make any sense of this based on their experience with the issue?

FWIW, I can replicate this under some different circumstances that may or may not be related to folks' posts above.

My environment:
Server 2008 R2 DCs, fully patched up to today.
Server 2008 R2 fileservers, publishing DFS and hosting Homes / Windows Profiles, fully patched up to today.
10.10.5 and 10.11.5 clients.

10.9+ exhibits this issue in various ways.

AD bind, use UNC to derive home - this will result in the above described if users have Full Control. Making them owners and only RW permissions on the fileserver appears to fix this issue. I confirm I get the SID added for Nobody / Deny - for whatever reason, the Mac clients interpret this as the numeric SID and apply the deny rights to all user. I've opted to simply ensure that different file permissions are set, as this is easy to do. This sort of thing is detailed in previous posts. Without the permissions changes and full control left on a network home, symptoms vary by platform - earlier OS X systems get the repair message, while later create subfolders and files in such a way that the odd everyone SID applies to newly created user folders and documents (manifests as folders/files initially creating, then disappearing because once the everyone SID is added, item is no longer readable.)

If I have an AD user with no home set in AD, behavior on Windows logins ends up with a local - which makes sense. No network home - no problem - create local home.

AD bind, use UNC to derive home - login to Mac 10.9+ clients with user that has no home set in AD, system tries to derive a home location and user home ends up in /var/empty.

For testing purposes I have:
- Created AD bind that doesn't use UNC patch to derive home
- Created test image with only AutoDMG base and AD bind with UNC derive
- Created test image with only AutoDMG base and AD bind without UNC derive

These combinations result in the same behavior for users with no home set in AD.

Any production machines with AD bind set to create local account have no issues, no matter which FEU/FUT packages I have added to workflow. Test images have no FEU/FUT items to rule this out, as well.

Feels like buggy AD connector to me or disagreement in spec implementation, but I could be wrong. Would be nice if AD users with no home set would get local.

Seeing this after user is upgraded from 10.10.5 > 10.11.6 using JSS out-of-box upgrade process.

Don't suppose anyone found a fix for this? Seem to see a lot of posts saying its related to AD binding.

Yes, all our Macs are bound to AD. If there's a known issue and a fix can be scripted, all ears. LOL

When I have encountered this in our environment, it's been either AD/Fileserver permissions on the user's home (in the case of network homes) or permissions on specific files in the user template (local accounts, network accounts)

Specifically for 10.10 -> 10.11 upgrades, I had an issue where a locked file was in the user templates and subsequently users that had logged in - 10.5 doesn't care about this at all. 10.11 doesn't appear to like this as much. After unlocking/chflags'ing the file, I no longer had the issue.

@JesseNCSD

Just out of curiosity what file are you talking about?

The users are upgrading themselves, so the User Template is not involved.