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)
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:
global 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
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.
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.
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?
I found this error here. It worked to fix 10.6.2 for my Celerra. I’m betting you’re seeing the same problem.
http://discussions.info.apple.com/thread.jspa?threadID=2222132&tstart=0
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:
#######
[default]
streams=no
#######
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
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?
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.
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
A workaround might be, just turning off Windows ACLs. Who needs that :-)
Just tested copying with terminal cp and no errors. copy in GUI and error occurs.
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
Are you sure? This is BURT 373136:
Previous versions tab shows no previous versions available in Windows 7 (BURT: 373136).
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.
Also, I meant to add… it appears the problem has to do with copying a fie’s extended attributes.
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?