OS X AFP shares and access

Question

I am running 10.5.6 Client as a mini server and am having problems with AFP shares. All clients are OS X 10.5.7

I have created three users for 'File Sharing' only on the 'server'. I have created groups and placed these users into specific groups. I have created ACL's to give each group access to certain shares.

Two of those users can read and write to any share, one user cannot write to the shares, with different results:

• when copying a directory, only the directory is created, no files inside are copied, the OS does not give any errors
• when copying a single file I get three dialogs: "You may need to enter the name and password for an administrator on this computer to change the item named 'xxxx', "The item 'xxxxx' contains one or more items you do not have permission to read. Do you want to copy the items you are allowed to read?, and, The operation cannot be completed because you do not have sufficient priveleges for some of the items.

With the single file, a file gets created on the server, but is empty.

My ACL for the group this user belongs to is:

 0: group:projectmembers allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
 1: group:informationtechnology inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
 2: group:executive inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
 3: group:everyone inherited deny list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit

User 1 & 2 belong to informationtechnology and executive and projectmembers, they can read and write freely on the share. User 3 belongs to projectmembers and cannot read and write freely.

I have read that this is a UID issue, however User 1 & 2 do not have matching UID's across clients and server and they work, so I don't think this is the case.

Any ideas?

Answer 1

Replaced my original answer after doing some testing of my own using a OS X 10.5.6 Server and a 10.5.7 Client:

What I found after a bit of experimentation is that OS X is a bit crazy when it comes to ACL inheritance for share points. ACLs that are inherited will always take precedence over ACLs that are set at the share point (or lower in the tree) but only for write permissions. You can quite happily give a user read permissions on a folder down the tree a bit and it'll work, but if you give them write it'll fail hopelessly.

What does work. Turn off inheritance for the deny rule above the problem share (you can have it there, just don't have it inherit in any way). Then explicitly set the deny at the share point (turning inheritance on at this point seems to work just fine). My testing had that working without issue but it'd be a pain if you had to manage hundreds of similar shares.

One option might be a top level blanket deny on Everyone having read and then the no-inherit block on write as suggested above. Please let me know how you get on as I'm interested for my own share management.