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.
- Setup your shares with permissions that prevent the average user from modifying ACLs.
- 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.
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
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...
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.
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.
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">
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.