One issue we recently ran into was linux nfs clients were blowing away inherited permissions on windows volumes. In order to allow rename/mv and chmod to work properly on an nfs (4 or 3) mount, you need to grant clients ‘full permissions’ on the directory they will be working in. This has the lovely side affect of a chmod, rsync, tar -xpf or anything that touches permissions completely changing the local permissions on that directory for ALL users/groups you may have assigned on NTFS
- Create a directory, set appropriate ntfs permissions (Full permissions) with inheritance for multiple security groups
- Share that directory out to an nfs client.
- On the nfs client, mount the volume, and run ‘chmod 700 /mountpoint’
- Go back into windows and notice you’ve lost all the inherited permissions you thought you assigned on that share.
- Scratch your head, check the KeepInheritance registry key, run tcp dump.
- Realize you need to place the permissions you wish to inherit in a place that the nfs client cannot change them.
How we now share volumes out is the following ‘X:\[projectname]\[data]‘
- projectname – high level, NOT shared directory that is the holder of all permissions for a project (subfolders, etc).
- For groups/users that apply to your unix clients make sure they have full permission.
- For your windows only folks, ‘Modify’ is generally good enough.
- data – directory that is actually shared out via cifs/nfs
So far this scheme is working pretty well and allows unix clients to work properly and do horrible things on local files while preserving the broader group permissions you wish to see on your windows clients.