Error code -36

Thanks for the info, that sounds promising. :-)

By now I found the perfect solution/workaround for me, which allows to force Mac OS to use the old SMB1 implementation all the time. Credit goes to Michael Larsen at "Cammodude's Blog" (http://cammodude.blogspot.de/2013/10/os-x-109-mavericks-workaround-for-smb.html).

To sum it up: You have to create a file nsmb.conf within ~/Library/Preferences/ with the following content:

[default]

smb_net=smb1_only

After a reboot all smb connections are now handled by the legacy smb version and therefor work quite fine. In his blog Michael Larsen states that this implementation might be slower than Apple's SMB2. While I did not perform any speed tests, I did not feel any difference on a wifi connection from a rMBP to my Mac mini server.

As soon as Apple finally fixes this issue, you just have to delete the mentioned file and reboot the machine.

A client-side patch is not really feasible when several far-flung machines are in play.

I can confirm that the Error Code -36 appears when using 10.9.2 on the client, with the OS X server running 10.9.2/Server 3.1, for Finder-sidebar (smb) mounts. afp:// mounts work OK.

The problem does not appear when peer-to-peer OS X desktop (smb) file sharing is used.

CAUTION: There has been a little typing error in my posting of the workaround. The correct lines for nsmb.conf would be:

[default]

smb_neg=smb1_only

Mind the "neg" instead of "net" on the second line...

Just adding a +1 to a client of mine who is seeing this issue as well. We are working around it for now. Can't believe a bug like this has been our there for that long.

We have a reseach situation running because of this problem. We did not have any problems any more with the

10.9.3D62 version (ore all versions before that) We now can safly copy file swithout any -36 eroros or strange slowdowns on SMB and AFP. No speed diffrenece.

We tested Client 10.9.3 -> Server 10.9.3 and Client 10.9.2 -> Server 10.9.3

Hope the update is out soon !!!

Thanks Patrick! Hopefully this makes it into the final release. I think I'll "do the right thing", and not deploy the developer version on my production system, and rather, wait for the final. Thanks again!

The patch forcing smb1 connects did it for me -- I only have a few machines and they're all local.

Still, this is a vast pain.

Many thanks to Patrick and Michael!

This problem is well recognized. If you don't feel like diving into terminal, you can do it with an app:

http://www.macparc.ch/apps/SMBconf/

lets you force SMB1, or allow SMB2 to be used.

Installed 10.9.3 update (released 15 May). After making backups, installed on server, and two client systems.

Using SMB2 on clients still generates -36 error when trying to copy files to server.

Switching back to SMB1 on clients eliminates the -36 error.

Will try it after update. I see this is D65. I had it also on one update, check if you don't have deleted users / groups in your ACL list of your share,

I have the same problem as stated over here.

When copying to my QNAP NAS error 36 is there all the time.

Copying takes place from my Imac - 10.9.4

Unfortunately it has the problem with afp, smb1, smb2 and cifs.

Any one any other ideas as it seem that the solutions in this thread are not helping my case.

Setting SMB1.0 on the NAS did the trick for me.

Its in Control panel, Network services, Advanced, Highest SMB version. I have a QNAP 469L, Running software 4.1. and is on OSX 10.9.5.

This solution worked 100% for me. Thanks a million. 🙂