OS X need to repair your library

[Chriskmpruitt]

Hello all,

We have been getting this error since upgrading to Mavericks. "OS X needs to repair your Library to run applications. Type an Administrator's name and password to allow this". This happens on a per user base. A user can login and get this error and logoff and get no error. It seems "random" but we know its not. Just cant seem to connect the dots.

If you navigate to ~/library. It says "The operation can't be completed because the item can't be found". But if you navigate through Computer-->Macintosh HD-->Users everything is there, and has full permissions.

Things we have tried that have failed.

1. Fix disc permissions
2. Repaired Keychain
3. Software update to OS X 10.9.2
4. Deleted Login Keychain via script
5. Created a folder in ~/Library/User/keychain @Postimage
6. sudo update_dyld_shared_cache -root / @Login
7. Disabling Keychain Update via script

We are using Active Directory Our Users are Managed, Mobile

Any help would be greatly appreciated

[merc_support]

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.

[martel]

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.

[stevewood]

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/

[ant89]

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

[stevewood]

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

[chris_hansen]

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.

[Nix4Life]

@stevewood Bingo. Solved my same issue on Monday

Thanks

LSinNY

[philcebutv]

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

[gokoudes]

<text deleted>

[ant89]

@stevewood - thanks! this worked perfectly.

[agrosvenor]

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

[cesposito]

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.

[gskibum]

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

[sanaumann]

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.

[kerouak]

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'

:-)

[cesposito]

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

[mapurcel]

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?

[JesseNCSD]

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.

[donmontalvo]

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

[JesseNCSD]

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.

[johnmcnair]

@JesseNCSD

Just out of curiosity what file are you talking about?

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

[JesseNCSD]

@johnmcnair It was a config xml file that pointed users at a server for an app, locked via Finder (or chflags uchg) so that people couldn't modify it unintentionally. File was stored in user's library, with perms 755. Owned by an admin user (FEU/FUT was used previously, and file was from 10.5 template.) which was retained as owner due to lock.

[McKinnonTech]

@JesseNCSD I'm curious to know how you went about finding/fixing this issue?

I've ran into this issue before.
Does the problematic file come up when you verify/repair permissions? And what's the best process to repair the file?

[JesseNCSD]

@McKinnonTech I used the split-halves method for tracking back the package responsible. I had been reading through related threads for this sort of issue, and people suggested permissions/package problems or AD/fileserver stuff. I figured funky permissions in a package was a possible culprit, given that it affected local users too.

Once I identified the responsible package, I repackaged it without the locked file.

Perhaps there was something corrupted with the original package also? I can say for sure that 10.11 does not like copying locked files on creation of user from template - for the existing users that had the problem on upgrade ... got me. Maybe an intersection of two unrelated issues?

[donmontalvo]

@JesseNCSD wrote:

I used the split-halves method for tracking back the package responsible.

Goose bumps...thinking of Conflict Catcher...

[SeanA]

FWIIW (adding some data, though probably not adding any solutions):
One thing I will state from reading this thread (that I think only a few people pointed out): this error is a “general” error message for a behavior that can have a number of causes.

When I have come across the error, the outward behavior was that the home directory was not completely propagated (for example, only Library, Documents, and Desktop). In my experiences, there were no AD mobile accounts in play, just a local admin account.

I am also inclined to recall that I did not have the error in greater numbers because I deliberately introduced an extra restart into the imaging process (no particular reason: I was working under the theory that, since a restart can fix a lot of problems for a computer when it is in a user’s hands, it can also help prevent problems from being creating).

[donmontalvo]

Seeing this in testing out-of-box El Capitan self-upgrade process. Out of curiosity we decided to run some consistency tests to see if we can narrow down the culprit.

To ensure we follow a deliberate/exact testing process we used:

• MacBook Air (128 SSD) for speed
• OOB image of Yosemite (10.10.5) created using Per Olofsson's awesome AutoDMG.
• JSS dev environment 9.92

Dropped the OOB image onto the MacBook Air, created testuser, enabled for SSH. Enrolled it to JSS, scoped it to our El Capitan self-upgrade test policy (cache; then install cached).

After upgrade completes, we log in as testuser, we get the dialog box, and we stop. We SSH in and look for anything in /Users/testuser/Library that isn't owned by testuser and found some stuff that was put there by vanilla third party package installers (that did not present any issues in testing/deployment):

bash-3.2# find /Users/testuser ! -user testuser
/Users/testuser/Library/Group Containers
/Users/testuser/Library/Logs/FlashPlayerInstallManager.log
/Users/testuser/Library/Logs/ReceiverInstall.log
/Users/testuser/Library/Preferences/com.apple.SetupAssistant.plist
/Users/testuser/Library/Preferences/com.jamfsoftware.selfservice.plist
bash-3.2# ls -l /Users/testuser/Library/ | grep Group
drwxr-xr-x   3 root      staff   102 Sep 10 01:56 Group Containers
bash-3.2# ls -l /Users/testuser/Library/Logs | grep FlashPlayerInstallManager.log 
-rw-r--r--  1 root      staff   336 Sep 10 00:38 FlashPlayerInstallManager.log
bash-3.2# ls -l /Users/testuser/Library/Logs | grep Receiver
-rw-r--r--  1 root      staff  1583 Sep 10 02:00 ReceiverInstall.log
bash-3.2# ls -l /Users/testuser/Library/Preferences | grep com.apple.SetupAssistant.plist
-rw-------   1 root      wheel    343 Sep 10 02:36 com.apple.SetupAssistant.plist
bash-3.2#

We stopped there and restored the MacBook Air to OOB state for another test.

This time we used a Before script in the El Capitan self-upgrade Cache policy that looped through all user accounts to recursively chown each /Users/$user/Library folder to ensure its owned by $user. Ran through the upgrade, and bingo, no prompt to repair Library folder on login.

Ran through the first test again to confirm, got the Library permissions error.

Ran through the second test (with fix) to confirm, did not get the Library error.

What does this mean? It means I need to get off my butt and enjoy the weekend, and come back to tackle this on Monday. :)

Planning to test again on Monday, responding to the dialog box to see what actually gets/got repaired.

Don

[donmontalvo]

Well, recursively setting /Users/testuser/Library to owner testuser fixes wrong ownership except for one file that keeps setting itself to root owner...

bash-3.2# find /Users/testuser ! -user testuser
/Users/testuser/Library/Preferences/com.jamfsoftware.selfservice.plist
bash-3.2# ls -l /Users/testuser/Library/Preferences/com.jamfsoftware.selfservice.plist
-rwxr-xr-x  1 root  XXXXDomain Users  573 Sep 11 17:02 /Users/testuser/Library/Preferences/com.jamfsoftware.selfservice.plist
bash-3.2#

We'll get a ticket open to support in the morning.

Don

[donmontalvo]

FYI, we confirmed on several dry runs today, that /Users/testuser/Library/Preferences/com.jamfsoftware.selfservice.plist does not cause the permissions issue.

Although curious why it has to be owned by root. We'll open a ticket to see if this is a defect.

Don

[macsadmin]

Has anyone figured this out?

After migrating from MacBook on Sierra which is binded to AD is having the same issue.

I haven't come across this on El Capitan, it only seems to happen to Sierra.

[apizz]

@macsadmin I just confirmed this for us as well when imaging a fresh machine. Our JSS is a bit out of date (9.82) and did it with both 10.12.0 and 10.12.3. IIRC, in my very prelim tests with Sierra on this same JSS version I did not run into this issue. Only now.

Very minimal image, so I don't think it's software, but going to keep testing.

[apizz]

When I login with a local user that gets created post image I get no prompts about needing to repair Library permissions.

When I login with an AD account I get the error. Running an ls -lah on the AD user's ~/Library folder I see that rather than our standard DOMAINDomain Users group as the primary group, I see sys as the group. We do a few things in the User Template, but I confirmed that both the stuff we add and/or modify as well as the default Mac settings are all set root:wheel.

So this appears to be a macOS AD group issue?

[JesseNCSD]

We do a few things in the User Template, but I confirmed that both the stuff we add and/or modify as well as the default Mac settings are all set root:wheel.

Default User templates are not used when users log in with directory credentials via default AD bind. If you enable "Mobile Account" creation at login, it will apply the Default User Template - but this results in a local cache being made of the network account, and you have to potentially deal with how a mobile account operates. (Unless I'm confused.)

This difference can result in different behavior between local user/"true" mobile/mobile with forced local home and network home only logins.

If you're having permissions issues with network home, non-mobile accounts - I'd look at how your permissions are defined on the fileshare and potential issues that may arise.

When I moved into later versions of macOS, I found I had problems in our environment and items being set with improper permissions due to issues with SMB and permissions creation on our Macs vs Windows fileshares.

[apizz]

@JesseNCSD We do create Mobile Accounts at login. We don't use network homes.

[JesseNCSD]

@aporlebeke Funky you're seeing no issue on locals and issues on mobiles! Does the account structure get fully created for newly logged in mobile accounts?

[apizz]

Sure enough, it appears it did not create the Mobile Account at all or the home folder.

[apizz]

So, I was able to resolve this for us! Hooraaaaay! Details below. Hope this helps other people.

The short and sweet version:

The configuration profile that configured our login window had the “Combine available workgroup settings” checkbox unchecked. Pushing out an updated profile and changing just this setting stopped the Library repair message from appearing. Ultimately, this appeared to be a workgroup setting issue with the account I was using (my own), as I am a part of many different groups and nested groups.

The detailed version:

After closer examination I noted a couple things:

1. The account I was initially testing this with was my own AD account, for which I am a part of many more groups and nested groups than a standard user would be in AD. Without making any changes to my test computer, I tried logging in with two different basic testing accounts and did not have the same Library repair errors as I did with my own account and confirmed that cached mobile accounts were created. I wiped and reimaged this test computer again and got the same results.

2. When I was logging in with my own account, I would get a Workgroup popup message similar to the one below, which I had not seen before. I did not see this message when I logged in with our two basic testing AD accounts. Choosing either Continue or Remember and continue when I attempted to login with my own account did not stop the Library repair message from appearing.

I had a hunch this might be something profile-related and checked our configuration profiles. I noted in the Login Window payload under Access that neither the Ignore workgroup nesting or Combine available workgroup settings were checked.

To test, I cloned this profile, scoped it to our test machine, and checked the Ignore workgroup nesting while leaving the combine setting unchecked. This did not stop the message from appearing for my AD account nor created a cached mobile account.

Then I tried checking the “Combine available workgroup settings” and leaving the ignore nesting setting unchecked. Unlike my first test, this change stopped the Library repair message from appearing and successfully created a mobile account for my own AD user!

We are currently still on 10.11.6 and this was not previously an issue.

So it appears that for us this was a niche-case workgroup issue with an AD account that was part of many groups and/or nested groups.

[sjha967]

Suspecting a permission issue, I was hoping to run the disk repair permissions option in Disk Utility, however I am running mac os Sierra and that feature has been removed. My only alternative was to reinstall mac os — so I did. Unfortunately, this did not fix the issue either — likely because the reinstall intentionally does not mess with existing home directories.

Running out of options, I decided to fix my home directory permissions via login with root user or other administrator profile.

When I rebooted, I was happy to see that my profile was returned and the pop up was gone. Root cause was the installation of VMware Fusion :)