Jamf Nation, hosted by Jamf, is a dynamic and knowledgeable community of Apple-focused IT admins and Jamf Pro users. Join us in person, in October, for the annual Jamf Nation User Conference (JNUC) to discover new and better ways to manage Apple devices.

# OS X need to repair your library

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

SOLVED Posted: 3/31/14 at 2:24 PM by bentoms

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

SOLVED Posted: 3/31/14 at 4:04 PM by SGill

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

sudo update_dyld_shared_cache -root /

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

SOLVED Posted: 3/31/14 at 5:29 PM by Chriskmpruitt

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

SOLVED Posted: 4/1/14 at 9:54 AM by SGill

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.

SOLVED Posted: 4/1/14 at 1:45 PM by Mike_Meyers

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.

SOLVED Posted: 4/3/14 at 11:04 AM by Chriskmpruitt

@Mike_Meyers and @Gillaspy are you running Active Directory?

SOLVED Posted: 4/3/14 at 11:05 AM by Chriskmpruitt

@Mike_Meyers and @Gillaspy are you running Active Directory?

SOLVED Posted: 4/3/14 at 11:08 AM by SGill

SOLVED Posted: 4/3/14 at 12:00 PM by Mike_Meyers

Yes to AD, no to OD.

SOLVED Posted: 6/12/14 at 2:23 AM by fulm

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! SOLVED Posted: 7/29/14 at 9:49 AM by jake.snyder 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. SOLVED Posted: 7/29/14 at 2:41 PM by Chriskmpruitt have you tried the same steps that we did? SOLVED Posted: 8/4/14 at 10:19 AM by kevin5495 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. SOLVED Posted: 8/4/14 at 12:10 PM by jake.snyder 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. SOLVED Posted: 8/5/14 at 4:05 PM by SGill 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). SOLVED Posted: 8/5/14 at 7:28 PM by jruskey 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. SOLVED Posted: 8/6/14 at 8:21 AM by kevin5495 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. SOLVED Posted: 8/6/14 at 8:25 AM by bentoms 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. SOLVED Posted: 8/6/14 at 8:29 AM by jake.snyder 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? SOLVED Posted: 8/6/14 at 12:07 PM by jake.snyder @bentoms this is happening on a 10.9.4 imac fresh out of the box so it can't be related to packages SOLVED Posted: 8/6/14 at 12:26 PM by bentoms @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. SOLVED Posted: 8/6/14 at 12:32 PM by kevin5495 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. SOLVED Posted: 8/6/14 at 12:38 PM by jake.snyder @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 SOLVED Posted: 8/6/14 at 1:15 PM by bentoms @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? SOLVED Posted: 8/6/14 at 1:30 PM by jruskey @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. SOLVED Posted: 8/7/14 at 10:04 AM by agrosvenor @bentoms, this has worked on 10.8.5 and all previous versions \- @jruskey, \- I suspect rolling back to 10.8.x will work \- it did for us, but we are still trying to get 10.9.4 operational for this upcoming semester [for reference, I work in the same department as @jake.snyder ] SOLVED Posted: 8/7/14 at 11:02 AM by jruskey @bentoms][/url][/url][/url, @agrosvenor][/url][/url, I can't roll back. These all shipped with 10.9.x and not matter what I try, it won't allow 10.8.x to install. So, back to the fun. SOLVED Posted: 8/7/14 at 11:27 AM by jake.snyder @jruskey that's really unfortunate, @agrosvenor and I haven't made any progress in the last 24 hours SOLVED Posted: 8/7/14 at 12:42 PM by jake.snyder we were assigned an Apple engineer from Apple Enterprise Support this morning so we'll see if we can make any progress once they reach out to us SOLVED Posted: 8/7/14 at 1:06 PM by jruskey @jake.snyder, There is the obvious problem of the home directories not mapping. We are all experiencing that. Let me know what they say. I have confirmed if I use AdmitMac from Thursby, my home drives mount correctly. Now, that isn't the solution since it is about$70/machine for that plug in. However, even if we paid the money for that, the other issue is that no network users can log in after the Mavericks machine goes to sleep. You either have to reboot or log in with a local account, log out and then network accounts are fine. Are you also lucky enough to have this other problem as well?

Please let me know what your apple engineer says. Thanks so much.

SOLVED Posted: 8/8/14 at 9:46 AM by Olivier

We also have our AD homes on a SMB server, but quite frankly, I don't think this is the root cause. Same for the udld force cache.

I also have seen couple of times this since 1 or 2 years now, and the only thing I could notice when pb happens, is a mismatch between the UID in the Directory service record for that user (dscl . -read /Users/yourADuser ) and the UID seen on the user's Library folder on disk (run a simple "ls -lnr /Users/yourADuser/Library").
Remember that OSX silently checks, and updates if needed, any user's record entries during session logon (99,999% of the time, there is obviously nothing to update but...) : this is what maybe created the permissions mismatch and the annoying popup.

