@Chriskmpruitt, are your home folders located on a server?

If your pushing out any DMG's that FEU or FUT's, please check their permissions too.

I was seeing this too, but solved it with just:

sudo update_dyld_shared_cache -root /

based on advice from this thread over at DeployStudio Forums:

http://www.deploystudio.com/Forums/viewtopic.php?id=5383

Thank you guys for the quick posts.

Our home folders are not located on a server.

I have been through our DMGs a few times to check if any have FEU or FUT's. Everything looks good there. If that was the problem, we would see it more consistent and not so "Random"

@Gillaspy I really like that thread, it is exactly what we are going through. There is no known "fix" besides just restarting the machine

I was under the impression that the command was fixing the issue before anyone logged into a newly imaged machine, but its true that I was also giving those computers an additional restart, too, so it would make an interesting test to leave out the restart to see if the command is helping at all…haven't done it that way yet.

I had a same sort of error with the Keychain. After trying to repair it a few times, I recreated my image (updating to 10.9.2) and the issue went away.

@Mike_Meyers and @Gillaspy are you running Active Directory?

@Mike_Meyers and @Gillaspy are you running Active Directory?

Yes, all AD, no OD.

Yes to AD, no to OD.

Hi there,

I just ran into the same issues with OS 10.9.3 and I tried almost everything I could find about this. Last, I tried this on an unmanaged computer with a fresh install and I got the same errors.

"OSX needs to repair your Library to run applications...bla bla"

I figured out some weird permission issues on the users homefolders which are created at the point of login on our Server (Windows Server 2008 R2), where 'Everyone' has delete/deny permissions. I was a little bit wondering about this, so I removed 'Everyone' from the list and applied those permissions to all child objects. By fixing that, I had no issues anymore.

Can't really tell if this is the same problem for you guys because we are using Acronis/GroupLogic ExtremeZip to mount the Shares via AFP from the WindowsServer. Also asked ExtremeZip Support if this is already a known issue with Mavericks, because we had no problems with 10.8.

Our AD client configuration looks like the following:

Active Directory Forest = our.domain.com
Active Directory Domain = our.domain.com
Computer Account = computerName$

Advanced Options - User Experience
Create mobile account at login = Disabled
Require confirmation = Disabled
Force home to startup disk = Disabled
Mount home as sharepoint = Enabled
Use Windows UNC path for home = Enabled
Network protocol to be used = afp
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 = not set
Authentication from any domain = Enabled
Packet signing = allow
Packet encryption = allow
Password change interval = 14
Restrict Dynamic DNS updates = not set
Namespace mode = domain

Maybe anyone else has a similar setup and has some more suggestions regarding this issue.

Thanks & Cheers!

We're having the same problem with Mavericks. We have an all AD environment and we repeatedly get the OS X needs to repair your Library to run applications. This error occurs for new and and old users. Entering credentials to run the repair gives a 30 second window before returning with the same error message.

have you tried the same steps that we did?

Having the same issue here. AD users get the “OS X needs to repair your library to run applications” error, local users work fine. Entering admin credentials doesn’t help.

Instead of mounting AD users SMB share the OS points the home directory to /var/empty.

I haven’t edited the default user template as many seeing this issue have and the update_dyld_shared_cache suggestion doesn’t help.

Oddly, an earlier version of my (monolithic) 10.9.4 image worked fine on new iMacs, when I apply to other machines (late 2013 Mac Pros, late 2013 iMac) it errors. Binding to AD using Deploy Studio plug-in.

This is becoming more unnerving as September approaches.

I tried running sudo update_dyld_shared_cache -root / on the admin side of things, but it didn't seem to help.

I'm at 10.9.4

I also tried a new smb share and made sure the permissions were correct. The problem occurs when the user signs into 10.9.4 - the home directory on the windows server gets partially created, but the permissions are completely wrong.

I have more luck if I have the account login on a 10.8 computer first, and then login on a 10.9.4 computer.

