10.9.3 appstore update and SMB still bad!!!

Hi MB7, SMB2 and 10.9.3 - that's sad to hear 😕. I've spend some time looking into this over the last few months. Like you I looked at the 10.9.3 announcement and there was no mention of this in the update doc. Oh well.

As usual if you are using the FINDER for Drag and DROP ito a network file system that is being serviced by SMB2 (look for port 445) then either use AFP or for windows requirements force your MACS to use SMB1 until a fix is provided for SMB2.

If it helps there's a well know workaround to use SMB1 only. All works fine and to 3rd party storage appliances that are SMB1 based. windows platforms (win7/8.1) work find through their windows explorer or what's left of it.

On our OSX SERVER MAC(V 3.3.1 ) machines, we still network file sharing point as "Share over SMB" and "SHARE of AFP" and windows platforms may access as such.

All other mac machines are set to use SMB1 only if they need it. Also any default non-AFP however we have instituted an SMB1 only on all our OSX hosts using this work around:

Circumvention/Workaround to SMB2 issues:

Use the Terminal.app on each Mac machine for the following 2 commands.:.. et voila!

sudo sh -cv "echo '[default]' >> /etc/nsmb.conf; echo 'smb_neg=smb1_only' >> /etc/nsmb.conf"

This certainly works fine as SMB1 (flawlessly).

This workaround CIRCUMVENTS these FINDER Drag and DROP errors and CLIENTSIDE and SERVERSIDE issues with:

• "The Finder can’t complete the operation because some data in [some-object-name[ can’t be read or written. (Error code -36)"
• kernel[0]: smbfs_set_create_vap: smbfs_setattr, error 5
• kernel[0]: smb_ntstatus_error_to_errno: Couldn't map ntstatus (0xc000010c) to errno returning EIO
• etc

Yes you can certainly continue use the FINDER "connect to server +k or Automator "Ask For Servers" (and select those on AFP only port 548) or simply use the above workaround until and select in teh sidebar Finder until Apple resolves this.. the simply "rm -f /etc/nsmb.conf" and its back to the status quo.

I've recently added my detailed $HK0.02 worthin a thread at https://discussions.apple.com/thread/5467191?start=75&tstart=0

Post your results for others to see.

Warwick

Hong Kong

Can confirm this. I still cannot copy files via Finder to my nas running *nix. Small files are copied but larger files result in error 36. Using ftp or the mv command in terminal works though.

Hi fred, simply right now if you need to use the osx 10.9.3 finder UI to drag and drop objects to an SMB managed file system only, you will need to institute the SMB1 only workaround that is mentioned in thus thread and many others

To avoid , Those annoying -36 errors. .., use the smb1 only workaround

It's solid and works find and from what we can tell, has little performance impact and 100% user functionality

You can control some access using osx server file sharing with"share using ago" for apple only clients

This obviously won't help in the slightest with non-AFP clients and Smb serviced host and appliances

And ad nauseam, use of specific cifs:// and Smb:// from finder ex works because of smb1

Yes, there's many other methods as u know using cp, rsynch, scp, blah blah. And also Transmit.app and so many others. These are also work arounds

Post your results for others to see

Warwick

Hong Kong

Thank's for the input Warwick, but I have tried all those workarounds, including the SMBconf.app but it wont help. Since it is a dlink 323 nas there is really nothing I can do with the server (smb is the only alternative). The error started after upgrade to 10.9.2 but of course by some freak chance something else may have happened simultaneously that caused the problem but it seems less likely. It is only the Finder that wont work, Terminal and ftp works. In a thread I read something about permissions and the extra files Finder creates that may be the culprit?

/Fredrokk

Hi fred, I'm curious that setting the client (your mac) to communicate as SMB1 to an appliance expecting presumably smb1 still doesn't work. Strange

We're in and others have, experienced the same hosts and appliance issues as you describe

Setting the client end (osx 10.9.) to utilise smb1 should work

We're you able to deploy the /etc/nsmb.conf on your mac and try it out?

W

(On iPhone in Hong Kong)

Yes it driving me nuts :/ I have put a nsmb.conf file according to instructions here and in the another thread about error 36. In the first thread it is suggested that the nsmb.conf should be in the Preference forlder, but I also tried to put it in /ect/ folder as you suggested and rebooted. Still getting error 36.

/F

Just a small addition, I've got a tip from a webpage about Dave, installed a trial and copy via smb now works like before 10.9.2. It is a quite expensive solution though, but may help to understand where apple messed up?

/F

Hi Fred, I'm rather surprised that this issue of a system wide parm to cause connections vi aSMB1 hasn't worked for you. Several of our clients ave deployed this 100% success. I looked those threads quickly and didn't see a lot of detail.

Did you specifically deploy the instructions to enable /etc/nsmb.conf for SMB1 only. Very strange it didn't work for you.

Those clients and ourselves that use it can simply connect, authenticate and DRAG AND DROP to the SMB services file systems under the 10.9.3 Finder /shared sidebar.. no need to use specific connections (onnect to server +k) etc.

Did you follow the instruction here? https://discussions.apple.com/thread/5467191?start=75&tstart=0 . Similar instruction and common in these forums for SMB2 issues.

Just very curious

Post your results for others to see.

Warwick

Hong Kong

Well, like I posted earlier, I have tried all the workarounds there is. I checked the nsmb.conf several times, made new ones and even tried the SMBconfig.app that basically do the same. It is not working and the only remaining explanation has to do with permissions. clearly Apple has messed up something else than just the smb2 in the 9.2 update, but which is only sensitive to a few unix/win based servers.

/Fredrokk

Hello,

So far I have done quite a bit of work to find a fix to the SMB issues in OSX mavericks. By this time I have tried every single posted "solution" out there.

There are multiple issues with Mavericks SMB and Finder implementations. These issues stack on one another. Some issues may only be evident under the right circumstances. For example lots of small files and directories and very large SMB shares. This explains why some people report issues some don't. I belive that the people that report Maverics as working "wonderfully" simple do not have the scale to see an issue. Mavericks works great until you put it under stress. Here are my findings (general terms is late to type)

Issue 1) Listings of large directories in SMB shares take a long time. This is one issue that can be fixed if the directory listing is made of other subdirectories. It is simply a matter of removing all .DS_Store files and modifying the OSX clients to not write these files to network shares. (defaults write com.apple.desktopservices DSDontWriteNetworkStores true) If the directory/subdirectory structure is well planned then some of of the below SMB issues can be alleviated.

Issue 2) Slow small file operations (list read write). OSX's SMB implementation does not perform well with small file operations. This causes slow listings of directories that are full of small files. The work around is to modify the file structure to avoid large directories of small files.

Issue 3) Finder likes to adquire all metadata from a directory before it renders the listing. No fix for this. it just adds to issue 2. However work around is to modify the file structure to avoid large directories of small files.

Issue 4) Slow reads and writes of "files" that are actually directories full of small files, for example keynote files and iPhoto libraries. I have not found a single solution for this but it comes down to poor small file performance in OSX's SMB

I have done my testings with both single Samba servers. and Clustered Samba servers. I am very confident on the Samba server side. I have also tried server side tweaks. It always comes down to the OSX client being at fault. Windows Linux clients always perform well. Working for a creative company means that a large majority of our user base is OSX and I am really eager for apple to address these issues.

I have to add that large file operations work great in Mavericks i ussually get full bandwidth 100MBps to 120MBps when reading and writing single large files.

Great post indeed. Thanks for the insight. I can confirm that the file systems that we are using have less than 10,000 items in them. Some 9000+ items. THe items are media items (footage et al) in excess of 500GB is some cases.

Our bandwidth verified with large uncompressible objects:

• scp, rsych and
• the AJA System Test using "enable network devices" in prefs, with 10 bit 1080P RGB size=1GB as an example

to excess 100MB/sec write and 106MB/sec read. Using 9000byte jumbo frames on all 1Gbe NICS and dedicated SWITCH and secondary LAN.

Warwick

Hong Kong