Copying to Network Drive Error code -36

I'm not sure if anyone have already posted this (long thread), but here's how I learned to remedy Error code -36 issues. The problem, I've found is when you copy files from non-apple formatted (HFS) devices (FAT32 windows drives, thumbdrives, smb or nsf network shares etc) into a Mac and then at some later point try to copy them back into those non-HFS devices.

It's something to do with the ._ files that get generated and then not properly restored. The solution I've found whenever an Error code -36 error appears is to open the troublesome folder (or folder containing the files) that Finder refuses to copy in a Terminal, run the command dot_clean and then try the copy again. It always works.

Alright, here's a step-by-step of the workaround I've described in my last message. So, you've just tried dragging some files somewhere else and got an Error code -36. Try this:

1) Open terminal. Applications > Utilities > Terminal

2) In terminal type: dot_clean <space> (Don't type the word <space>, just press the space bar)

3) Drag the folder you're trying to copy/move inside the terminal window
(if you're trying to copy just a few files and not a whole folder, nevertheless drag the folder they're in, not the files themselves. if said folder is open in finder, you can drag this little icon on top of the window: http://grab.by/1HEJ )

4) Notice how your terminal line now reads: dot_clean /full/address/of-your/folder (press ENTER now to run that command)

5) Now just try copying those files again. It will work.


All you've done was using the command dot_clean to clean all hidden dot-underscore files. They are OS X specific, and not used by other systems, cleaning them will not harm your data. 10.6 Somehow doesn't properly handle these resource fork files (hidden dot-underscore files) when files are copied to/from non-Apple partitions and then later back to them.

It's not a mystery, not a windows error, not a driver error, it's just a Finder bug introduced in 10.6 and I'm sure the mothership is aware of it and it'll probably go away on 10.6.3. Meanwhile, here's a workaround for you.

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 share

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.

Regression:

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 uploaded

*Solution Found...* Ok, I have upgraded 3 Macs here at my college to Snow Leopard. 2 of them were mine and 1 was another staff member. I wasn't having any problems copying to a Windows (smb) share, but other staff member was only able to copy 1 file out of a group then getting the error like the other post on this subject. I knew the only difference between the two accounts was that I am a Domain Admin and the staff is not. I check the shares that we were connecting to, to find out that I had "Full" control of the *folders under the security tab from the Window Server* and the staff member had only modify... When I *change the staff member's access to "Full"*, she was able to copy multiple files without any issues. I hope that this helps.

The problem started to reoccur... Then I went to upgrade the VMFusion (vmware) the Snow Leopard machine that was having problems (to give the user an alternative method to get files out to a SMB share) and noticed that MACFUSE was still 1.5x and the newest version of MACFUSE is 2.x. After upgrading the VMFusion which also upgraded the MACFUSE to version 2.x, the user was able to transfer files to a SMB share on a Windows Server without any errors.

Quote from Google "MacFUSE allows you to extend Mac OS X's native file handling capabilities via 3rd-party file systems. It is used as a software building block by dozens of products."

I hope this solves everyone's problems.

Confirming some of Oliver's findings:

1) My Share permissions were set so that Authenticated Users had read and write but not Full Control. Against the underlying directory, Authenticated Users had Full Control (file system permissions are different than share permissions).

2) Finder always gives Error -36 when copying to the share.

3) Set Share permissions so that Authenticated Users have Full Control.

4) Finder error goes away.

However, when I reverted the Share permissions to Read and Write, I got the Error -36 back. I can live with Full Control since this is just the Domain Controller in my home, not so sure I'd want that setting in a different environment.

So the problem seems to occurr if you have assigned "Change" permissions at either the "Share" level or the Folder Security level. I have tested extensively with the simplest of files.

Scenario - A folder on a Mac running OSX SnowLeopard containing 3 small text files. A Sub folder on a network Share with Modify Permissions assigned on the Folder and Full permissions on the Share or Change Permissions on the Share and Full permissions on the Folder.

If you drag the folder to the network share the folder itself will get there but no files and you get the error message eveyone mentions.
If you drag the 3 files together - the first file gets there and you get the error.
If you drag each file individaully - each will get there with the error msg popping up each time.

If you use the same login account on a PC - no problem exists.
If you Assign Full Permissions at the Share level and at the folder level - no problem exists either.

This is a really huge problem for my organization which has been looking forward to SnowLeopard as we continue to strive for better collaboration and integration between our OSX and Windows communities.

Please try the following:
go to thursby.com and download an eval version of Dave.
Connect to the smb volume and try whatever you did to copy or save your document.
Pls write about your results.
For me, Dave did it. I can open and save .doc and .xls documents out of office 2004 or 2008. Same for every other document. This narrows it definitly down to the SMB / CIFS Implementation of 10.6x
I do not have this problem in 10.4x or 10.5x.
I do not have the problem of -36 when saving.
I use netapp 7.31p3(!) and win2003 shares.
I only had problems when I tried to save an office (doc or docx, same for excel...) document to theses shares.
Dear Apple devs, when will you release on OS that does the job of Dave....?
regards

Oliver

Problem seems to be solved.
What remains is the question why 10.4x or 10.5x had no problem and why 10.6x is more sensitive to some ACL Settings.
How did I solve the problem?
I figured out that my netapp based SMB shares had the owner of "netapp/administrators". by changing this to "ourActiveDirecotory/Administrators" I was able to fix this problem.
I do not have a clue why this turns out to be a problem for the macs.
This solution works for AD bound macs as well as for "standalone" macs that only mount the SMB share with the AD account.
One addition: Make sure the .Trash and .TemporaryItems folder (if you use MS Office) have Full Access for every share-user.
regards

Oliver

I had a similar problem when trying to merge an iphoto library from my laptop to my desktop using iPhoto Library Manager. The solution I found was to make sure that I connected to my laptop as a user using an account with write permission, rather than as a guest. Even though I had set permissions for my iphoto library on my laptop to read/write for everyone, accessing the laptop over my network as a guest still resulted in the -36 error when I tried to merge the libraries. It was only when I connected to the laptop as a user that I was able to merge without the error. I found this solution on Fat Cat's website at http://tinyurl.com/yduyj6x

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.

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:

#########
[[default]]
streams=no
#########



You will need to use sudu to create the file.

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.

I have a similar setup here with SAMBA Version 3.4.2-1.1.3.1 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.