Apple support engineering can replicate these issues and they been elevated to product engineering. That's all she wrote folks. Good luck!

Thanks for pushing this. My understanding is we may see something in 10.9.5.

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.

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.

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.

@eWhizz @joe.farage

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.

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-

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

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.

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

"Add" sharing permissions to allow
Everyone: Read
Authenticated Users: Change, Read
Administrators: Full Control, Change, Read

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/
/Downloads/
All the folders and files in /System/Library/User Template/English.lproj (minus the ACLs!)
/Library/Preferences/loginwindow.plist

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.

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

@jake.snyder

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

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 UsersGeneric UsersstudentUser /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 UsersstudentUser /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 UsersstudentUser /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 UsersstudentUser /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.

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

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!

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.

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

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

i've had this same problem.
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"), ("$userDownloads") , ("$userFavorites") , ("$userLibrary"))

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 AUTHORITYSYSTEM"), ("FullControl") , ("ContainerInherit, ObjectInherit"), ("None"), ("Allow") )
$Ra1= @( ("BUILTINAdministrators"), ("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.

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!

Testing in 10.10.1, not seeing this issue anymore when binding from Directory Utility.

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?

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.

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.

@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 o emplate path ohomeshareusername /copyall /e /sl /njh /njs /nfl /ndl

icacls path ohomeshareusername /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