How to debug slow samba share by Nautilus?

Question

I have Fedora 23 with Gnome 3 and Nautilus 3.18.5-1.fc23. I have troubles with SMB speeds by using Nautilus. It is about 4.4MB/s, while by any other methods (e.g. smbclient from terminal) I got 11MB/s from the Samba server. Is there a way to debug this. I read on some forums that maybe Nautilus does not set rsize properly by mounting the drive. I am not sure about that. I did not find the mounted drive with lsblk. According to some forums the network drives are mounted to /run into a gvfs folder. This I can confirm, I got the following path:

/run/user/1000/gvfs/smb-share:server=odroid-server,share=asmedia-hdd

By mount | grep gvfs I got the following:

gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

I did not find a way to check this rsize thing. It probably would not solve my problem, I am not sure. Another thing I wanted to turn off by the drive is relatime. At least it is set to noatime on the server.

Is there a way to do this in Nautilus config (I know it is possible in fstab)? Is there another way to debug this slow SMB speed problem somehow?

Solution

Accoding to a forum the problem is with gvfs and cifs works much better. I am not familiar with these terms, but I can confirm that. By mounting the drive manually:

mount -t cifs -o username=root,password=xxxxx //192.168.0.186/asmedia-hdd /media/asmedia-hdd

I can achieve 10MB/s in Nautilus. The only problem that I don't have network discovery and I cannot umount the drive from nautilus. So I think this is not a real solution.

Is there anyway to force the Nautilus to use cifs instead of gvfs?

next

I found a config file, which appears to be very relevant:

/usr/share/gvfs/mounts/smb.mount

[Mount]
Type=smb-share
Exec=/usr/libexec/gvfsd-smb
AutoMount=false
Scheme=smb

I guess gvfs is not a partition type, it is something that uses cifs too. So I guess I can somehow set the cifs buffer size here. I was not able to find out yet how to do that.

According to wiki the gvfs is a virtual filesystem, so it can be on top of cifs, so I was right.

next

I found this answer: https://unix.stackexchange.com/a/44318/126217 by trying to gvfs mount from terminal. According to it, the export $(dbus-launch) is important before using any gvfs command. I confirm that, I was not able to use gvfs commands from terminal, and I got only vague error messages about the problem.

I was able to mount the drive manually with gvfs:

gvfs-mount smb://WORKGROUP\;[email protected]/asmedia-hdd

I was able to list the mounted drives

gvfs-mount -l

    Drive(0): KINGSTON SV300S37A120G
      Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
    Drive(1): ST31000528AS
      Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
      Volume(0): data
        Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
      Volume(1): system
        Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
      Volume(2): Rendszer számára fenntartott
        Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
    Drive(2): TSSTcorp CDDVDW SH-222AB
      Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
    Mount(0): asmedia-hdd on 192.168.0.186 -> smb://WORKGROUP;[email protected]/asmedia-hdd/
      Type: GDaemonMount

There is still not much info about the configuration of these mounted drives. Nautilus did not show the mounted drive. This is interesting, becauase when I used the mount command in terminal the mounted drive showed up in nautilus.

I found the mount point here:

cd ~/.gvfs/smb-share\:domain\=WORKGROUP\,server\=192.168.0.186\,share\=asmedia-hdd\,user\=root/

I was able to cp from the gvfs mounted drive an mkv file and I used

watch -- du -h test.mkv

to measure the transfer speed, it was about 4.3MB/s. I used the same technique by measuring cp speed when I used the smbclient command. So I was able to reproduce what Nautilus does in the background. Now the only thing I need is adding an option to change the cifs buffer size, if that is possible.

conclusion:

I ended up adding the following to the fstab:

//192.168.0.186/asmedia-hdd          /media/asmedia-hdd          cifs            rw,workgroup=WORKGROUP,username=root,password=xxxxx,noauto,users,iocharset=utf8      0     0

and used

chmod 4755 /usr/sbin/mount.cifs

because nautilus wrote, that only root can mount the drive instead of showing the root password prompt.

I don't like this solution, because nautilus does not discover the network drives this way. Another problem that I had to give permissions to all user to mount this drive and I had to give the smb password, because I did not have prompt for that either. The download speeds were okay, and I got the same by the upload as well. By the upload I got false speed and file size reports from nautilus, it writes 120MB/s at the beginning, which constantly decreases. By checking the file size with gvfs mounted drive I managed to get info about the real speeds. It was about 10MB/s.

I try to solve this with gvfs. If I manage to do so, I'll post an answer, but until that I'll use this cifs mounted workaround.

next ~ 2016

Added a bug report here: https://bugzilla.gnome.org/show_bug.cgi?id=762384 maybe they have an answer.

next ~ 2017

According to Gnome devs this is a Samba bug. They might write a patch, but there is a no guarantee. The Samba devs did not care about it in the past 3 years (2014-17), I am not even sure that project is maintained.

note:

I measured this 10MB/s through wifi connection. I did some measurements through ethernet with the same Odroid XU4 when I tried to debug this. (The GVFS uses libsmbclient, so it does something similar as calling smbget.)

copy with nautilus (18-19MB/s)

# mount with nautilus on GUI
# copy with nautilus on GUI

copy with smbget default block size (23-24MB/s)

# mount with nautilus on GUI
smbget -u root -w WORKGROUP smb://192.168.0.186/asmedia-hdd/testfile

copy with smbget 16K (1-64K) block size (38-57MB/s)

# mount with nautilus on GUI
smbget -u root -w WORKGROUP smb://192.168.0.186/asmedia-hdd/testfile --blocksize=16777216

copy with CIFS mount (70-90MB/s)

# mount in fstab
//192.168.0.186/asmedia-hdd /media/asmedia-hdd cifs rw,workgroup=WORKGROUP,username=root,password=...,noauto,users,iocharset=utf8 0 0
# copy with nautilus on GUI

So an evident bottleneck is the too small block size here in GVFS, but the speed tops around 1k block size and it reaches at most 63% of the CIFS speed, so there must be another unidentified bottleneck in the smb lib.

Comments

[emk2203]

I have the same issues with gvfs. Did you find a solution?

[Imran Juma]

@emk2203 Nope, I did not manage to solve this. Samba developers could probably fix this. Afaik. there is a bug report related to this here: bugzilla.samba.org/show_bug.cgi?id=10879 , but the page is not available currently due to a https issue. I guess this won't be fixed anytime soon... :S

[Imran Juma]

@emk2203 Probably adding the cifs mount to the fstab is the best workaround. It is not safe (storing the samba password in plain text), but at least it works.

[Beef Eater]

Thank you for taking the time and effort to investigate this problem. I am also experiencing this problem, and I have been looking for ways to improve network throughput to/from Samba shares in Nautilus and Nemo. It does look like the source of the problem is in fact in gvfs. It also looks like there is no way at present to increase the buffer size (block size) in gvfs as the current value is hard coded into it. I do not see how this problem can be fixed at present without compiling gvfs, and likely Gnome which gvfs is part of, from the source code...

[Imran Juma]

@BeefEater You can try to convince the developers to fix it, maybe you are more influential than me. :D