SOLVED Posted: 8/8/14 at 9:59 AM by jruskey

This happens with old users, brand new test users created, etc. It is every network user. It is only on 10.9.x. Any other versions from 10.6.8 and up, no issues whether new or existing user.

SOLVED Posted: 8/8/14 at 5:08 PM by ebioit

We are seeing the same error on our older classroom computers. Our Mid 2009 MacBook Pros and Early 2009 iMacs prompt us after imaging: "OSX needs to repair your library in order to run applications..." Furthermore they fail to bind to the active directory at imaging time. If we log into the Local Admin and repair the library when prompted \- we are then able to manually bind the computer to the AD furthermore, the required applications work for the Local Admin and AD users.

Our newer computers (Late 2009 +) do not display the repair message and bind to the AD. Imaging is a flawless process on these iMacs and MacBook Pros.

We are using 10.9.4 build 13E28 images created from AutoDMG \- its quite the predicament, we may end up imaging our classroom computers with 10.8 again. This is the first time I've experienced the age of a mac producing different imaging results in such a manner.

SOLVED Posted: 8/11/14 at 6:18 PM by jruskey

@jake.snyder, has your apple engineer been able to resolve anything as of yet?

SOLVED Posted: 8/11/14 at 7:09 PM by jake.snyder

@jruskey not yet, they've been getting pretty deep into logs and verifying what we're seeing, I'm hoping for a resolution soon. I'll post on here as soon as I get anything.

SOLVED Posted: 8/11/14 at 7:14 PM by jake.snyder

@ebioit have you tested brand new accounts with network home directories on 10.9.4? I'd be curious to see if you have success or not.

SOLVED Posted: 8/12/14 at 7:19 AM by michaelhusar

I saw the same things with old user accounts from 10.8 when we moved to Mavericks. We saved the work-data and made a new account/library.
Base OSX 10.9.4 is from AppStore and packed with Composer.
Before that we were also exploring the everybody-deny-delete-road: We removed that ACL from the user template and wrote a launch agent for removing. But OSX "repairs" that \- so you always end up with files with everybody-deny-dele-ACL in the Library. The only remedy we found was ExtremeZ-IP (handles the ACL correctly).

SOLVED Posted: 8/13/14 at 8:30 AM by jake.snyder

@michaelhusar @jruskey I just downloaded the trial of Acronis ExtremeZ-IP and can confirm we didn't have account corruption when using AFP, but it still only created three folders (Desktop, Documents, Library).

I'm still waiting for next steps from the kind folks at Apple. They are very detailed and thorough but I'm afraid I won't have time to wait for their solution.

I'm preparing two options for the scenario where Apple can't figure it out in time for the start of my school year:

1. Roll back to 10.8.5 on iMacs that will support it and run forced local home directories on our 20 brand new imacs \- less than ideal for those that will need to use these computers.
2. The other option is to implement Acronis ExtremeZ-IP, but the unlimited client licensing is expensive for a technology that Apple is moving away from.

Michael \- Do you have instructions or tips for how to setup ExtremeZ-IP? I followed the instructions I found for version 3, but they seem slightly dated. It seems to be working except that its only creating 3 folders.

Thanks all. If Apple support comes through, I'll post a follow up here.

SOLVED Posted: 8/13/14 at 8:40 AM by jruskey

@jake.snyder \- I understand your frustrations. What we did with the labs that can't be downgraded is similar to option 1. We created a generic local login since it is in a lab. Then, we have Aliases on the desktop that allow users to connect to their home directories, shares, etc. Not ideal, but didn't have a lot of options.

