Copy fails with error -36 (introduced with 10.9.2)

Question

Level 1

9 points

Copy fails with error -36 (introduced with 10.9.2)

10.9.2 seems to have introduced a new bug that surfaces during a Finder copy from local volumes to remote volumes on Mavericks server 3.0.2. Copies partially fail with error message -36. This new problem was not there with 10.9.1 & Server 3.0.2. A video is of this behavior can be found here.

In summary:

A single file copy fails with Error -36, but the file is actually copied.
Multi-file copy also fails with Error -36, but the first file is actually copied.

There are no permissions issues locally, or on the server, so this is not a permissions failure. Server is running 3.0.2. Any solutions would be greatly appreciated.

MacBook Pro with Retina display, OS X Mavericks (10.9.1)

Posted on Feb 26, 2014 4:07 AM

Reply

Answer 1

Ali Kaylan Author

Level 1

9 points

Feb 26, 2014 6:16 AM in response to Ali Kaylan

Apple released Server software 3.0.3 this morning, but this problem remains after the update.

Reply

Answer 2

Feb 26, 2014 5:30 PM in response to Ali Kaylan

Same problem here.

Server: 10.9.2 & Mac 10.9.2 = Error 36

Server: 10.9.2 & Mac 10.9.1 = No error

Im still running Server 3.0.2. Going to hold off on 3.0.3 since most of the mac are working fine. Luckily i only updated one of the Macs for the company i work for.

A "soultion" for me was connecting via afp.

This is so annoying considering 10.9.2 was meant to bring more stability to smb!

Reply

Answer 3

Feb 26, 2014 5:40 PM in response to Ali Kaylan

You can try turning off smb on your file share. Forcing connecting macs to use afp. Windows machine will be unable to connect of course. If you try this can you let me know how it goes.

Thanks

Reply

Answer 4

Ali Kaylan Author

Level 1

9 points

Feb 27, 2014 5:40 AM in response to BenPridmore

BenPridmore;

Thanks for the suggestion. This indeed solved the problem. I do not have a windows environment, so it is no big deal for me to turn off the SMB. But for others, this is going to be another killer bug.

It seems that SMB is still broken, now in a different way. But turning off SMB for all drives and home directories shared, with AFP selected as default, the copy error -36 goes away.

Thanks so much. Kind regards.

Ali

Reply

Answer 5

Ali Kaylan Author

Level 1

9 points

Feb 27, 2014 5:56 AM in response to Ali Kaylan

The console output also catches this issue as SMB:

2/26/14 8:19:48.000 AM kernel[0]: smb_ntstatus_error_to_errno: Couldn't map ntstatus (0xc000010c) to errno returning EIO

2/26/14 8:19:48.000 AM kernel[0]: smbfs_set_create_vap: smbfs_setattr, error 5

2/26/14 8:19:48.000 AM kernel[0]: smb_ntstatus_error_to_errno: Couldn't map ntstatus (0xc000010c) to errno returning EIO

Reply

Answer 6

Feb 28, 2014 8:08 AM in response to Ali Kaylan

I'm having this issue with SMB also -- it appears to affect all clients running 10.9.2.

10.9.1 had some SMB stability problems (connections would drop), 10.9.2 made it worse with an error -36 on every copy!

Reply

Answer 7

Feb 28, 2014 7:49 PM in response to BenPridmore

Thank you, it worked for me.

SMB has not been working well for me since it's began to be the default with 10.9.

Reply

Answer 8

krlklm

Level 1

13 points

Mar 3, 2014 12:39 AM in response to Ali Kaylan

I can only hope that Apple fixes the SMB problems really soon and finally. I convinced companies to switch to OS X Server. Now we have the mess.

Reply

Answer 9

Mar 3, 2014 4:22 PM in response to krlklm

If your after a stable mac server for file sharing use 10.6.8 (iv had experiance with all OS / server updates and this was the best for file sharing. SMB still had to be tweeked now and again tho, normally was just a restart of the service would cure any problems).

I'm very tempted to use 10.6.8 as a file server on an old mac pro then have 10.9 on a mac mini for the other features.

Lets hope 10.9.3 will be better.

Reply

Answer 10

Mar 10, 2014 8:33 AM in response to BenPridmore

Thanks a lot for evaluation - I have exactly the same problem:

10.9.1 was working 10.9.2 has this bug!

Unfortunatelly I have to use SMB - so this is not a workaround for me.

Reply

Answer 11

Mar 12, 2014 12:45 AM in response to Ali Kaylan

10.9.3 is in beta testing, which brings much-needed updates to smb according to reports. People brave or desperate enough can find it here.

http://bestblackhatforum.com/Thread-Mac-OS-X-Mavericks-10-9-3-Build-13D12-Update --119828

I'm neither brave nor desperate enough to try a beta in a work environment. Update at your own risk!

Reply

Answer 12

Fredrokk

Level 1

0 points

Mar 13, 2014 12:44 PM in response to BenPridmore

I tried the beta, still same problem of error 36 😟

pls apple fix this, bring back Steve if you have to, it is not acceptable to realease bad updates with no possibility to roll back.

Reply

Answer 13

Fredrokk

Level 1

0 points

Mar 17, 2014 12:42 PM in response to Fredrokk

A most curious thing, from another post I learned that with an original installer it is possible to revert to earlier versions. I installed 10.9 over 10.9.3 but the problem that was introduced with 10.9.2 persists. I guess the only way to solve it is a fresh install.

Reply

Answer 14

Mar 21, 2014 5:50 AM in response to Ali Kaylan

Until Apple finally fixes this issue, there might be another workaround: it is still possible to use the "old" SMB implementation by connecting to the server via cifs://myserver instead of smb://myserver. When doing so I do not experience error 36 anymore. Please note that the information window of the mounted network share still shows smb://myserver/myshare, that's all right. The only issue is that upon reconnection after a reboot or wake from sleep finder obviously switches back to Apple's own SMB client again. I have yet to find a possibility to force finder to use cifs:// instead of smb:// on a regular basis. Maybe there's an app for this... ;-)

By the way, using the classic SMB implemention can also solve certain issues when connecting to windows network shares: Apples version is not able to access folder-mapped-drives within a windows share, while using cifs:// it works just fine.

Another interesting fact is that (at least in my case) only network shares making use of ACL are concerned. The user's home directories, for example, 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.

Reply

Answer 15

krlklm

Level 1

13 points

Mar 21, 2014 10:43 AM in response to Ali Kaylan

I just found this article:

"About named streams on SMB-mounted NAS, Mac OS X, and Windows servers; "-36" or "-50" alerts may appear"

http://support.apple.com/kb/HT4017?viewlocale=en_US&locale=en_US

Didn't someone say they were "escalating" this topic? This is a nightmare for someone who just convinced people not to use a Windows Server. I'm still on hold with our 10.9.2 server waiting for a fix.

Reply