Error code -36

I did the same thing with apple and got the AFP to work, but still not getting SMB to work even after destroying and creating new LDAP.

My AFP users are stil working, not seeing this as a solution. Where to look if OD and DNS is corrupted.

Destroy OD, making a new one is not a solution. Still same problem. Report a bug to Apple.

Another frustrated admin…

Just FYI: I did the OS X 10.9.2 and Server 3.0.3 update on our Mac mini server this Sunday morning, and everything was working fine. Today I made the mistake of updating the client iMacs — after this update all clients using SMB shares are unable to copy or modify existing files. (Error code -36 in Finder, various complaints when using cp in Terminal). It seems like the Server is alright, but the client is broken. (That would explain why Windoze machines still work fine with the server).

so, what do we do with this problem, any solvetion? how to fix it, cifs not work, smb not work, dont_clean not work

I've noticed that I am able to use SMB and AFP to copy to/from my home folder (I am owner of the folder). When I do not own the folder (say a public folder) I get the error when using SMB, but, it works fine with AFP.

When all else fails call the Support…

So I did and the guy from Apple could reproduce the issue. I'm told that the problem was „escalated to the engineers internally“, so at least we know, that Apple knows…

In the mean time — CIFS is working for me. So I can use that with my Mavericks clients. If you want to find more then the -36 error in Finder, it's a good idea to try the cp command in Terminal. When the share is mounted using SMB, it says:

cp: file.extension: fchmod failed: Input/output error

When using AFP, or CIFS, it works correctly.

Still a bug, that Apple has to fix. At least there is a workaround.

OMG! I thought I was going mad and had done some stupid thing when upgrading my MacBook Pro's HD to a hybrid drive!

After that, which included the recent 10.9.2 upgrade I got these errors from our server - also updated. Searching the Internet over the last few days has drawn me into a variety of dark holes with no success - so thank you for the post and the fact its an Apple not a users issue 😉

Whilst we don't have any Window's PC's we do use Windows8 and XP in to test and check work, so losing SMB will cause some irritations - lets hope the patch comes soon and we can just go back to business as usual.

same here and watch it as i just lost all my user accounts - identical, well done apple

Same for me as well. Intermittent error code -36 when transferring files between shared folders on the network since upgrading to 10.9.2. Spent a bunch of time on the phone with Apple...no joy. Permissions solved nothing.

This SMB upgrade on Mavericks has caused me nothing but trouble. I should have stayed on 10.8!

Has anybody tried Synology NAS instead of sharing folders? I wonder if they would have the same issues.

SMB works perfectly fine with our Synology NAS—just not with our MacMini Server running SMB (AFP works fine)

Arrrrggghhh!! They better fix this fast! I've resorted to opening up each file and doing a "save as" in order to get the files onto our OS X Server from our OS X clients!!

Bryan, I noticed that behavior myself and figured out that only shares making use of ACL are affected. The user's home directories completely rely on classic POSIX permission and copying files to those shares works like a charm. But as soon as I add ACL permissions for a specific user (or a group he is a member of) the error 36 shows up. Unfortunately there are some shares to be used by several users, so using ACL on them is imperative for me.

michalmaria, I was able to successfully connect via CIFS as well. However, even when dragging those shares to finder's sidebar and using those links to reconnect after a reboot or wake from sleep, finder obviously uses Apples flawed SMB implementation for reconnection.

Did you find a way to fix those shares on CIFS? I am getting a bit tired of manually connecting via CIFS all the time. AFP is no option for me, since it does not work with hardlinks to folders (yes, I know, they are not recommended anyway...)

By the way, there's another thread about this issue: https://discussions.apple.com/thread/5941762?start=0&tstart=0

Regarding the CIFS workaround: We did use the Profile manager to automatically mount the shares with SMB, but it does not provide an option for CIFS (only for AFP and NFS). Apart from PM profiles every user loads an Automator app at login, which is placed in the /Users/Shared folder. I was using this for certain specific tasks not related to this problem. Because every user loads this script, I was able to insert a Connect to Server action to it (with CIFS path) and that solved it for now.

So again: every user has an app created with Automator in his/her login items. This app is placed on every single computer in the Shared folder, so it's accessible to everyone and doesn't need the server. That means, that I can change the original Automator workflow, save it as an app, replace the old ones with it and that's it.

BTW: It seems, that once you connect to the server using CIFS, it will break the standard (automatic) share discovery within Finder windows. You can connect using the Connect to server drop-down menu, but not using the Shared tab within a Finder window.

Hopefuly Apple will fix this soon and when that happens I can just delete the corresponding actions from the Automator app and use Profile manager again (or I can just replace cifs with smb in that workflow).

Just FYI: I was contacted by Apple again, they asked for various pieces of information, like sysdiagnose output and a TCP dump for the copy operation. They are definitely working on that, but of course nobody knows when the fix will appear. In the meantime, I'll stick to my workaround.