I did use AdmitMac from Thursby and it works very well. I think education pricing is about $132 per license($110 for the license and $22 for support). The more licenses you purchase, you get volume pricing. It works very well, but it is expensive. We ended up purchasing a 5 pack for the machines that we are rolling out to staff that won't be in labs. If you hear anything from apple, let me know. Thanks so much. SOLVED Posted: 8/13/14 at 8:46 AM by michaelhusar sure: Security: Permissions: NoCheck Allow Mac clients to change permissions Check Reset permissions on move Check Support UNIX permissions Check Support ACLs on all volumes Check(ed) Show only accessible Folders \+ Files Directory Services: Check Global Catalog: We have a AD-Account for that Search: Check Index volumes for search Other stuff is default/no game changer I guess. At the first sync I also see only 3 folders \- it seems to build up incremental \- as the user needs the stuff. I use a Profile Manager Config to set what gets synced. I use the defaults of "mobility" on \~/Library with these exclusions \~/.SymAVQSFile \~/Documents/Microsoft User Data/Entourage Temp \~/Library/Application Support/SyncServices \~/Library/Application Support/MobileSync \~/Library/Caches \~/Library/Calendars/Calendar Cache \~/Library/Logs \~/Library/Mail/V2/MailData/AvailableFeeds \~/Library/Mail/V2/MailData/Envelope Index \~/Library/Preferences/Macromedia/Flash Player \~/Library/Printers \~/Library/PubSub/Database \~/Library/PubSub/Downloads \~/Library/PubSub/Feeds \~/Library/Safari/Icons.db \~/Library/Safari/HistoryIndex.sk \~/Library/iTunes/iPhone Software Updates IMAP- Exchange- EWS- Mac- and also added those: \~/Library/Developer .fstemp \~/Library/Safari/LocalStorage \~/Library/Mail/V2 \~/Dropbox \~/Library/Mobile Documents \~/Library/Messages \~/Library/Application Support/AddressBook/Sources \~/Documents/Microsoft User Data \~/Documents/Microsoft-Benutzerdaten \~/Library/WebKit/LocalStorage in future probably \~/Library/Containers, \~/Library/Accounts, \~/Library/IdentityServices, \~/Library/iCloud One other thought: Do you use a Win2012 Server? I had to make sure the SPNs are all low letters (!) otherwise Kerberos does not like it and there are on and off sync problems. SOLVED Posted: 8/13/14 at 9:32 AM by jake.snyder @michaelhusar thanks for your quick response! My ExtremeZ-IP settings were fairly close to yours except for the "reset permissions on move" and "show only accessible". I made adjustments to my settings to match your settings. It's good to know that you're seeing the three folder thing initially as well. I will be using folder redirection mostly for Adobe related cache. We're using Windows Server 2008 R2, but the SPN is already lower case. Good to know though! Thanks again! SOLVED Posted: 8/13/14 at 10:34 AM by dhandy @jake.snyder Jake, I've been following along with the same issue, and eagerly awaiting the response from your Apple engineer. I also have Everyone ACLs getting explicitly set on new Windows Server 2008R2 home folder items by Mavericks 10.9.4. My only workaround at this point, has been to build my own "User Template", by logging into Mavericks as a local user, logging out, then ditto'ing the created local home folder up to the server. I then strip off the everyone ACLs: icacls U:\Students\username /remove:d everyone /t /c /q /l on the home folder, then grant full control to the user. Interestingly, any folders manually created by the user aren't handicapped by these everyone ACLs, but any folders/items created by Mavericks OS processes are. Those user home folders that I migrated over from an Xserve file server don't have this problem. SOLVED Posted: 8/15/14 at 9:59 AM by jake.snyder I just got this update from Apple, but haven't tried it yet: After some more testing I have been finally able to reproduce the reported issue and found a solution in order to address this behaviour. Could you please check in your Home share properties under advanced if you have a Feature enabled called: "Enable access-based enumeration" ? If this is correct please remove the nsmb.conf ($ sudo rm /etc/nsmb.conf ) global Configuration again and disable this feature.

After this has been disabled create one more Test user, restart the Client and try to login with this new user account after restarting.

SOLVED Posted: 8/15/14 at 10:16 AM by dhandy

@jake.snyder

FWIW, access-based enumeration is off for me, and has never been enabled on the new share points I set up on a new server.

Here's my scenario to recreate the issue (sorry for the length):
----
Active Directory/Open Directory bindings
Student Network Home folders on Windows Server 2008 R2
Mavericks 10.9.4 clients, OD server is OS X Server 3.1.2

Steps to recreate:

Create a new user in AD.
Active Directory creates the empty home folder with the user's name, when path entered in Home Directory attribute in AD. (Without this, user login denied.)

Permissions on empty home folder automatically set with new user in Full Control over subfolders and files, and System and Administrators Full Control propagated down by inheritance from parent share point.

Then, first login by user on Mavericks client, Mavericks populates the empty home folder with a Spotlight folder, Library and Downloads folder (no use of /System/Library/User Template)

"Downloads" inherits home folder permissions, and sets explicit Everyone Deny Delete this folder only.

Library also inherits home folder permission, and sets explicit Everyone Deny Delete this folder only.
*ALSO sets "S-1-5-88-3-448" Deny None this folder only.*
*** (This SID translates to Everyone) \- This is where problems start.

Client user login experience shows "Keychain Not Found". Attempts to Reset to Defaults repeats twice. Then error "Home folder for user isn't located in the usual place or can't be accessed" User can't get to home folder at all.

Logout, and user can't login again. ("Unable to login at this time.")

If I run the following command, to remove the "Everyone" ACLs on the Windows Server, the user can login again.

icacls U:\Students\username /remove:d Everyone /t /c /q /l

Home folder now accessible to the user, with no keychain error. Desktop folder now available (permissions set again with Everyone Deny Delete). No Documents, Pictures, Movies, etc. yet.

Various other Library sub folders and Library items are created by the client OS, but permissions on these items are all set to explicit "Everyone Deny Delete this folder only" and "S-1-5-88-3-448" Deny None this folder only" on everything.

The user can create a folder in their home folder, but there's no "everyone permissions" set, and looks normal.

