How I can force El Capitan to use SMB3 (I have heard it perform better than this)?

Windows machines connect and list files fast but OS X machines are terribly slow and becoming nonuse because there might be thousands of files and folders to list.

When I run in console:

smbutil statshares -m /Volumes/myShare/

I get the following:

SHARE                         ATTRIBUTE TYPE                VALUE
                              SERVER_NAME                   <internal ip>
                              USER_ID                       501
                              SMB_NEGOTIATE                 AUTO_NEGOTIATE
                              SMB_VERSION                   SMB_1
                              SMB_SHARE_TYPE                UNKNOWN
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              LARGE_FILE_SUPPORTED          TRUE

  • How do you mount/connect the volume? – nohillside Apr 26 '16 at 9:59
  • 1
    smb://<ip>, from finder -> Go To -> connect to server, as known as CMD + K :) – Diamonte Apr 26 '16 at 10:55
  • This is ridiculously slow! Any solution yet ? I'm uploading 1.37Gt file for 13mins ? With gigabit network, 2.66Gt takes like 20mins... ? My co workers with windows upload like in less than minute both... Apple needs to work in this if they are planning to people to use these with work :( Literally costs money to use macs in work if you use 20mins instead of 1min min with windows – Diamonte May 31 '16 at 7:37
  • We are not Apple, please use the contact details on apple.com to address them directly. – nohillside May 31 '16 at 8:45
  • I know that, but I'm requesting for help if there is any fix around made by someone else... I just stated they should fix this because its common issue and been around long time. I have contact Apple too, several months ago, and I thing there is thousands who has done so aswell, maybe they don't know how to fix – Diamonte May 31 '16 at 9:11

The problem is caused by Apple's home-made implementation of the smb protocol. Using smb3 won't make a difference.

Server-Side Fix

If you have control of the smb server (Samba?) then you can fix this issue by enabling the vfs_fruit module. If you are not using Samba then you'll need to find another way to enable "Alternate Data Streams" (ADS) and intercept OSX's "special" streams: AFP_AfpInfo and AFP_Resource. I made notes of all the details at the plazko.io blog. On Samba server you can fix the issue by enabling vfs_fruit in smb.conf like this:

vfs objects = fruit streams_xattr

From the vfs_fruit manpage:

The module enables alternate data streams (ADS) support for a share, intercepts the OS X special streams "AFP_AfpInfo" and "AFP_Resource" and handles them in a special way. All other named streams are deferred to vfs_streams_xattr which must be loaded together with vfs_fruit.

Having shares with ADS support enabled for OS X client is worthwhile because it resembles the behaviour of Apple's own SMB server implementation and it avoids certain severe performance degradations caused by Samba's case sensitivity semantics.

Important note for novices: This fix needs to be done on the server side. If you do not have control of the smb server (presumably Samba) then you will not be able to use this fix.

Client-Side Fix

If you do not have control of the smb server, then your only option is to change the way the OSX client is handling smb. The only way to do that is to replace Apple's implementation of the smb stack with Samba. I have never done this, but there is a tutorial here.

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .