We're looking at deploying SMB homes on Debian (5.0.3) for our mac clients rather than purchasing four new Xserves. We've got our test servers built and functioning properly. Windows clients behave perfectly, but we've run into an issue with OS X (10.6.x and 10.5.x). We're going this route instead of Windows file servers due to a whole bunch of other issues that arise when going that way.

Specifically, when mounting a SMB share with unix extensions switched on and the remote server bound to AD, the finder cannot save files on the share, instead touching the file and then bombing out with a -36 IO error, folder creation is fine. Copying files in the terminal behaves fine and the problem seems to be limited to the finder.

The issue arises (I think) as the remote UID/GID is passed across when using unix extensions. OS X uses its own winbind idmap (odsam) to work out the effective UID/GID from AD users and groups whilst we're using a rid map on the server. Consequently, there is a mismatch in ownership which the finder chooses to honour.

How OS X appears to handle this is to use the remote uid and gid at the file permission level (see below) and then set an OS X acl granting the local uid/gid to have the appropriate permissions on the file. I think the finder touches the file (which the kernel allows because of the ACL) and then checks the filesystem perms and drops out with the IO error.

On a Client

fc-003353-d:homes2 root# ls -led test/
drwx------+ 2 135978  100513  16384 Feb  3 15:14 test/
 0: user:jfrench allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit
 1: group:ARTS\domain users allow 
 2: group:everyone allow 
 3: group:owner allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit,only_inherit
 4: group:group allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit,only_inherit
 5: group:everyone allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit,only_inherit

We've tried the following without any luck:

• Setting the Linux side file owner to match the OS X GID/UID
• Adding ACLs on the linux filesystem which grant the OS X GID/UID perms
• Disabling extended attributes
• Setting steams=no in /etc/nsmb.conf on the client

We're currently running a workaround which is to just turn off unix extensions which forces the macs to just mount the share as the local user with u=rwx perms. This works for most things but is causing a few apps that expect certain perms to break in subtle ways. Worst case scenario is that we'll continue running in this way but we would like to have the unix extensions on.

Regards.

Relevant SMB config below:

[global]
        workgroup = ARTS
        realm = *snip*
        security = ADS
        password server = *snip*
        unix extensions = yes
        panic action = /usr/share/panic-action %d
        idmap backend = rid:ARTS=100000-10000000
        idmap uid = 100000-10000000
        idmap gid = 100000-10000000
        winbind enum users = Yes
        winbind enum groups = Yes
        veto files = /lost+found/aquota.*/
        hide files = /desktop.ini/$RECYCLE.BIN/.*/AppData/Library/
        ea support = yes
        store dos attributes = yes
        map system = no
        map archive = no
        map readonly = no