Copying to Network Drive Error code -36

Resolved! ....at least on my system.

The problem was in the Windows Server permissions. Somehow the profile got corrupted somehow. Corrected the permissions on the Windoze server and everything works again.

The error probably has something to do with copying over the hidden extended attribute files created by Mac OS X when it attempts to copy to a non-HFS+ file system, like NTFS, ZFS, or any of the others listed in this thread.

In my own experience copying files from Active Directory bound Mac Pro systems to a Windows 2003 file server, the file is successfully copied to the SMB share, but the extended attribute files are not. This leads me to believe that the "Error -36" warning, at least in my case, is most likely due to the failure to create these "._" extended attribute files.

My two cents. I could be totally wrong :P

Just to add another datapoint, I'm getting:

"The Finder can’t complete the operation because some data in "filename" can’t be read or written (Error code -36)"

...when using the Finder to copy a file from local disk to an NFS-mounted share on an IcyBox NAS. A straight command line cp of the same file works.

My test file has no extended attributes and is about 30MB in size.

*Current server options (from /etc/exports on the NAS):*

/mnt/md1/horus *(rw,root_squash)

*Current client options (from Diskutility on the Mac):*

Remote NFS URL: nfs://horus/mnt/md1/horus
Mount location: /Volumes/horus
Advanced Mount Parameters: resvport

Happy to carry out experiments with NFS mount options on both the client and server sides if anyone has any suggestions.

I am also having the same problem. I appear to be having two seperate issues just to complicate things.

1) I am unable to copy any files with extended file attributes to our SMB server. I get a "The operation can’t be completed because you don’t have permission to access some of the items." error. Deleting any extended attributes using the xattr command allows the files to be copied. A simple way to test this is to create a test.txt file using pico, not TextEdit. Try copying this file. In my case this copies fine. If you rename the file by removing the .txt it will give the file a com.apple.FinderInfo attribute. Try copying the file, I get the "The operation can’t be completed because you don’t have permission to access some of the items." error. Deleting the extended attributes with xattr or renaming the file with the .txt and the file will copy again.

2) The second problem is a -36 error on trying to copy. I have noticed that approx 50% of the time the file will copy without an error. Checking the console gives me the following error "27/10/09 4:03:27 PM /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder153 Allocator race detected: transaction is not verified for -101/2 - test7.txt". It seems to me that this is a seperate issue/bug.

Justin

CarCode wrote:
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.)

I was having this problem between my mac pro and iDisc and appear to have solved the problem at least in my case.
Analysis: The problem is intermittent - tried from more than one drive no change thus not drive problem. Copies between drives thus not os problem here. Assume no hardware prob at .me. Thus problem in-between. On net there are reams of stuff about this problem. error code -36 seems to = sorry there is a problem. Noticed there were a few streams about going through windows samba servers and not coping with unusual characters in file names so removed the _ from the file name = worked first time or I got lucky, but I'm not clever enough to know which!
Hope this helps someone. I find the help on the net very valuable and was starting to be a bit embarrassed that I only took but never gave back!
cheers

This works, when trying to connect from a PowerBook G4 running Mac OS 10.4.11 to a Windows 7 Pro 64-bit (BOOTCAMP on a Mac Pro) ...

Connect to Server:

smb://ip address_ofserver/SHARE

Note the capital letters "SHARE" for the network share on the "PC."

Now, about the copying problem ...

Experimenting with the Mac command line, I found that the cp command would copy items where the Finder would not, but still, I get errors on occasion --- on the command line, they show as "Cannot allocate memory."

I have no idea, if that is a true error report or just a guess by the Mac OS command line bash shell whatever.

Whether copying with the Finder (all too familiar Error code -36 or Error code -41) or copying at the command line using cp, the result is cosmic, but certainly there is more success when copying by using cp at the command line, than using the Finder.

Also, there seems to be an improvement by removing the .DS_Store file of the Mac directory to which I am trying to copy a file or a folder from the "PC."

I suspect that basically, there is a wobbly SMB "handshake" instead of a good, "firm" SMB "handshake" going on, and both Apple and Microsoft are interested in a fix, but a Samba + Apple + Microsoft project team that is determined to solve the problem, has not fixed it, yet.

I suspect that a lot of the "Hey! This works!" reports, are mostly improvement on the odds --- increasing the occurences of success over failure --- but no solid THIS WORKS, yet.

Our solution for copying, therefore, has been to --- at the "PC" --- copy the files of interest, to an office network SMB share (we use an Intel Mac Mini running Mac OS 10.5.8 and the smb.conf file set up to share a directory) ... and that has been working OK, and then any Mac users pick up the files, from that "Windows server" ... instead of directly from the Windows 7 Pro 64-bit "PC."

OK Found the issue/workaround.

This is to fix the issue when CP works, but Finder copy doesn't.

