SMB slow with OS X 10.11.5+ and macOS Sierra

So over the last couple of days i had to restore my mac mini to a backup copy and once I connected via CMD R, I noticed immediately that the restore will take 7 hours of which I had suspected it was trying to restore via wifi. I then stopped wifi services and it still reported 7 hours for the restore. The restore is without an OS, unless it was using the driver from Sierra.

After the restore, I thought nothing of it until I tried copying 800MB of data to the cloud and it resulted in a 3 minute copy. Yup checked the cable, rebooted Cloud, assigned reserved IPs, all the standard stuff. Routers, switch, both Mac Mini and Clouds have been rebooted. Cable tested with MacBook retina resulting in standard gigabit speed.

The nail in the coffin is mounting the cloud with cifs or afp: gives us the standard 10-20 second copy of a 800MB file. Switch to smb and it slows down to 3 minutes.

My other MacBook retina using Sierra can mount the Cloud with smb without any slowdown in speed.

Fairly sure that the only change is 2.21.119. Sorry WD I won’t give you logs…

So even though I am getting old, my re-memory suddenly rang a bell. The backup copy did not have the signing_required=no which was applied to Mac el capitan earlier this year when we had that massive slowdown.

My current copy on my MacBook has the signing_required=no fix thus when it upgraded to Sierra, it still kept the nsmb.conf file.

Here is the link to fix this if you are experiencing slow SMBs. I’m guessing you can use a terminal command after CMD-R to add the signing_required=no before selecting a backup to restore, otherwise it would take 7 hours to restore 100GB.

How to Fix Slow SMB File Transfers on OS X 10.11.5 + macOS Sierra

Hi, thanks for the information, hope it helps a lot of users. Where you able to restore from backup?

yes indeedy… took 7 hours to restore… where-as normally it would take about an hour to restore 100GB from a MyCloud on ethernet…

Man, I really didn’t understand this. What is this signing_required=no fix?

some kind of authorization that is needed for every access. Turning it off speeds it up by a factor of 2x back then… but it might not be needed with the latest mac version or WD firmware. No idea today…

Where is the setting made, though…?

on your mac…

Buried in one thread on the Apple Discussion Forum is a suggestion to use the /etc/nsmb.conf file to disable client signing on the client end.


After unmounting & remounting the SMB share, I verified this returns transfer speeds to normal.

This is indeed the fix for speed issues I can DL and upload from mac to nas x10 quicker! but… I still have issues when browsing folders in macOS Sierra. I open a folder and then the file can take up until a minute to load. This is a big folder with alot of subfolders but windows loads it in a flash.

Directory loading on Mac SMB is very very slow in comparison to windows. I have an ePub directory of about 15,000 entries and it can take up to 30 minutes (yup minutes) versus probably 30 seconds on Windows. However if you use AFP, directory loads will be about 30 seconds to load 15,000 entries, but AFP is about half the transfer speed of SMB.

It is what it is…

It has to do with Kerberos authentication and security on the connection.

Basically, instead of just authenticating the user ONCE in the session, newer versions of the SMB protocol introduced (optional, if the server supports it as an option instead of an enforced requirement, such as when joined with active directory) a more secure transport that verifies both the client and host continually through the exchange by signing all of the messages used by the protocol. This greatly increases the authentication and processing overhead of the stream. It also makes it significantly harder for network worms to abuse SMB as a means of spreading through a corporate LAN.

yes indeed it does :slight_smile:

but directory/folder browsing is a different problem altogether as it occurred way before we had Kerberos come along.

The browsing/listing issue affects older windows clients as well. It shows its ugly face on XP machines attached to a win7 or newer domain, for instance. The winxp clients will appear to stall and grunt really hard for several seconds (to several MINUTES!) before finally giving a directory listing. This is with legit fully windows hosted shares even.

well I don’t know which version of Samba started to cause the problem with the Mac, but the first time I encountered it, I thought my cloud had hanged. I then proceeded to time it… yup 30 minutes later it finally pops up. I change over to AFP if I need to check the ePub directory.

on Windows 7, it was somewhere in the neighborhood of fast which told me that it wasn’t a cloud problem as the thought did cross my mind that WD may have implemented SMB in interpretive script :stuck_out_tongue: