Error 36 SMB share Yosemite

Question

Level 1

10 points

Error 36 SMB share Yosemite

Hi there!

Having a bit of a problem with Yosemite SMB sharing. Yosemite has solved hanging AFP shares and numerous other issues for our file server but now we have encountered another issue and that is error 36.

We have a Mac Mini running Yosemite 10.10.1 and have a RAID 10 array connected via thunderbolt. When we transfer data to the array from a computer on our network we encounter an error 36 but only in Finder, Path Finder by cocoa tech doesn't have any problems with transferring files. The odd thing is, when the error 36 pops up and says it can't write the data it still copies the file across anyway...

I've turned off SMB and defaulted to AFP but immediately we encountered the dreaded beachball again so switched SMB sharing back on.

Is there anything we can do to stop this happening?

Cheers!

Posted on Dec 9, 2014 8:09 AM

Reply

Answer 1

Logsi Author

Level 1

10 points

Dec 11, 2014 12:56 AM in response to Logsi

I tried deleting the file i created in Mavericks to force SMB1 as i thought this may be causing issues but it didn't work.

Still get Error 36 when copying files to the file server under SMB. AFP is fine however.

Reply

Answer 2

BoxOslo

Level 1

0 points

Dec 22, 2014 2:45 AM in response to Logsi

I have exactly the same problem. I have set up a MacMini with Yosemite 10.10.1 server, and shared a Lacie RAID volume over thunderbolt. Got exactly same error when users try to copy folders to the shared volume. Connected via SMB. Please Help!

Logsi, have you found any solution?

Reply

Answer 3

Logsi Author

Level 1

10 points

Dec 23, 2014 5:53 AM in response to BoxOslo

I'm going to update it to the pre-release 10.10.2 over christmas and see if that fixes it.

I'm running exactly the same setup though. Attached LaCie 5Big connected with thunderbolt.

Reply

Answer 4

BoxOslo

Level 1

0 points

Dec 23, 2014 6:32 AM in response to Logsi

FYI: I have also no problems when connecting to AFP.

On my thunderbolt disk I have 3 folders that I share, and only have this SMB problems on one of the shares. I have also experienced that the permissions on this share is a bit different down in the root, so I think this issue we both got could be a permission problem.

Please post if you find out more about this issue and I will do the same. Happy Christmas!

Reply

Answer 5

Logsi Author

Level 1

10 points

Jan 8, 2015 3:41 AM in response to BoxOslo

I've just done some testing on a test server i have set up and I could replicate the same problems on this with a carbon copy cloned drive. This is a USB3 LaCie drive.

I had a play with permissions and propagated the permissions and it's solved the error 36 issue. I have updated this server to 10.10.2 Beta. Not sure if this has any relevance though.

Now, i wait until everyone is off to do it to the main server!

Reply

Answer 6

Jan 8, 2015 5:07 AM in response to Logsi

Same Problem here. Tested with two MacBook Pro (A1502 and A1278) under Yosemite 10.10.1 as Clients to an XServe with 10.6 (yes). Copy-Process stops with Error -36. AFP is fine. No Solution.

Reply

Answer 7

Ronuccio

Level 1

0 points

Mar 11, 2015 12:56 PM in response to Logsi

Same problem, Mac Mini, OS10.10.2, Promise RAID array for files, thunderbolt connection. However the problem emerged when the clients were updated to Yosemite, thought it would go away when I upgraded the server to Yosemite. Also same problem trying to copy files from client to client over the network. Terrible problem, has anyone found a solution?

Reply

Answer 8

Logsi Author

Level 1

10 points

Mar 16, 2015 4:52 AM in response to Logsi

Has anyone tried the fix i posted above?

You have to reset and strip the permissions via terminal and then apply them again via the Server App. If you change permissions via the Server App in the first instance it's additive and just adds new permissions to the old one. I'm trying to find a thread with how to reset and strip permissions entirely.

This is what i did and no longer have the error 36.

Reply

Answer 9

Nielsvk

Level 1

0 points

Apr 14, 2015 1:48 PM in response to Logsi

Got the same problem.

Server is an Mac mini Yosemite Server 10.10.3 with an Caldigit T3 RAID via Thunderbolt.

AFP works fine SMB keeps giving me an error 36.

I have no idea how i can strip the permissions via Terminal, years ago i always used Batchmod.

Can i use this? http://www.lagentesoft.com/batchmod/

Reply

Answer 10

May 26, 2015 2:19 PM in response to Nielsvk

Interesting. I have been doing research on this -36 error and this thread seems the closest to my problem as well.

My environment is a 10.10 mac that is trying to copy files to a windows 2012 fileserver. Its interesting that you are getting this error on an OSX fileserver too! i figured it must be a windows setting on my server

the problem only exists in finder. if i use freefilesync for the mac the folder copies fine. Its gotta be a finder bug! This is with SMB.

i think this bug affects all my mac users though, as they often complain of network file errors to the server. So it would be great if apple could fix finder or find the cause of it.

I will continue looking, just to let you know, error -36 is also happening for me on a windows server. The only fix i have seen so far is revert to smb1 which is not possible in our environment.

Reply

Answer 11

iansilv

Level 1

4 points

Jun 11, 2015 10:00 PM in response to Logsi

I'm having the exact same problem. Are there any long-term issues or is this just a bug that gives an error with no actual problems?

Could someone post the terminal code that allows the permissions to be reset?

Reply

Answer 12

Jul 2, 2015 1:00 AM in response to Logsi

Bump

Same issues as above, you can even test this within a non server environment, just using the built in Apple Sharing options and only using SMB for the share and connect using Finder.

It seems to only occur if there are thumbs.db files that have been created by Windows PC connecting to the same share.

Also the SMB connection can be incredibly slow at navigating directories, compared to using AFP.

Wish there was an option to just use AFP within Finder on 10.9 / 10.10

Reply

Answer 13

Nov 19, 2015 4:22 PM in response to Alan Phillpot

I tried the same test file that i used in 10.10 after doing a clean install on a mac to 10.11 and the problem is no longer there.

YMMV, but it appears to be fixed for us. I no longer get this error when copying my test file to the server anymore. Someone else would need to confirm whether 10.11 does fix this bug, whatever it was.

Reply