*My current workaround is to create the user's home folder as a local home folder, login, logout so it gets populated, then ditto this local home folder to the server. I then delete the everyone ACLs, and grant the user Full Control over their server home folder.*

Hopefully this is aligned with the symptoms you're seeing. Otherwise, I'm in the wrong thread.

SOLVED Posted: 8/15/14 at 10:55 AM by jake.snyder

@dhandy

I'm seeing something a bit different than you, but the issue is related. Perhaps its because I'm not using Open Directory. My home folders are created on first login too.

SOLVED Posted: 8/15/14 at 10:57 AM by jake.snyder

Significant progress today: My environment seems to be working with Access Based Enumeration off and forcing SMB1 on each client.

In order to enforce SMB1 on a mac client:

1. Create the Global Config: $sudo -s$ sudo echo "[default]" >> /etc/nsmb.conf $sudo echo "smb_neg=smb1_only" >> /etc/nsmb.conf 2. Restart the OS X Client 3. create a new AD Test user 4. Login and check if the issue still persist SOLVED Posted: 8/15/14 at 11:01 AM by jake.snyder I'm still seeing these permissions with the above changes, but I'm still able to write: Deny S-1-5-88-3-448 None <not inherited> This folder only Deny Everyone Delete <not inherited. This folder only SOLVED Posted: 8/15/14 at 11:29 AM by dhandy Forcing SMB1 Only now allows login and creation of Library folders, so that's a great step! But there's no observance of the /System/Library/User Template for new home folders. (But this may always have been true in the auto-creation of new SMB home folders \- I don't know.) For instance, launch iPhoto on a new home folder, and it can't create its own database due to the absence of a Pictures folder. Guess we can't have everything. SOLVED Posted: 8/15/14 at 1:51 PM by jake.snyder @dhandy I noticed that those folders eventually get created, not sure why its not happening all at once like it used to though SOLVED Posted: 8/15/14 at 1:51 PM by jake.snyder Adobe CC is working on network homes, which is huge. Notes and Photo Booth do not work. SOLVED Posted: 8/15/14 at 2:50 PM by jake.snyder Apple support engineering can replicate these issues and they been elevated to product engineering. That's all she wrote folks. Good luck! SOLVED Posted: 8/15/14 at 2:54 PM by kevin5495 Thanks for pushing this. My understanding is we may see something in 10.9.5. SOLVED Posted: 8/15/14 at 7:17 PM by michaelhusar To let you know we are on the same page: I was also setting my clients manually to SMB1 and seeing the (so called) "ghost-user" S-1-5-88-3-448 And iPhoto also prompted me for a new Photo-Library Good to know I am not alone with these observings \- also Thanks from my side for pushing this. We invested in ExtremeZ-IP because of this "feature" \- would be great to operate without these extra costs. SOLVED Posted: 8/18/14 at 12:43 AM by joe.farage Hi all, we also had almost all the problems you describe here. Last year we used Remote Home Directory (AD and Windows Server or NetApp) for our schools. We had to switch back to Local accounts. We had many problems: \- permissions corruptions => user cannot login; even if we had a script to correct permissions on Windows Share there was still lot of problems. \- some apps don't work using Remote Home Dirs, need to much hacks.. sometimes nothing works \- User Template never worked with Remote Home Dirs => plists had to be install with Login Hook at first login \- For many users it took so much time to login (more than 2 mins) We decided to come back to Local Home Dirs (using AD) and of courses users were not happy to lose this functionality. SOLVED Posted: 8/19/14 at 4:10 AM by eWhizz The problem is with the \~/Library/Containers folder in your Network homes. This folder and its contents are not being created with the correct permissions. This folder needs to be writeable by more than the User that owns it. There are processes like soagent and others that seem to need to write things in this folder, but don’t do it as the user. They may well do it as root, but this is no good for Network homes. I too have yet to find a definitive answer to this problem, but hopefully this little bit of information helps. The problem was quite prevalent with 10.9 and 10.9.1 with many improvements to this with 10.9.2, however I am still seeing the issue occasionally. Removing the Containers folder and recreating it with quite open permissions seems to at least work around the issue for now. This may well be why people that are editing the User Template are seeing this problem the most. SOLVED Posted: 8/19/14 at 7:53 AM by jake.snyder We're building out the DUT on an iMac and then putting it onto the server in each users home directory because its not being created as expected. This allows us to setup the Finder and Dock the way we want it. In AD, we setup the profile as Z: //SERVERNAME/sharename$/%username% which creates the initial folder we need to copy the DUT into.

We haven't run into the \~/Library/Containers issue yet. I haven't looked for it either. What does this prevent or what issues does this cause?

We redirect \~/Library/Caches, and remove this folder from the DUT. This is primarily to avoid the Adobe caches passing over the network.

Last year we had a few permission issues scattered throughout the year (maybe 4-5). In those instances, we just added a 2 to the end of the home share path and then copied over the files they needed. Not ideal, but it worked on the fly.

SOLVED Posted: 8/19/14 at 1:23 PM by thall

I finished building my very first image using composer and casper admin. 10.9.4 for iMacs. I felt great about my accomplishment and then started logging into some network accounts and ran into this same issue. I captured the OS image from a manual install, then target booted the iMac.

My trouble is that I am not mapping the users to any servers. Is there something I can reconfigure to fix this? If I am reading the posts right it seams to be a mapping issue.

Thanks-

SOLVED Posted: 8/21/14 at 12:05 AM by eWhizz

Let’s get this straight. The error is because the system or agents running in the background can’t write correctly to a users’ Containers folder.

The “Containers Issue” IS THE ISSUE that causes the “Library needs repairing” errors.

Make sure the permissions on that folder are correct. i.e. fully writeable by the user and others.

If you are creating a User Template (which I think you shouldn’t be) then make doubly sure the permissions are correct, all the way through that folder.

Also a lot of the apps that use the Containers folder (i.e. those that are ‘Modern’ and correctly use and specify their Sandbox requirements) will create symlinks to other folders within your Library and Home folder. These folders probably need to exist.

They will be (amongst others)

Pictures
Music
Movies
Desktop

etc

If these folders in particular are being redirected elsewhere, then that could be the root of the problem.

This again is the reason why a User Template shouldn’t be used for Mavericks. Too difficult to keep track of all the symlinks etc within the Containers folder.

Still no definitive answers with my post here, but hopefully helps someone else find that answer to their particular cause of the “OS X needs to repair your Library" messages.

SOLVED Posted: 9/2/14 at 11:29 AM by TheSeans

I just started seeing this. I deployed out 120 new macs with my 10.9.4 image. Everything was perfect for 2 weeks then my users started getting these errors.

The strange thing is it's fairly random. I can't find any differences in package deployment or profiles on ones that are having and issue and the ones that don't.

SOLVED Posted: 9/13/14 at 8:15 AM by Swift

Our setup \- Mac clients bound to AD, with network home directories located on a MS Server. No Mac Server, no OD, no symlink redirections of cache folders etc. No special setup.

This is what appears to be happening...

When a user logs in, the Mac OS does some kind of sanity check on the users home directory.

If a users home directory fails this sanity check, the OS will attempt to create missing files and folders, and assign what it thinks are the appropriate ACLs.

If you have your user home directories on a MS Server, these explicit ACLs appear to prevent the user from accessing the home directory.

Examining the properties of users home directory folder shows the explicit ACL

0: group:everyone deny delete

The result of these explicit ACLs, is that the user is prevented from seeing his home folder.

---

OK, you now have two options.

1. Setup your shares with permissions that prevent the average user from modifying ACLs.
2. Create the files and folders that the OS expects to find in the user home before the finder loads. This can be done in a login script.

---

Option 1:

The fact that the troublesome ACL has been successfully added, is a consequence of CREATOR/OWNERs being able to add or remove ACLs on files and directories. This seems to be standard practice.

Most shares are set up similar to what is described in TechNote http://technet.microsoft.com/en-us/library/cc736916(v=ws.10).aspx

If you have a choice, I would suggest preventing normal users from modifying ACLs. This means deviating from the suggested TechNote norm which might have other consequences.

I have to preface the following with the suggestion that If you are going to try this, do it on a test share first!

The following is taken from my notes from a while back \- when I had my own MS File Server dedicated to our Mac users. Our Mac users now make use of the organisations PC shares, which are maintained by a different team, so I have to admit that I haven't tried this for a while.

-- Firstly, modify the Share level (SMB) Permissions for the Share (default shown in TechNote Table 7.13)

Right-Click on the share > Properties > Advanced sharing > Permissions > Add...

If you have any file admin groups that need to modify ACLS, you should add them here with the same permissions as Administrators above.

-- Next, modify the "Creator Owner" permissions on the Share (default shown in TechNote Table 7.12)

Right-Click on the share > Properties > Security...

Creator Owner: Subfolders and files only \- everything EXCEPT: Full Control, Change permissions, Take ownership

These settings will prevent normal users from modifying ACLs, nipping the troublesome ACLs in the bud.

---

Option 2:

Since I do not control our MS File server(s), I had to go for this option.

It appears that if you create the following files and folders before login, things will be OK.

/Documents/
All the folders and files in /System/Library/User\ Template/English.lproj (minus the ACLs!)

The file loginwindow.plist appears to be important. This file must exist, otherwise the home folder will fail the sanity check, and the system will re-apply the troublesome ACLs.

I am unsure as to whether the OS inspects the contents of this file as part of the sanity check, I might find out the hard way when I update to 10.9.5. On my 10.9.4 clients loginwindow.plist contains the following:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict> <key>BuildVersionStampAsNumber</key> <integer>27526016</integer> <key>BuildVersionStampAsString</key> <string>13E28</string> <key>SystemVersionStampAsNumber</key> <integer>168363008</integer> <key>SystemVersionStampAsString</key> <string>10.9.4</string>
</dict>
</plist>

I create all these files and folders in my login script.

This appears to have fixed the issue for me.

---

Whatever option you choose, you will still need to jump on the MS Server and fix the permissions on the home directories of all the locked out users \- which is a big pain.

SOLVED Posted: 9/17/14 at 5:43 AM by michaelhusar

@Swift
Thank you for the interesting analysis. Did you also try to use portable home sync to create the necessary folders? Or does it kick in too late?
...I was thinking to put the loginwindow.plist and the other necessary folders in the User Template of the Base Image and then set the mobility configuration profile to "use local template" for creation....
But I am afraid during the "life" of the user home folder there will be a lot more files with ACL everyone deny delete...

SOLVED Posted: 9/23/14 at 5:30 AM by mark.mahabir

Would you be able to share any details re those official permission/security settings recommendations for Mavericks?

SOLVED Posted: 9/23/14 at 8:22 AM by dhandy

Following up on my earlier posting, now running clients with Mac OS X 10.9.5 against Active Directory and Windows Server 2008R2 network home directories:

I made my own "user template" by creating a local user account on a Mac, then logging in, logging out so that the home folders, Library prefs, etc. get initialized. I copied that home folder up to the Windows Server to use as a template when creating new users. (I delete the contents of the Library/Keychains folder in the template.)

After creating a new user in Active Directory, I then populate their new home folder using my "Generic" template.

robocopy \Users\Generic \Users\studentUser /copyall /e /sl
\# copy empty folders and symbolic links

I then strip any wacky everyone ACLs that might have been created by Mavericks. (I also run this command nightly on all users on my server.)

icacls \Users\studentUser /remove:d everyone /t /c /q /l

I add a user's Full control AND Inheritance ACL on all folders in their home folder:

icacls \Users\studentUser /grant:r studentUser:(OI)(CI)F /t /c /q /l

I then set the owner to be the studentUser. (Helps? I don't know, just feels like I should.)

icacls \Users\studentUser /setowner studentUser /t /c /q /l

Logging in, and logging out users under Mavericks has worked better. (I still run that nightly command above on the server to strip those everyone deny ACLs that crop up.)

I am setting clients to use SMB instead of SMB2, by creating the /etc/nsmb.conf file on clients...
[default]
smb_neg=smb1_only

FWIW, my Advancing Sharing Permissions for the share point is set to give Everyone Full Control. (When set to use SMB2, I did try just giving everyone Read/Write, and that removed the Everyone Deny ACL problem. But users of Apple Pages and other Apple apps started seeing multiple copies of documents appear as they saved/revised/saved (old versions weren't getting auto-deleted.)

So, downgrading to SMB and the steps above seem to be working.

Next problem to deal with... Mobile User FileSync under SMB flags uploaded documents as Hidden on the Windows Server. Users are prevented from seeing those files if the log into other Macs as regular network users, or use Connect To Server to get to their server home folder.

SOLVED Posted: 10/14/14 at 5:50 PM by jruskey

@jake.snyder did your apple engineer ever give you a manageable solution to resolve this or is it basically to wait for Yosemite and hope it is fixed?

SOLVED Posted: 10/17/14 at 12:40 PM by anderb54

Well, unfortunately upgrading to Yosemite didn't solve this issue either. This is really a bummer. Our students use the macs to do things like iMovie. Before Mavericks, all of their files would be in there server home directory and they could edit on any mac on the network. If anybody finds a fix, please post!!! Really need this working!

SOLVED Posted: 10/21/14 at 9:37 AM by anderb54

I'm finding that a work around is simply creating the Pictures, Movies, and Music folders in the network home folder (as those seem to be the ones that are missing in my case). So far the first couple I have tried allows users to use iPhoto, iMovie, etc. and no Library repair errors. Not very good solution when you have 100s or 1,000s of users however. Also, they will need to create a new iPhoto library in the Pictures folder.

If the user has logged in before Mavericks, no issues as those folders are already there.

SOLVED Posted: 10/23/14 at 12:36 PM by jake.snyder

@jruskey we did not get any sort of ideal solution and Yosemite has the same problems. They admit there is a problem, but haven't fixed it.

To get things to work I forced smb1 on the clients and disabled Access Based Enumeration on the server. This seemed to work for awhile, but the "everyone, deny, delete" permissions kept coming back so I've been experimenting with permissions by following @Swift recommendations:

"Next, modify the "Creator Owner" permissions on the Share (default shown in TechNote Table 7.12)

Right-Click on the share > Properties > Security...

Creator Owner: Subfolders and files only \- everything EXCEPT: Full Control, Change permissions, Take ownership

These settings will prevent normal users from modifying ACLs, nipping the troublesome ACLs in the bud."

SOLVED Posted: 11/6/14 at 3:30 PM by jake.snyder

just following up here, definitely follow the permission suggestions posted by @Swift or you'll have a very bad time...

Creator Owner: Subfolders and files only \- everything EXCEPT: Full Control, Change permissions, Take ownership
SOLVED Posted: 11/13/14 at 6:53 PM by flowirin

I'm using profile redirection and document redirection via AD and group policy (both say the same things) synchronised from an external database,
logging into PCs was fine, but fresh 10.8 macs bound to AD all had this error for their users
i've been working on a scripted solution, which works for new users, where i manually create this lot:
$homeFolderlist= @( ("$user"), ("$user\$Desktop"), ("$user\Downloads") , ("$user\Favorites") , ("$user\Library")) then set the acl permissions accoring to this list:$rights = "ListDirectory, ReadData, WriteData, CreateFiles, CreateDirectories, AppendData, ReadExtendedAttributes, WriteExtendedAttributes, Traverse, ExecuteFile, DeleteSubdirectoriesAndFiles, ReadAttributes, WriteAttributes, Write, Delete, ReadPermissions, Read, ReadAndExecute, Modify, Synchronize"

$useranddomainname = New-Object System.Security.Principal.NTAccount("DOMAIN\" \+$user) $Ra5 = @( ("Everyone"), ("Delete, Synchronize") , ("None"), ("None"), ("Deny") )$Ra3 = @( ("CREATOR OWNER"), ($rights) , ("ContainerInherit, ObjectInherit"), ("InheritOnly"), ("Allow") )$Ra2= @( ("NT AUTHORITY\SYSTEM"), ("FullControl") , ("ContainerInherit, ObjectInherit"), ("None"), ("Allow") ) $Ra1= @( ("BUILTIN\Administrators"), ("FullControl") , ("ContainerInherit, ObjectInherit"), ("None"), ("Allow") )$Ra4= @( ("$useranddomainname"), ("FullControl") , ("ContainerInherit, ObjectInherit"), ("None"), ("Allow") ) which works. i've not managed to get existing users copied over from an old OD server to work reliably, yet. definitely an ACL thing but im having issues with [ and ] and ( ) and path lengths within powerscript. SOLVED Posted: 11/19/14 at 10:43 AM by agrosvenor We have implemented all of the suggestions here for SMB1 & fixing ACL's \- worked great for a little while. We are now seeing intermittent issues where users on 10.9.5 cannot move files again \- they receive the "Finder needs an administrators username and password" dialog. When looking at the Windows share, the rogue ACL's have not returned to the account, but they are still unable to move items. If the user logs out & back in, they are able to move files as expected, without the administrators dialog. Anyone else seeing this behavior, or have any suggestions on where to look next? Thanks! SOLVED Posted: 11/19/14 at 11:26 AM by kevin5495 Testing in 10.10.1, not seeing this issue anymore when binding from Directory Utility. SOLVED Posted: 5/11/15 at 8:58 AM by m.entholzner The issues started with "OS X needs to repair your Library" started when I created additional accounts in another AD forest. First, I had only one account (lets say "account123") in europe.company.com. Since two weeks, I have accounts with the same short name in china.company.com and americas.company.com too. This was the beginning of the "OS X needs to repair bla bla" error. The home folder is created, but it seems that OS X uses the first account in the AD structure to set the permissions of the mobile account. There is no change when I use the UPN or NetBIOS name for login. OS X always seems to use the first account found in AD. Any suggestions? SOLVED Posted: 5/11/15 at 1:02 PM by jake.snyder I suggest creating a new post as your issue sounds like it's not related to what we were experiencing. If anyone else is looking at this thread I have just confirmed that this issue has not been fixed in 10.10.3, but disabling ANE and forcing SMB1 still work as a work around. My support ticket is still open with Apple. SOLVED Posted: 5/18/15 at 1:50 PM by jake.snyder SMB3 with Windows Server 2012 R2 seems to be working on 10.10.3. Share settings: Everyone: Read Authenticated Users: Change, Read Administrators: Full Control, Change, Read Security (NTFS) settings: SYSTEM: Full Control (Applies to "This folder, subfolders, and files") Local or Domain Administrator: Full Control (Applies to "This folder, subfolders, and files") CREATOR OWNER: Everything except Full Control, Change permissions, and Take ownership (Applies to "Subfolders and files only") On Server Manager, go to File and Storage Services > Shares Uncheck "Allow caching of share" Check "Encrypt data access" Despite not letting Creator Owner have full control, the defined user account ends up getting full control anyways. I think the idea for setting restrictions on the share permissions is to circumvent full control. Windows admins typically prefer to set everyone at full control and then have everything secured at the NTFS level. That method just doesn't seem to work well when os x clients are involved. Securing authenticated users at the share level might prevent them from having full control or weird ACL issues. "Share permissions and NTFS permissions are independent in the sense that neither changes the other. The final access permissions on a shared folder are determined by taking into consideration both the share permission and the NTFS permission entries. The more restrictive permissions are then applied." In our case, the share settings actually are the more restrictive permissions for our users. We'll be testing with this setup. It's encouraging to see that we can actually use SMB3 now. Is anyone else using SMB3 with Windows Server 2012 R2 successfully? Note: I still have Access Based Enumeration disabled. The following are screen shots of the configuration, if helpful. SOLVED Posted: 5/19/15 at 11:54 PM by plawrence @jake.snyder Hi Jake Thanks for your detailed post, I used your settings to configure a share on a Windows 2012 server. I noticed that if I let Active Directory create the home folder (after specifying the path in the Profile tab of the account properties) to sets the Owner of the folder to the Local Administrator on the Windows 2012 server. We are planning to create home folders with a basic template of the standard Mac folders (Desktop, Documents, Library, etc) so we are looking at a powershell script with the following commands to copy a homedir template and set the owner correctly: robocopy \path\to\template \path\to\homeshare\username /copyall /e /sl /njh /njs /nfl /ndl icacls \path\to\homeshare\username /setowner username /t /c /q /l I am then able to successfully login to this account as a Network Home Folder with no errors. It also appears to be working over AFP with a trial version of ExtremeZ-IP installed on the server. Very promising! Patrick SOLVED Posted: 5/20/15 at 10:05 AM by jake.snyder 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". SOLVED Posted: 6/25/15 at 10:27 PM by plawrence @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:\rsync\$id e:\homedirs\$id /copyall /e /sl /njh /njs /nfl /ndl

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 SOLVED Posted: 9/2/15 at 7:22 AM by Zvordauk 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. SOLVED Posted: 9/29/15 at 8:06 PM by merc_support 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). SOLVED Posted: 9/29/15 at 8:07 PM by 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. SOLVED Posted: 10/1/15 at 10:37 AM by 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. SOLVED Posted: 10/1/15 at 12:05 PM by 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/ SOLVED Posted: 12/1/15 at 4:22 PM by 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. SOLVED Posted: 12/1/15 at 4:51 PM by 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/ SOLVED Posted: 12/1/15 at 6:58 PM by 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.

SOLVED Posted: 12/2/15 at 7:21 PM by Nix4Life

@stevewood Bingo. Solved my same issue on Monday

Thanks

LSinNY

SOLVED Posted: 1/28/16 at 2:03 AM by 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..

SOLVED Posted: 1/29/16 at 8:37 AM by gokoudes

<text deleted>

SOLVED Posted: 2/2/16 at 9:46 AM by ant89

@stevewood - thanks! this worked perfectly.

SOLVED Posted: 2/2/16 at 9:57 AM by agrosvenor

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?

SOLVED Posted: 2/11/16 at 11:11 AM by 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.

SOLVED Posted: 3/1/16 at 11:03 AM by gskibum

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.

SOLVED Posted: 3/1/16 at 11:16 AM by 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.

SOLVED Posted: 3/8/16 at 9:14 AM by 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'

:-)

SOLVED Posted: 3/9/16 at 1:36 PM by cesposito

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.

SOLVED Posted: 5/4/16 at 12:16 PM by 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?

SOLVED Posted: 7/15/16 at 11:24 AM by 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.

SOLVED Posted: 9/8/16 at 6:46 PM by 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

SOLVED Posted: 9/8/16 at 6:53 PM by 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.

SOLVED Posted: 9/8/16 at 7:28 PM by johnmcnair

Just out of curiosity what file are you talking about?

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

SOLVED Posted: 9/8/16 at 8:09 PM by 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.

SOLVED Posted: 9/8/16 at 8:46 PM by 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?

SOLVED Posted: 9/8/16 at 9:00 PM by 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?

SOLVED Posted: 9/8/16 at 9:14 PM by donmontalvo

@JesseNCSD wrote:

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

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

SOLVED Posted: 9/9/16 at 8:16 AM by SeanA

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

SOLVED Posted: 9/10/16 at 12:17 PM by 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/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

SOLVED Posted: 9/11/16 at 7:47 PM by 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  XXXX\Domain 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

SOLVED Posted: 9/12/16 at 9:41 PM by 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

SOLVED Posted: 2/9/17 at 12:06 PM by 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.

SOLVED Posted: 3/22/17 at 2:09 PM by aporlebeke

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

SOLVED Posted: 3/22/17 at 4:01 PM by aporlebeke

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 DOMAIN\Domain 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?

SOLVED Posted: 3/22/17 at 4:16 PM by 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.

SOLVED Posted: 3/22/17 at 4:19 PM by aporlebeke

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

SOLVED Posted: 3/22/17 at 4:24 PM by 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?

SOLVED Posted: 3/22/17 at 4:44 PM by aporlebeke

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

SOLVED Posted: 3/23/17 at 1:55 PM by aporlebeke

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.