Copying to Network Drive Error code -36

same problem here. setup: 10.6.1 mount a 3TB share via nfs(opensolaris server)

i have big problems with reading files / folders with special characters (worked with 10.5)

and the same copy error. BUT: sometimes it works, when i create a new folder in the share-root i can copy a file to this folder, but when i copy a file to the new createt folder in "/tank/multimedia/dll/foldername" i get the "-36 error"...

and i only copy files, no moving, after i moved 50GB of files and all new were 0b and the older were deleted...

i switched from linux to osx 3weeks ago, and i am very unhappy. it can't be that thee are bugs in the filemanagement. 😟

papierschiff

I have this problem, too.

Here are the specifics:
10.6.1 (also had the problem with 10.6)
I'm using finder to copy a local file to a Windows Server 2008 share mounted with cifs.
I get error code -36, but the file seems to copy successfully.
I did not have this problem until I upgraded to Snow Leopard.

On the server, I have 5 shares -- 3 of them are affected by this problem, 2 of them are not.

I am having the same issue as the original poster. I use a mac in a Windows environment. We have Small Business Server 2000 (I believe) running our file server. Under Leopard, I had no problem connecting and copying files back and forth via "smb" in the "connect to server" of Finder. When I upgraded to SL, I have the "error code -36" issue when I try to copy to the file server. After SL throws the error, the file is copied. But, when trying to save an edited document that I have opened in MS Word that is sitting on the server, Word crashes and none of the edits are saved. This is creating a big pain in my side.

Now the NEW discovery: Our file server is set up into various drives. I noticed today that when saving a file to our "archive" drive (where old files are archived off of the main drive), SL did not throw the "error code -36". I rechecked this to verify. So, obviously, our file server has different configurations for the various drives, and SL is able to handle one of the configurations, but not the other.

I heard a suggestion that SL can only handle certain kinds of passwords when dealing with MS Small Business Server. I have no idea if this is true or even makes sense.

Help Apple!

I think it is great that we are all exploring how to get around this problem by examining configurations of Windows shares. However, it seems to me that we should not have to make these changes.

Either the upgrade to Snow Leopard or Snow Leopard itself has a bug. This problem needs to be solved by Apple (and quickly).

For my part, I have attempted reconfiguring smb.conf and other PLIST and CONF files. I tried using smbclient and got the same results: first file copies and all others fail with error -36.

I believe I'm having the same issue -- 10.6.1 will connect to a CIFS share (being hosted from an OpenSolaris box, not Windows), but whenever I try to copy files from the finder over to it, it creates a 0-byte file & then throws error 36.

I'm going to try a solution I saw in another post (prefixing the username with the machine's IP) but I'm not sure it will work. And their other suggestion (change the password to numeric only) is unfeasible at this juncture.

Writing to confirm this... here's my unique setup...

I have a FreeBSD samba server, the home shares work fine, I can drag and drop in the finder with no problems. However, with my larger share I get the -36. My home shares are UFS, this larger share is msdosfs, and the fstab line looks like this:

/dev/ad8s1 /mnt/LARGERSHARE msdosfs rw,large,-m=775,-g=wheel 0 0

my user is in wheel, but I've tried with the group that belongs to only my user, with the same result. I've also tried using mode 777 just to see if it would work, and that doesn't work either.

another thing I can add is that from the terminal it does NOT work for me...

%cp Test.zip /Volumes/myshare
cp: /Volumes/myshare/Test.zip: fchmod failed: Permission denied

Here's hoping....

Hi Stuart,
these are steps that have to be done on the SMB Server, in our case, this is a netapp bound via ActiveDirectory (AD).
We manage the shares via our AD Server.
So this is the place where the changes have to be done.
We manage our Mac Accounts on AD and manage the settings for the Macs in OD (OpenDirectory).
google for magic triangle.
But as I stated before, the solution works (for me) also for Macs that are standalone without directory binding.
If all of this seems to be quit confusing, I would ask my local admin and show him discussion.

kind regards

Oliver