Why this (I think) is why it happens... Finder in all its crappy glory is to blame, and I think we all new this. The reason why is related once again to the .Files it creates. When you drag a file (say MyFile to copy into an NFS mounted share, finder will create two files ._MyFile and MyFile. What happens is one gets created as the root user (._MyFile) and the other as the actual user (MyFile), so when it tries to write the file, it will fail because the temporary file is permissioned to root.

How to fix it. Well luckily this was happening to me on my Xserve so I just decided enable the root account and use that from then on out. I wanted to do this anyways because i am used to using root for my entire environment. (Please no BS about running as root for security reasons, I'm fine, trust me)

What it really comes down to is how you use all_squash, no rootsquash, and other mounting options between your OSX and NFS server. Really you just gotta find a combination that makes root(0) and user(501) act the same to the NFS server. I never had time to figure out correctly the combination, because i just got a free pass by logging in as root and using the no rootsquash option on my server, but i'm sure someone might be able to comment on it.

Anyways hope this helps someone.

Cheers,
Bobby@CiscoIT

I might have found the solution: try to disable Simple File Sharing on windows.

In my case - all of the files that I can't copy are packages. I opened up the packages and noticed that they contain some aliases (pointers) to other files; when I delete these pointers, I am able to copy the files.

This isn't a workaround by any means, but hopefully some Apple engineers are reading this thread and might find this useful.

I have the same problem as others (copies first file, not the rest, with same error, copies single files, not files in folders) when trying to copy to an external drive attached to a BT Home Hub (I believe it is an NT4 server...) via WIFI, using Finder - didn't have this problem before SL.

However it works fine when copying the same files from the same location (from my Mac Documents folder) from inside my WinXP VM (Running VMWare Fusion 2.0.5, XP SP3) to the external drive accessed via 'My Network Places'. Not great if you access loads of files I know, but a simple work-around for those who use VMWare.

I have an Iomega Home network drive
- does anyone know if this uses plain text passwords or encrypted?
As this could be the issue.....

I found these two articles

https://iomega-eu-en.custhelp.com/cgi-bin/iomegaeu_en.cfg/php/enduser/std_adp.php?p_faqid=18698&p_created=1157649094&p_sid=3e9R4 qKj&p_accessibility=&p_redirect=&p_lva=&p_sp=cF9zcmNoPSZwX3NvcnRfYnk9JnBfZ3JpZHN vcnQ9JnBfcm93X2NudD0xOCwxOCZwX3Byb2RzPTEwMzEsMTAyNiZwX2NhdHM9NzMmcF9wdj0yLjEwMjY mcF9jdj0xLjczJnBfcGFnZT0x&p_li=&ptopview=1

Which then points to this apple support article
http://support.apple.com/kb/TS1564?viewlocale=en_US

I dont have enough knowledge to try the terminal commands - also there is no instruction on reversing it. Has anyone tried this or willing to and post the results please?

I am currently using fetch to do the job that connect to server should - come on apple!

Also not working after 10.6.2 update

I also tried re-programming from the Terminal to use non encrypted passwords but still no good.
http://support.apple.com/kb/TS1564?viewlocale=en_US

I think we should all write a letter to their offices - requesting information on this subject

For me in Europe that address is:

Apple Ltd
Holyfield Industrial Park
Cork, Republic of Ireland

If you live in the United States, try this address:

Apple Computer, 1 Infinite Loop, MS60-DR, Cupertino, California, USA, 95014

Here's hoping.....

Dear Daniel Palmer,
would you please share your wisdom with us instead of yelling around that it is working for you?....

What kind of server are you using?
What software version?
What are your ACL settings?
With what kind of test did you verify it is working for you?
What kind of document did you copy?
Did you use an application to save your document to your server?
If yes, what version, please name to doc type?
Seems like a lot of work to you?
Now you might get the idea how much work it is for the professional user to check out this problem...
In my case:
I use Netapp Ontap 7.3.1 (which is said not to be compatible with Snow Leopard....)
and Win 2003 Server SP2 (which should mean no problem) as server.

For you netapp users out there, here is a doc that shows mac os compatibility: http://now.netapp.com/NOW/knowledge/docs/olio/guides/ntsp_mac.shtml

I use the actual Office 2008 Apps, since yesterday with the actual 12.2.3 patch.
If I try to open and save a .docx I can do that on a given netapp or w2003 share although netapp says it does not work..
If I try the same with a .doc it fails. It gives the information that it is not able to write the .doc
Findercopies do work in my case for both the netapp and the w2003 shares. In fact error -36 does not happen here anymore..
I use the ACL Settings that Brandon Seymour posted above.
These are no breach in security and do well in terms of findercopies and .docx or .xlsx Documents.

I tried with 10.6.1 and 10.6.2. That makes no difference. A 10.4.x mac has no problems opening and saving .doc or .docx documents as well as 10.5.

I figure out that mainly MS Office has this problem. Try saving a Indesign 3.x Document or something simple as Textedit and this will work (for me...) Of course this does not point the whole problem to MS, I simply did not test any more applications..

I am totally ****** as there is no clue coming from apple why this does not work, while older OS versions do work...

regards
Oliver

Have you guys tried enabling writing of extended file attributes, like some said earlier?

I mean, it is fixed for me (Simple File Sharing On), but maybe it's NOT a bug that it will give an error on incorrect permissions if you're actually using the full permission system.