Q: El Capitan 10.11.5 update SMB slow (bug)

Maybe look over the man page for 'nsmb.conf' ?

Basic AppleScript to produce a man page as a text file to your Desktop:

try

  set input_text to text returned of (display dialog "Input here:" default answer "")

  tell me to do shell script "man " & input_text & " | col -bx > /Users/$USER/Desktop/" & input_text & ".txt 2>/dev/null ; wait"

end try

Copy and paste that into a new AppleScript Editor window.

Run that and at the prompt, type "nsmb.conf" (no quotes).  Then look at your Desktop for text file "nsmb.conf.txt"

There may be an Examples section near the end of the "nsmb.conf" man page; mine shows:

           # Configuration file for example.com

           [default]

           minauth=ntlmv2

           streams=yes

           soft=yes

           notify_off=yes

           [WINXP]

           addr=windowsXP.apple.com

Learning what each of those pieces parts of the "[default]" section does/do, might help you - testing them.

-

This has been issue quite a while now, I have had this issue since last year fall or so. SMB is ridiculously SLOW!

I'm trying to work with this mac and I'm using 20-30minutes to upload files instead of 1-2minutes which my co workers can do with windows / linux machines.

Well, this november my apple care is out so I change back to windows machines because simply can't use mac for working. I passed solved problems with programs I could not use with mac which I need for my work but now theres more and more issues.

This being one annoying but working fix atm for me, its faster to upload to dropbox from mac, my co workers to download from there and then upload to local network share than myself uploading to local share... we have 100/100 net with 1gigabit local network

Krutsch, you mentioned changing your network protocol from SMB to CFIS, how do you do that? I looked in the Network pane, but couldn't find anything like that. Thanks in advance.

It depends on where you're connecting to your server, whether that's in a script, or command, or using Finder > Go > Connect to Server...    In each case, though, you would typically prefix the server name with the "smb://" or "cifs://" accordingly.

Another option (if AFP isn't available) is to use SSHFS/OSX FUSE.  It is free, and if you can ssh into the NAS, you can set this up.  It seems to handle filenames with non-ASCII characters better on my freeNAS than any of the other options it offers.

NFS is also worth trying.

carlart wrote:

 

Krutsch, you mentioned changing your network protocol from SMB to CFIS, how do you do that? I looked in the Network pane, but couldn't find anything like that. Thanks in advance.

As mentioned above, use "cifs://..." instead of "smb://..." when connecting. But the real solution is to disable the signing requirement, as detailed earlier in this thread.

Is disabling the signing a "real solution" though? It seems that if every update from OS X from now on is going to overwrite the nsmb.conf, the required signing itself needs to be coded in a better way, and the permanent fix is in Apple's hands.

Seth Goldin wrote:

 

Is disabling the signing a "real solution" though? It seems that if every update from OS X from now on is going to overwrite the nsmb.conf, the required signing itself needs to be coded in a better way, and the permanent fix is in Apple's hands.

So Windows Linux don't sign and that's why NAS smb is working? I'm confused. The latest update brought an issue with SMB and seeing files on a share. Its been over a year for the slow SMB.

Seth Goldin wrote:

 

Is disabling the signing a "real solution" though? It seems that if every update from OS X from now on is going to overwrite the nsmb.conf, the required signing itself needs to be coded in a better way, and the permanent fix is in Apple's hands.

Well, the problem is really within your NAS device, from a performance perspective. If your consumer-grade NAS solution can't handle signed/encryted traffic between your Mac and the SMB-serving NAS device, how can Apple fix that from the Mac OS side?

To add to the confusion, my WDMyCloud NAS is suffering from this SMB mess and slow speed while my LG Nas doesn't and remained as fast as it was before the upgrade. So what is different between the 2. It's hard to tell from the settings of both, I had a look, and didn't find any, but I'm not specialist. I guess there is probably something different in the format they use. IT's a fact connecting to WDMyCloud with CIFS is damned faster than actual SMB speed. With my LGNAS whatever it is SMB or CIFS, keeps the same good speed. How to know why is there a difference? one has been affected (WD), not the other one (LG)?

Did you try this, from an earlier post to this thread?
<https://discussions.apple.com/message/30260816#30260816

Krutsch wrote:

 

Well, the problem is really within your NAS device, from a performance perspective. If your consumer-grade NAS solution can't handle signed/encryted traffic between your Mac and the SMB-serving NAS device, how can Apple fix that from the Mac OS side?

I wouldn't call Samba on FreeBSD a "consumer-grade" solution. Apple changed something in their default configuration so as to cause problems with a very popular piece of software, used by many enterprises. Just because this isn't SMB from Windows Server doesn't make it "consumer-grade."

The suggestion about seeing what's happening server-side is helpful though. My server's SMB4.conf file didn't actually even have the flags client signing or server signing. I will see about adding those flags.

Seth Goldin wrote:

 

Krutsch wrote:

 

Well, the problem is really within your NAS device, from a performance perspective. If your consumer-grade NAS solution can't handle signed/encryted traffic between your Mac and the SMB-serving NAS device, how can Apple fix that from the Mac OS side?

I wouldn't call Samba on FreeBSD a "consumer-grade" solution. Apple changed something in their default configuration so as to cause problems with a very popular piece of software, used by many enterprises. Just because this isn't SMB from Windows Server doesn't make it "consumer-grade."

 

The suggestion about seeing what's happening server-side is helpful though. My server's SMB4.conf file didn't actually even have the flags client signing or server signing. I will see about adding those flags.

I work in the storage industry, so I would call that a consumer-grade solution.

Glad you are on the right track, however.

Quick update.

1. Rather than mess with anything on the server side, I went ahead and just created a nsmb.conf file in /etc with vim. Mine didn't exist yet. sudo is required. It's as simple as just writing into the file:

   1. [default]
      
          client_signing=no
      
      
2. Restarting the OS X 10.11.5 client.

I'm happy to report that everything's working fine now!

A few notes:

• There's a man page for nsmb.conf included in OS X, which details this flag.
• When this nsmb.conf file is in /etc, and you put the flag in the [default] section, the settings are global for the whole boot disk. This will override any user-specific nsmb.conf you might have in the ~/Library/Preferences/nsmb.conf, if it exists for your user account.
• My NAS is on an offline LAN, so I don't really need the added security of SMB signing. If your NAS is connected to the Internet, you may want to keep signing on, even at the cost of poor performance, or you may want to adjust your workflow so that your high-speed SMB shares are offline, safe, and don't require SMB signing, while you use SMB with signing to access your server online to protect against those man in the middle or Badlock attacks.

On a related note, one of the Samba developers had a guess as to why Apple might have changed the defaults with such drastic performance implications, and without notice: http://article.gmane.org/gmane.network.samba.general/157447