SMB ACL Problem

Question

We have this problem that came up sense we upgraded our servers to Leopard. When Windows users are accessing files (over SMB), the POSIX permissions seem to override the ACLs. This is a problem because applications like Excel will change the permissions.
This worked perfectly in Tiger. The windows user would modify the POSIX permissions all they want, but it wouldn't matter because the ACLs were what mattered.
Does anyone know of a solution. This is a real problem.

Answer 1

OK, here's a tip that may get the situation going for you all. This involves making an adjustment to your server's Samba configuration file, which should be done with the Windows SMB services stopped.
In /etc/smb.conf, add the following line under [global]:
*acl check permissions = no*
This mailing list archive notes the same problem: http://lists.apple.com/archives/macos-x-server/2008/Jan/msg00759.html, and it offered the above solution.
Here's a little more about why this alteration is required: Windows clients work a little differently when determining if a file or folder (an item) can be deleted or not. With simple POSIX permissions, you're allowed to delete an item as long as you have write access to the item's parent folder and as long as the POSIX special permission sticky (owner only delete) bit is not set. With ACLs, deletion can be granted explicitly on the item via the use of delete or it can be granted via implication so long as the item's parent has delete_child. In short, to deny deletion of an item, you must deny delete on the item itself and delete_child on its parent. Now it's starting to get a bit more complicated to determine if some item can or cannot be deleted.
Apparently Windows clients perform a "pre-scan" of a folder's contents ahead of time to determine if an item can or cannot be deleted. The logic behind this "pre-scan" works like this: 1. Assume that the item cannot be deleted. 2. If the pre-scan evaluates effective permissions correctly, and those permissions allow delete, flag the item as being delete-able.
Now when you go to delete the item, Windows just checks the result of its pre-scan. With Leopard, Windows boxes are having trouble evaluating effective permissions from the Darwin ACL model. (I don't know why.) Thus, the pre-scan returns "deletion denied" because that's the default assumption. Windows didn't even try to delete the file; rather, it simply doesn't think this is possible.
The use of *acl check permissions = no* disables this Windows "pre-scanning" behavior. Unfortunately, this can mean that an item that really cannot be deleted appears to be delete-able. In this case the item will "magically reappear" the next time the folder's contents are refreshed in Windows.
Hope this helps! This is my present understanding of the need.
--Gerrit
Message was edited by: Gerrit DeWitt