5

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
Frenchie
  • 1,272
  • 9
  • 14

6 Answers6

1

You may want to look into the named streams settings. Apple has an article on it. "Mac OS X v10.5, v10.6: About named streams on SMB-mounted NAS, Mac OS X, and Windows servers; "-36" or "-50" alerts may appear"

tegbains
  • 1,956
  • 12
  • 27
  • We've got steams off in /etc/nsmb.conf for our test machines, but I wasn't aware that you could switch it off for the volume. Cheers, we'll give that a shot. – Frenchie Feb 06 '10 at 00:05
1

A different Apple article TS1564 references an earlier issue in 10.3/10.4 producing error -36 with SMB shares.

Apparently it's related to clear-text vs encrypted authentication...something else to consider?

Cheers, M.

Mark Glossop
  • 121
  • 2
  • No go, the smb session is up and running, and the security is okay as we can do everything one might expect in the terminal. Just seems to be limited to the finder and stuff that depends on it. Rgds. – Frenchie Feb 10 '10 at 06:15
1

The problem is likely due to Finder bugs in the way it handles resource forks as extended attributes.

I would try:

ea support = no

This may result in ._ files but until Apple cares enough to make their file manager interoperable, this is what you have to deal with.

Edit: I just noticed you actually did try disabling them. That is where I have ran into all the Finder issues. After some brief searching it looks like turning off unix extensions is the only reported fix.

  • Alas, it certainly seems that way. Oh well, for nearly all of our use cases that's acceptable for now, a few things like Office break in unusual ways but we have workarounds for most things. – Frenchie Mar 11 '10 at 01:47
1

You could try: unix extensions = no

  • That's what I said in my last paragraph, +1 though as it is a workaround that works for most things. – Frenchie Apr 19 '10 at 01:19
0

Just to clarify: your workaround is to set unix extensions = no in /etc/smb.conf on the CLIENT, right?

Because I tried that but I still get the 36 error.

theduke
  • 600
  • 2
  • 6
  • 11
0

I was having this issue myself, and found a much simpler solution on http://osxdaily.com/2015/02/21/fix-error-code-36-finder-mac-os-x/.

On your Mac, open the terminal and run dot_clean against the destination folder of your downloading file.

E.g. I download all my files to ~/Downloads folder so I run:

dot_clean ~/Downloads

After that reattempting the download succeeded.

tokenizer_fsj
  • 101
  • 2