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.


Relevant SMB config below:

        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

6 Answers 6


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, 2010 at 1:47

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"

  • 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 6, 2010 at 0:05

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.

  • 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, 2010 at 6:15

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, 2010 at 1:19

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.

  • Sorry, the workaround is server side
    – Frenchie
    Jan 10, 2011 at 6:25

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .