Samba throughput slow from client end when mounted through Nemo

[Ascaris]

Mint 18.3 x64, three different PCs (Core 2 Duo, Sandy Bridge i5, Braswell Celeron N), all with the same issue.

I have been struggling with this one for a while. I've searched and read a ton of posts about it at various Linux-related sites, and none of the advice (like setting socket options and other parameters in samba.conf) has helped. Some of them made it slower, but none improved the speed beyond what I had been getting before playing with any of the parameters.

I've narrowed the scope of the issue to Samba shares that are mounted through the Nemo GUI on the client machine. It does not matter whether the server is running Windows or Mint... if the client is Mint and the share is mounted via Nemo, I get ~50% of the throughput expected. When I reboot into Windows on any of the client machines, I get all of the speed expected from the same hardware and the same server.

This slowdown happens on all three PCs I have Mint on, whether using the gigabit ethernet or wireless (Intel and Realtek gigabit, Atheros, Intel, and another Intel on wireless). I tried a live USB with Kubuntu on it, and I got the same result using Dolphin: half the expected speed.

I knew the underlying TCP speed was fine, since FTP connections and transfers were as fast as expected, and when I tried using smbclient to access the shares from the terminal on the Mint PC, the results were good (all the expected speed) there too.

As one site suggested, I tried unmounting the share with the Nemo gui and then mounted the share from the terminal with this (replacing the xxxxxx and .x.x. with the appropriate values, of course):

Code: Select all

sudo mount -t cifs -o username=xxxxxx //192.168.x.x/Shared /mnt/TEST-SHARE

I tried it at first without the sudo, but it told me "only root can use --options option." After entering the above line and typing the password for the sudo and then the one for the share (it balked when I tried specifying my password on the command line; the special characters in my password probably messed it up, and rather than try to look up the syntax of how to make it work, I just tried it without to see if it would prompt me, which it did), it mounted just fine.

I was then able to open that share in Nemo and initiate a copy with the usual drag and drop, and I got the full throughput expected.

So... while I now have a workable means of getting the full speed through Samba, I would like to know if there is a way to get Nemo to do whatever it was that made the command-line mount quick? The way Nemo does it automatically is quite convenient, and I would like to be able to use that if it is possible.

[keithrboz]

I tried sshfs for this reason, and found the set-up easy between to LM machines. Check this link:

https://www.digitalocean.com/community/ ... s-over-ssh


I had to list both machine ip addresses to /etc/hosts; and install openssh-server and openssh-client.

There is a reference to VPS near the mount instructions - I ignored this, successfully

Then I had top delete the option ,defer_permissions from the mount options quoted.

I have added the mount to /etc/fstab yet,but that seems simple enough.

[keithrboz]

I realised later I should have added m final mount:


sudo sshfs -o allow_other keith@192.168.0.126:/mnt/ /mnt/compaq

I only wanted the remote /mnt available locally

[keithrboz]

A further addendum. I wrote an alias to mount the remote share, and discovered I had to add an option:

alias mntc='sudo sshfs -o allow_other,nonempty keith@192.168.0.126:/mnt/ /mnt/compaq/ && mc /mnt/data/keith /mnt/compaq'

Worked as I expected.

[altair4]

@Ascaris,

Samba / SMB has something called dialects: SMB1, SMB2, and SMB3. SMB1 is the oldest and considered "chatty" which degrades actual file transfer throughput and sometimes leads to disconnects. On the server end ( those offering shares ) most modern operating systems including Linux can use SMB3. SMB3 is far superior in speed to SMB1.

Nemo ( like all Linux file managers ) uses smbclient ( actually a library of that ) to access a Samba share and by design defaults to using the SMB1 dialect.

CIFS is different. If you are using Mint18 the Linux kernel sets the default CIFS smb dialect to SMB3.

You can change the SMB dialect that nemo uses:

Edit smb.conf:

Code: Select all

gksu xed /etc/samba/smb.conf

Right under the workgroup = WORKGROUP line add this one:

Code: Select all

client max protocol = SMB3

But that comes at a price. SMB1 and share "discovery" ( finding samba hosts by going to Network in Nemo ) are linked. You cannot have one without the other. So if you change the max protocol to SMB3 you disable host discovery. You can still access a host by name or by ip address but you have to do it explicitly - As in smb://192.168.x.x in nemo. You can Bookmark it at that point.

The smbclient / gvfs mechanism that Nemo uses has other overhead associated with it so it probably won't match a CIFS mount but you should see an improvement in speed.

[Ascaris]

Keithrboz,
Thanks, I will take a look at that.

Altair4,

It is faster when I specify SMB3 as you suggest, but still short of the speed with the CIFS mount or Windows (as you suggested it would be).

With my 300 mbit wireless-N connection, I get around 12 MB/s with the Nemo mount (GVFS) and SMB1. With SMB3 and GVFS, that went to about 16 MB/s. With CIFS or in Windows, it's about 22MB/s, and in Windows, that's with SMB1 (full browsing via NetBIOS enabled).

I noticed that around 2010, there were a lot of messages posted about how CIFS was much slower than GVFS, which in turn was slower than Windows. The numbers cited by the writers of these messages for GVFS transfers over gigabit ethernet are pretty close to what I get over my gigabit connection with GVFS all these years later, but CIFS has jumped way ahead to be on par with what I got in Windows. I wonder if this is something that is simply not optimized well, as the CIFS implementation apparently wasn't back then, or if this is as good as GVFS can get, given the structural limitations it has to live within.

Thanks for the reply and info.

[pastic]

You can change the SMB dialect that nemo uses:

Edit smb.conf:
Right under the workgroup = WORKGROUP line add this one:

Code: Select all

client max protocol = SMB3

But that comes at a price. SMB1 and share "discovery" ( finding samba hosts by going to Network in Nemo ) are linked. You cannot have one without the other. So if you change the max protocol to SMB3 you disable host discovery. You can still access a host by name or by ip address but you have to do it explicitly - As in smb://192.168.x.x in nemo. You can Bookmark it at that point.

Hi,
I set my NAS to serve min=SMB2.1 and max=SMB3. After that I could no longer browse the shares on the NAS in Nemo (Mint 18.1). This was expected. But after specifying max protocol smb3 according to the above, I am again able to click to 'Network' link in Nemo and all my NAS shares appear and can be used. This was unexpected.

Maybe I misunderstood the blue "but"?