Background
Access Control Lists (ACLs) are applied to folders and files to define user (and group) access privileges.
I have setup two Mac mini Servers at our company – one in our Melbourne office and one in our Sydney office. Each file server is made up of the following hardware:
1x Mac mini Server (with Lion Server).
2x Promise Pegasus 12TB (6x2TB) R6 RAID System (thunderbolt) in RAID5 configuration. The two Pegasus unit are mirrored (RAID1) using SoftRAID.
Users and Groups are replicated between the two servers via Open Directory.
The PeachPit book "OS X Lion Server Essentials" is the best book I've found that explains OS X Server services and configuration. It has a good explanation of POSIX and ACLs.
The Problem
It seems there is a bug in Lion Server that causes ACLs be ignored. A couple of times I've managed to fix the problem using these steps:
1. Remove the share-point.
2. Setup up the share-point. /Volumes/promiseraid/work
3. Apply an ACL to a folder.
5. Propagate the ACL to sub-folders.
When ACLs are not applied to a folder the older POSIX permission define access privileges. With POSIX mechanism the user, group and other access privileges applied to new files and folders is defined in the 'unmask' value. The default 'unmask' value sets file/folder group to read-only access. The upshot is when POSIX mechanism is used and a member of staff creates a file or folder it is read-only to colleagues. System Administrators shouldn't need to change the 'unmask' value – too technical. Apple documentation encourages System Administrators to use ACLs to define access privileges – use ACLs to overcome the limitations of POSIX.
The workarounds I've been considering
- Stick with Lion Server, apply POSIX read&write (group and others) permissions to all folders at regular intervals (daily) and wait for Mac Apple to fix the problem.
- Abandon Lion Server (10.7) and revert to Snow Leopard Server (10.6).
- Abandon Lion Server (10.7) and setup a Microsoft Windows Server solution.
A solution?
Scanning the several threads here I think I discovered a "fix". Mac OS Lion doesn't seem to honour ACLs if
- it is a volume is being shared (AFP and/or SMB), or
- it a folder at the root level of the volume is being shared (AFP and/or SMB).
However, if the folder being shared is at least one folder deep ACLs seem to be honoured!
!!! This did not work – ACLs are not honoured !!!!!
/Volumes/promiseraid
/Volumes/promiseraid
/Volumes/promiseraid
!!! This did not work – ACLs are not honoured !!!!!
/Volumes/promiseraid/share1
/Volumes/promiseraid/share2
/Volumes/promiseraid/share3
!!! This works – ACLs are honoured !!!!!
/Volumes/promiseraid/shareditems/share1
/Volumes/promiseraid/shareditems/share2
/Volumes/promiseraid/shareditems/share3
Acknowledgement
I should acknowledge gmbion for his time troubleshooting this and reporting his findings to this thread.
A response from Apple
It would be good if Apple could address this limitation with either:
- A note from Apple acknowledging this limitation ("undocumented feature") witch advice to not share a volume or a folder at the root level of a volulme. Instead, share a folder at least one level deep; or
- Fix Lion Server so that any volume or folder can be shared and ACLs will be honoured.