Accessing CIFS Share on NetApp Filer gives Error -36

Posted on 07 September 2009

There seem to be an issue with Snow Leopard accessing a CIFS Share on a Filer. Especially copying of Files ends up with the following Error:

The Finder can’t complete the operation because some data in “<filename>” can’t be read or written.
(Error code -36)

Picture 1

The files on destination do exists afterwards. They also seem to be correct. Just the Error message shows up in general.

I also realized that this happens only on certain users. So I will investigate more about the differences.

It seems only member of the Domain Admins mounts the samba share with the acl’s. And that leads to this issue. I found a concerning discusion on Apple’s developer forum.

As a workaround, you could try these option on a samba server:

 unix extensions = no

And on a NetApp Filer, I tried and succeed turning this option off:

options cifs.preserve_unix_security off

14 responses to Accessing CIFS Share on NetApp Filer gives Error -36

  • Drew Haven says:

    I had this problem with a few folders when the users tried to copy files with Finder to our Samba server running on OpenSolaris (not the ZFS file server). I found that the problem was in some of the extra files that OS X had created for files. I’m not sure if it has to do with the resource/whatever forks, but they were all of the form ._{filename}. Removing these files with a quick ‘find . -name “._*” -exec rm {} \;’ and we were copying fine.

  • Chad says:

    I have found 2 workarounds for the Error -36 problem at my office.

    We had Snow Leopard 10.6.2 Macs joined to our Active Directory domain, but we were logging into the computers w/ local accounts. We connected via samba to our linux servers, logging in w/ AD accounts. Some servers would let us copy files to the server normally w/ Finder; other servers gave us Error -36 and would create a 0 byte file. We were able to delete and move files in the Finder on all the servers, even the ones that gave Error -36 on copy. Copying files from the Terminal also worked on all servers. We tried putting “unix extensions = no” in our smb.conf files, and it did not help.

    We found 2 workarounds:

    1. Unjoin your mac from the domain & restart your computer. With the machine not on the domain, we didn’t get any more Error -36’s when copying.

    2. Leave the computer on the domain, but only log into it w/ a domain account. This also let us copy to the problem servers.

    Hope that helps someone.

  • Robert Federle says:

    My problem with error -36 is even weirder. I have a new iMac here on which I restored the original configuration of my old iMac from a TimeMachine backup, so I have almost identical configurations (different computer names, different IP addresses). When I’m on iMac (New) and want to copy files larger 2 GByte from iMac (Old), I get this error after almost 2 GByte have been transfered. The copy process stops at exact the same point if I repeat this with other files. But when I’m on iMac (Old) and copy the same files to iMac (New), everything is fine. How crazy is that?

  • Tony says:

    I found this error here. It worked to fix 10.6.2 for my Celerra. I’m betting you’re seeing the same problem.

    Create a file named nsmb.conf in the /etc directory using ‘vi’ within Terminal or creating the file on your desktop and copying it to /etc, Either way, you will need to authenticate as a super user. I used ‘sudo vi /etc/nsmb.conf’ to create the file, insert the information and save it.

    The data that needs to be in the file is as follows:


    After the file is saved, a reboot will be needed for the settings to take effect.

    Client: Macbook Pro, OSX 10.6.2
    Server: EMC Cellera NAS

  • Sri says:

    have the same issue. if this is only happening with snow leoperd, how s i a netapp issue? i dont understand this idiotic thinking here. why can’t apple work with rest of the world?

  • Brian says:

    does any one know if
    “And on a NetApp Filer, I tried and succeed turning this option off:

    options cifs.preserve_unix_security off”
    requires a restart of the cifs service? or the entire filer?
    I made that change to our net app we haven’t rebooted yet but it did not work.

    • Harald Haentsch says:

      No, the setting is activated immediately. But the client needs to reconnect.

      Also check out OnTap Version 7.3.2. This version officially supports OS X 10.6.1

  • Harald Haentsch says:

    A workaround might be, just turning off Windows ACLs. Who needs that :-)

  • tommy says:

    Just tested copying with terminal cp and no errors. copy in GUI and error occurs.

  • steve says:

    Same issue here. Would love to know a fix for this. Issue on Apple side or Netapp side? Heard there is case open with Netapp already. BURT 373136

    • Harald Haentsch says:

      Are you sure? This is BURT 373136:
      Previous versions tab shows no previous versions available in Windows 7 (BURT: 373136).

  • Harald Haentsch says:

    I also tried a file without acl’s. No difference here at least. What does make a difference here, that it works with some users and some users don’t. I’m looking into group memberships right now.

  • tommy says:

    Also, I meant to add… it appears the problem has to do with copying a fie’s extended attributes.

  • tommy says:

    We are experiencing this in our work environment as well. Not sure what’s going on. 10.6.1 doesn’t fix the problem. I filed a bug report with Apple. Maybe related to NETAPP?

  • Recent Posts

    Tag Cloud

    Checkpoint FAS 3020c Join Mac OS X Server NetApp OS X 10.6 R56 SecureClient Snow Leopard


    Sysadmins World is proudly powered by WordPress and the SubtleFlux theme.

    Copyright © Sysadmins World