This discussion is archived
100458 Views 199 Replies Latest reply: Apr 8, 2010 8:35 PM by Robert Bosch
Currently Being ModeratedJan 12, 2010 2:30 PM (in response to Weallstoned)Very strange. Running dot_clean has helped me about half a dozen times, and have not failed yet. We're probably looking at different (albeit similar) issues here.
I'm sorry the workaround didn't work for you guys.
Ollie.iMac 9,1, Mac OS X (10.6.2), HP SimpleSave external 500GB
Currently Being ModeratedJan 13, 2010 12:00 AM (in response to Weallstoned)I must say first off that I haven't read ALL of the pages of this thread, so this may well have been mentioned before, but what works for me and my NAS is to use FTP to transfer files to and from the NAS.
The NAS is a Macally which appears to use some form of Linux or freeBSD for the OS, but if I try to transfer files directly using 10.6.2 I do get the -36 code.
FTP is working OK. I have tried Cyberduck, YummyFTP, and FileZilla. The only issue I have seen so far with this FTP method is that somehow a few of my files have gotten a slash into the filename itself which the Mac OS seems to access on local disks OK (not sure how), but these files cannot be copied to the NAS without deleting the slashes which the NAS' OS can't handle since these filenames are actually invalid.
From what I understand the NAS is probably not saving the metadata (haven't copied any files to which the metadata is critical), but this would be true via Finder SMB access as well.Macs Since 1984!, Mac OS X (10.6.2), Snow Leo on White MacBook 2.4GHz, Leo on PowerBook 12" 1.5GHz
Currently Being ModeratedJan 13, 2010 1:37 PM (in response to TripleChime)Correct, it seems there are different reasons for error code -36. Some people can't even copy, other like me can't launch a file which has worked before.
It might be possible the password settings for smb clients are the reason for copy failures.
So copying works here back and forth with windows computers, linux computers and a NAS via smb with no problems.
However launching a file with Finder from smb clients (e.g. open a picture in Preview) works with the smb computers but not when the file sits on the NAS. The thumbnail is shown in Finder but Preview fires up an error message: Preview could not be started, error -36.
Before the update to Snow-Leopard it has worked however.
Because anything works fine with the other clients but not with the NAS, I guess there is some trouble of different Samba versions between Snow-Leopard and the Samba version running on the NAS. Samba version has changed with Snow-Leopard, but I can't change the Samba version of the NAS to make things running as before.iMac+MacbookPro, Mac OS X (10.6.2)
Currently Being ModeratedJan 13, 2010 8:44 PM (in response to CarCode)
Correct, it seems there are different reasons for error code -36. Some people can't even copy, other like me can't launch a file which has worked before.
That's it exactly.
A -36 error means the Finder encountered an I/O error attempting to perform an operation (technically it's a Mac OS X ioErr.)
There are a multitude of things that could cause it from network difficulties to a bad hard drive, so the workarounds given here will not eliminate every cause of the error.
Unfortunately one common cause seems to be using a newer version of Samba (like that included with SL) to communicate with an older version (as implemented on many NAS devices.)Quad 2.5 GHz G5, 5 GB | 15" 2.6 GHz MBP Penryn, 4 GB | 1 TB Dual-Band TC, Mac OS X (10.6.2)
Currently Being ModeratedJan 14, 2010 12:52 PM (in response to William Kucharski)<edited by host>
In most cases it is impossible to update a Samba version running on a NAS. It might however possible to lower the restrictions in a given Samba version to be friendly to different Samba versions running in a network by using the commands in the smb.conf config file settings.
Any Samba specialist is asked here for suggestions.iMac+MacbookPro, Mac OS X (10.6.2)
Currently Being ModeratedJan 21, 2010 5:40 PM (in response to CarCode)I isolated the problem some. It occurs when you try to copy a resource file in the format "._<whatever>" from a HFS volume to a CIFS share from within the Finder. To demonstrate:
1) Enable viewing of invisible files (via program MainMenu, or via "defaults write com.apple.Finder AppleShowALlFiles TRUE;killall Finder" in a terminal)
2) Open a the directory that will not copy to the CIFS share, you will find at least one file prefixed with "._", it is a resource fork file.
3) Try to drag just that resource fork file over to the CIFS share, it will produce the infamous "......can't be read or written. (Error code -36)" error.
4) Close the error and try to copy the file again, you will now receive a different error, "The item ..... can't be replaced because it's invisible" !!!
I think that the Finder has a feature where it hides resource fork files on CIFS shares from itself, and probably other non-HFS volumes. When copying such files over to a CIFS share though, it will freak out and produce the -36 error when they suddenly "disappear" after being created.
I spent hours trying various options to work around this issue on the server side Samba 3.0.X and 3.3.X and failed miserably. I think Apple is just going to have to patch the bug.
As an (annoying) work around, I found that you can delete all resource fork files from the directory you are trying to copy. That worked around the problem %100 of the time for me. For example, if the directory "Financial Data" on your desktop won't copy over to a CIFS share, you can do the following:
1) Open a terminal, run: find "Desktop/Financial Data" -name '._*' -delete
2) Close the terminal, copy "Financial Data" over to the CIFS sharec64c, Other OS, .
Currently Being ModeratedJan 22, 2010 2:48 PM (in response to brian-c)I've submitted bug report 7570870 on this, for what it's worth. The only workaround I have is to compress the folder, move the resulting zip file to the new location and then unzip it.
22-Jan-2010 03:44 PM Carey Jung:
Summary: Copying folders on Snow Leopard from a CIFS share to another location on the CIFS share or another CIFS share fails if the folder contains hidden resource fork files ("._*"). The copy operation fails with the following error:
"The Finder can’t complete the operation because some data in “XXXX” can’t be read or written. (Error code -36)"
Steps to Reproduce:
- connect to Samba share (any recent version. we've confimed on Samba 3.0.x and 3.3.x)
- create a folder on a CIFS share, e.g., on a Samba share
- copy or create a file, like an Excel file (.xlsx) in the folder and confirm ("ls -a") that a corresponding resource file (._*.xlsx) exists in the folder.
- now copy and paste the folder into a different location on the share.
Expected Results: The folder gets copied to the new location on the server.
Actual Results: You get the error above.
Notes: This is a new problem introduced with Snow Leopard. With the new NTFS streams default in Snow Leopard, it appears that the Finder is hiding the Apple Double files from itself in CIFS shares. It copies the ._ file over, but then apparently can't stat it, so gets the -36 error. We've found numerous reports on line of users experiencing the same problem with Samba shares, NAS devices, etc. The only workaround we've found is to compress the folder, move the resulting zip file to the new location, and unzip it.
22-Jan-2010 03:45 PM Carey Jung:
'Screen shot 2010-01-22 at 3.41.55 PM.png' was successfully uploadedMacBook Pro, Mac OS X (10.6.1)
Currently Being ModeratedJan 23, 2010 10:08 AM (in response to Carey Jung)It seems as if 10.6x has a problem with the NTFS ownership.
Reassign the owner to "network service", this is a local user of the NAS (in our case a netapp bound to AD)
until Apple fixes this mess, this is the way to read / write files from a SMB share.
credits for this hint goes to Chris Eads: http://www.macwindows.com/snowleopardAD.html#121009aimac 2008, Mac OS X (10.6.1)
Currently Being ModeratedFeb 1, 2010 4:37 PM (in response to XenData)I noticed that there are a couple different discussions on this topic. Also, as mentioned earlier, error code -36 is a generic error code and can have many causes. That being said I have found the solution to my issue. The problem was introduced in 10.6 and has to do with writing with NTFS Streams instead of resource forks. The solution is to create a /etc/nsmb.conf file, if it doesn't already exist, and put in the following:
You will need to use sudu to create the file.Mac Pro, Mac OS X (10.6.2)
Currently Being ModeratedFeb 2, 2010 8:11 PM (in response to MacUser4_20YRS)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.MacPro, Mac OS X (10.6.2)
Currently Being ModeratedFeb 3, 2010 9:37 PM (in response to chad von nau)chad, you should not have to unjoin your domain.
Follow the hint from Chris Eads: http://www.macwindows.com/snowleopardAD.html#121009a
This fixed it for me while I remain bound to my AD domain and can do a single login to my account and my shares.
I also want to make clear that no editing of /etc/nsmb.conf was necessary as well.
Oliverimac 2008, Mac OS X (10.6.2)
Currently Being ModeratedFeb 4, 2010 1:54 AM (in response to Oliver Kess)Thanks Oliver, but the problem on the page you linked to is slightly different from the one we were having. There are tons of SAMBA bugs in Snow Leopard.macbook pro 2.33 core2 duo, Mac OS X (10.6.2)
Currently Being ModeratedFeb 4, 2010 8:16 PM (in response to chad von nau)This from Apple:
My NAS, a Synology Diskstation exhibited the -36 problem a while back but was fixed by a firmware update from Synology and I no longer have problems copying folders, files or bundles.iMac / MacBookPro / Mac Mini, Mac OS X (10.6)
Currently Being ModeratedFeb 5, 2010 11:22 AM (in response to brian-c)I have a similar setup here with SAMBA Version 3.4.2-126.96.36.199 running on top of OpenSUSE 11.2. Had the same issues, while troubleshooting i noticed that in my smb.conf file had the "veto files = /.*/" directive set. Once i removed that, was able to copy files/folders through finder without any issues.Macbook Pro, Mac OS X (10.6.2)
Currently Being ModeratedFeb 5, 2010 2:48 PM (in response to herveyw)herveyw,
Thank you so much for posting that link to the apple article. I took the steps listed for disabling the stream, and now I have the functionality of my NAS back without having to ftp files to and from my local drive.
BTW, for those that might be wondering, I have a NexStar LX NAS box and this worked.Mac Mini, Mac OS X (10.6.2), I also have Ubuntu and Windows boxes