Under 10.9.4, with AD accounts I am seeing better results if the account is generated under 10.9.1 (and later) and not imported from a record generated under 10.9.0 and earlier. Some sort of directory schema change has seemingly occurred to support iCloud Keychain with the release of 10.9.1:

http://support.apple.com/kb/TS5362?viewlocale=en_US&locale=en_US

Unfortunately, following the directions in the article above won't be an option for many multiple user environments and will only help with single-user workstations.

With the AD-based Password change/Keychain update dialog, I am seeing that there continues to be an issue with the "Continue Logging In" button (the OS might complain about no access to various items related to the Keychain), but that "Update Keychain PW" and "New Keychain" work if the directory record was generated by Mavericks 10.9.1+ and not an earlier OSX version (and if the user is correct about what their prior password was for the "Update Keychain PW" button).

We are seeing the same problem. Brand new out of the box 10.9.4 machines. All updates run. AD Only. Bound to AD. I have an access problem while creating the home folder for a user. Home folder should point to windows server 2008r2 share. On the first logon from any new Mac, the access right to the network home is corrupted. It sets up some folders on the server share, but screws up the security on all folders so we have no access to those folders. If I log in as the same user on a 10.6.8 machine, no problems. It creates the folders in their network share home folder and all security is correct.

Testing yesterday I found the same results on an out of the box iMac. I bound to AD using Apple's AD plug-in, restarted, logged in as an AD user and got the same error. Opening a ticket today.

FWIW, I have not seen this with AD mobile accounts & 10.9.x.

I guess there is a package that you're installing that may be causing the issue.

It seems like @jruskey][/url and @kevin5495 are having the same problems that I'm running into. I just made a bit of progress:

I found that an Everyone Deny permission appears within the home directory folder on the server. If I delete this permission on the few folders that are actually created (Library, Desktop, and Documents), then I can actually save files to those folders. Unfortunately the other default folders are still missing (Movies, Music, Pictures, Public).

I think we'll be able to resolve the issue if we can figure out how to avoid having that Everyone Deny permission attaching itself to folders within the home directory. Could this be prevented by modifying the default user profile?

@bentoms this is happening on a 10.9.4 imac fresh out of the box so it can't be related to packages

@jake.snyder, so it looks like your AD homes are located on an SMB share right?

When you say "fresh out the box" do you mean the local admin account on the OS supplied by Apple?

Really not seeing the same issues as you, so it may help if you detailed some more of your setup. Perhaps there is some commonality.

In my case I created the local admin account as part of the AppleSetup wizard. No updates, no packages. The other thing I touched was Directory Utility. Because the AD home directory pointed to /var/empty we're looking at AD now.

@bentoms][/url good call, let me provide more detail

Our AD homes are located on a SMB share (windows 2008 R2). I verified that the permissions on the share are setup exactly the way Apple recommends for Mavericks (I was even sent a custom made video by an Apple engineer detailing the permission and security settings for the share so those should be perfect).

I then took a brand new imac that came with 10.9.4 already installed and signed into a local admin account and then bound it to AD using the mac AD-plugin. I signed out and restarted the computer, and then tried signing in with a fresh AD account that was pointed to my AD home directory share. I can sign in just fine, but I immediately get the “OS X needs to repair your library to run applications" error. I can't save or do much in the environment when it does this.

If I look at the permissions of the newly created home directory for my fresh AD account it looks kind of funny - only the Library, Documents, and Desktop folders were created. I noticed that there was an Everyone Deny permission on each of those folders and when I delete the Everyone Deny permission on each folder (Library, Documents, Desktop) I can actually use the account and save documents. If I log out and back in after those changes, the other typical home directory folders are still missing.

Edit: I should note that I don't have this problem with 10.8.x or 10.7.x

@jake.snyder, yea I don't know. It's not something I do.. & tbh, my "it doesn't happen to me" wasn't helpful. Sorry.

Which Mac OS has this worked on before?

@jake_snyder, Your symptoms are identical to what we are seeing. I have been working on this for 2 days with no luck. Considering go to 10.8.x on the new imacs to see if that fixes the issue.