SMB server ignoring ACLs

[Random Chaos]

I'm having issues that the SMB server is ignoring ACLs. Anyone know a work around?

This is a Leopard Server with all current updates applied.

Here is an example. An AFP client adds a directory on our file server. Permissions auto-set to 755 for the directory (standard POSIX behavior). ACLs are set to be 777 for the default group, staff (we're a small office where everyone should have full access). AFP clients can go and add directories, files, etc successfully, getting full 777 access on everything on the server.

SMB clients see the permissions in a very different way. 755 dir with 777 ACL allows for creating a directory via SMB (different user, same group). However, SMB refuses to permit the SMB client to rename the new directory. Similarly, SMB cannot rename or move any files/directories in the directory. We have also had files delete themselves when SMB tries to rename directories, though I have no tracking to confirm this is actually a bug or just a side affect. Our SMB clients are running Windows XP, both Home and Pro.

Our fix is everytime someone has this issue is to go to server addming and propagate group permissions of R/W through the directory that the SMB client is having problems with, then SMB works file with the parent directory having 775 permissions.

Note, umask can't modify LDAP users. I've tried...no success forcing the AFP client to write the permissions of the new DIR as 775, which would bypass the problem until Apple fixes SMB.

Anyone have a work around or a fix for SMB ignoring the ACLs?

Thanks!

P.S. - I've seen several threads on the Apple forums with similar issues...none with resolutions.

 

[jhmaughan]

Same here

I'm pretty new to running my own server, which is why I got Leopard server. I figured it's simple Server Preferences would do the trick. Turns out I have the exact same problem you describe. After a couple calls to Apple Care tech support, I found a guy who seemed to know about this. He said it's a samba implementation bug that also existed in the first few Tiger releases. He said with Tiger it was fixed by 10.4.3 but that he wasn't sure why it showed up again in Leopard. He said the only way to work around was with POSIX stuff, but I don't know anything about that. So the bottom line is that I am waiting anxiously for 10.5.2.

 

[Skaffen]

I'm having issues that the SMB server is ignoring ACLs. Anyone know a work around?

Effectively at the moment there isn't one that reliably works. Fingers crossed Apple just get the 10.5.2 update out the door asap, it appears imminent from all the reports.

 

[Random Chaos]

Anyone know if 10.5.2 fixes this? Not finding a detailed release notes for 10.5.2 Server on Apple's site.

 

[Random Chaos]

Solution found at http://lists.apple.com/archives/macos-x-server/2008/Jan/msg00760.html

The cause is SMB trying to detect Window's use of the file system, and failing to do so properly.

The fix is to change:

[global]
         acl check permissions = no

in /private/etc/smb.conf

Details from the MAN page:

acl check permissions (S)

This boolean parameter controls what smbd(8)does on receiving a protocol request of "open for delete" from a Windows client. If a Windows client doesn't have permissions to delete a file then they expect this to be denied at open time. POSIX systems normally only detect restrictions on delete by actually attempting to delete the file or directory. As Windows clients can (and do) "back out" a delete request by unsetting the "delete on close" bit Samba cannot delete the file immediately on "open for delete" request as we cannot restore such a deleted file. With this parameter set to true (the default) then smbd checks the file system permissions directly on "open for delete" and denies the request without actually deleting the file if the file system permissions would seem to deny it. This is not perfect, as it's possible a user could have deleted a file without Samba being able to check the permissions correctly, but it is close enough to Windows semantics for mostly correct behaviour. Samba will correctly check POSIX ACL semantics in this case.

If this parameter is set to "false" Samba doesn't check permissions on "open for delete" and allows the open. If the user doesn't have permission to delete the file this will only be discovered at close time, which is too late for the Windows user tools to display an error message to the user. The symptom of this is files that appear to have been deleted "magically" re-appearing on a Windows explorer refersh. This is an extremely advanced protocol option which should not need to be changed. This parameter was introduced in its final form in 3.0.21, an earlier version with slightly different semantics was introduced in 3.0.20. That older version is not documented here.