Hi folks. I have no answers, (and honestly I don't understand 75% of what you're chatting about, I'm just a lawyer who uses Macs). But your discussion helped me figure out the source of my problem (I think). In case my experience helps you, I'll relate it.

Quick history: I'm a Mac user, but long story short, I bought a PC to run one program unavailable on Macs. I had a bad experience with Virtual PC crashing on my Mac and losing work in that one program that was labor-intensive to reconstruct. I needed to be guaranteed that the program would work because I had to reconstruct it ASAP. So I bought a PC laptop for $400 rather than buying an emulation program, and Windows, for the same amount.

I have a SimpleTech backup drive that I formatted as MS-DOS so my laptop PC could also access the drive. I rarely use the PC but it is my only laptop, and I was able to use the PC and backup drive during a trip to Europe. The drive still worked perfectly with the Mac for months afterwards.

Until shortly after I upgraded to Snow Leopard!

Then I received the error -36 message whenever I tried copying a folder to the backup drive, no matter the contents. This seemed to occur every time I tried to copy.

But what I find interesting is that if I create a new folder on my Mac, and put any contents large or small, few or numerous, in the folder, the folder and contents will copy to the drive fine. If I copy that same folder back to the Mac, no problem. But THEN if I copy that very same folder (or any folder that was ever on the backup drive) back to the backup drive, the -36 error message always occurs. The result is the folder itself copies, but no contents follow.

This sucked because I used the drive as my primary source of my work files (mainly Word, Excel and pdf documents) to take back and forth from home and the office.

So I'm in the midst of copying everything off the drive, so I can reformat it the Mac way, and forget using it with my PC for a while. (Why it is taking an hour to copy 3 Gb of files off the drive is beyond me though). Hopefully whatever contamination there is in the files won't cause a problem when I re-copy the stuff to the "Mac" formatted backup drive.

I hope Apple takes care of this issue soon. Good luck.

Similar problem. I have iMac, Macbook Pro and macmini. All running 10.6.2

I get error 36 when trying to copy my iPhoto library to a share on any of these computers. I started with simple user permissions, then went to read/write for everyone. These machines are 0-2 months old. APF shares. Journaled. I tried to external drive share it also failed. I can successfully copy the 35Gig file to a Windows XP SP3 share.

The problem is still there and I wish Apple would fix it. I have a 100gb iPhoto library that I back up to my OS X 10.5.8 server and never had a problem until I upgraded to 10.6.

I have always copied the file off an external hard to my server using AFP and have never had a problem. I have checked all permissions, verified hard drives on both the client and the server and everything checks fine. I even did a clean install of 10.6 and all the patches and upgrades and still had the same problem. I then go to another machine still running 10.5.8 and copy that same file with no problems.

What gives Apple?!

Yes, the problem is since I switched to Snow Leopard.
Copying in both directions to the NAS works however.
But when opening a file with Finder - say with PreView - the file does not open.
Doing the same with muCommander then the file opens, e.g. a picture file shows up with PreView. Finder however does not launch the associated app (err -36).
Looking in the logs I see:
"smb_maperr32: no direct map for 32 bit server error (0x0000161)"

This happens only with the NAS but not with any other Windows computer in my smb network. I have searched over and over the Xcode docs but nothing found about smb_maperr32.

Hi Gordon,

This sounds familiar:My iMac had a memory problem and I was advised not to use the backup to restore executables. So, I erased and installed a clean Snow Leopard and next I wanted to restore data files. Not possible since I had no rights.

What I did was use the same user name and password and everything but in Unix a new user is generated with a new ID and that makes that you can't read your old backed up files.

The solution is simple: make a root account and login as root and now you can read all your old stuff back. You have to do this with Finder though: go to your TC, double click on your TC disk and right-click on your sparsebundle and use "show package contents". A bit cumbersome but it worked for me. And in a way I understand what happens, it is a Unix security issue that in the end we don't want to miss.

I hope it works for you.

Pierre

man overboard wrote:
Same problem here - Cannot write to NAS drive, reads are very slow.

Some sign that there is an Apple support team would be nice...

This is a user to user forum; Apple support does not officially read and does not reply on these boards.

If you want direct technical support or to report a bug, call AppleCare.

gswd wrote:
If Apple does not "officially" read and respond on these boards, then why is it on the Apple website under the Support category?

Because Apple provides these forums as a way for fellow users to help other users troubleshoot Apple issues, as for 99% of issues there's usually someone here who knows how to solve a particular problem or how to work around it.

If you want help directly from Apple, call AppleCare or visit the Genius Bar at your local Apple Store.

In today's world of social networking, every community forum, especially those on your own site, should be monitored and issues addressed appropriately. It could be from someone in the PR department letting us know that the issue has been entered into the bug system and even providing us with some tracking number or something.

Apple does not do that here, and these forums have never been meant for that purpose, no matter what you think Apple should be doing.

Have you called AppleCare on this issue? Have others who have been experiencing it?

If Apple doesn't have detailed technical knowledge of what the circumstances are under which the problem occurs, they can't fix it, and that's the interaction contacting AppleCare provides. You can be the person that provides Apple with the information they need to solve the problem and may, in fact, be asked to interact with Apple's engineers to do so.

If you want to enter things into Apple's bug system, feel free - anyone can after setting up a free ADC online account:

http://developer.apple.com/products/membership.html
http://bugreport.apple.com

I'm experiencing the same problem as described above: I get -36 errors when trying to write to my pendrive which is in FAT32. I never had problems before. So then I tried to copy a folder with Word files which I created on a PC to my WD external drive, and the same -36 error occurred.
The funny thing is that some folders with files unrelated to a PC copy just fine. Especially the folder that I created on a PC and copied to my Mac via a pendrive (which, a couple of weeks ago, worked just fine), does not copy to a pendrive.

Then I had the same problem with copying a folder full of newly created mp3s; to and from the pendrive would give a -36 error. Since I have recently installed Dropbox on my computer, I uninstalled it, did a clean restart and then the folder with mp3s copied fine to and from my FAT pendrive. But the problem with the specific folder full of PC-created wordfiles continued!

I'm just very confused... I really hope 10.6.3 fixes this, and that the update comes soon!