Return to

SMB share slower than expected


98% sure it's gvfs's fault. gvfs is the underlying smb handler for nautilus and it runs like shit from all of my tests. My recommendation is to use something else. smb4k seems nice so far. The interface was a little odd but it worked smoothly and just as fast as mount.


That's correct. But my goal was to have it run fast via the file browser too, so I don't need to have the share mounted all the time, or having to run Terminal whenever I need to connect to the share.

So I can replace gvfs with something else in Nautilus and it will "feel" like before?


I'm just glad that we're making ground on this issue.


You can edit the /etc/fstab file and it will mount every boot.

I don't believe you can really replace it. With either mount or smb4k it will act like a mounted location. It just gives you more options such as auto mounting at program start, unmount inaccessible mounts and unmounting on exit. It looks to me like a regular mount. I haven't dug much deeper than that.


Enter password:

Share mounted:



I mean its great that they bring "red light" to gnome - well for those who care; But they realy realy should put some serious work into the stupid gvfs; That mediocre speed is realy saddening, specially now that I learned its working with other implementations.


It's really disappointing and it seems like a lot of people have noticed it's doing this. I think most people though are either below us in terms of skill and knowledge and therefore assume that's normal or above us and also figured out that gvfs is crap and used something else. There were a couple threads I saw about gvfs doing this, and a couple about mount -t cifs doing it and not gvfs, but mostly gvfs. From my test's last night and today I think it's just a problem with gvfs.

I am personally going to use smb4k if I need to mount a share in the future and need the proper speed. It seems well thought out enough and is working at full speed. I haven't looked into it but I think smb4k might just be using the mount command with a gui and automaton wrapper. Maybe someone else wants to check that.


Well just see if a mountpoint is added - gvfs is userland - does smb4k need root permission?


It does not.

Uhhhhh! Lazy. Fiiiinnneeee.

Suspicion confirmed.


If you make an entry in fstab with the options users and noauto then the share will show up on the left panel of the file browser but won't mount until you click on it. You may also have to make the mount point in /media for it to show up in the browser panel, I'm not sure about that.

For example:

//server/share /media/mount cifs credentials=/path/to/credentials/file,uid=1000,gid=1000,users,noauto 0 0


As I said, my goal was to have it only be mounted when needed and not all the time.

Okay, then I misunderstood that part. I thought you meant that I can replace gvfs with smb4k ;-)

That's more like what I need. But one question remains: can I also "eject" the mount just like the usual way via the file browser, or will it completely disappear?


if its in fstab, its not going to go away. Permanent until you modify it again.


Yes you can eject it just like any other kind of removable storage via the little eject button in the file browser, and then you can click on it to mount it again. If it's in fstab with the noauto option it will always be in the file browser but won't mount until you click on it. The users option is so you don't have to be root in order to mount it.



This might be an acceptable workaround for now, but I still hope that they will fix this at one point. At home where the shares don't really change, this is fine, but if you think about laptops, this is not really an option.


Maybe you could use a different file browser? One that doesn't use gvfs


When surfing around looking for alternatives, it seems GVFS is pretty widespread and not only used for network shares but also removable media and the like. Honestly it seems rational, anytime something is "virtual" it begets a performance penalty. What puzzles me is that some does not have this issue, right? Maybe it is a bug that has been fixed, introduced down the line, misaligned sectors, what have you,, or something else. If anyone wants to follow me down the rabbit hole...

My GVFS version on Xubuntu 16.04.1

$ dpkg -l | grep 'gvfs' | awk '{print $2,$3}'

gvfs:amd64 1.28.2-1ubuntu1~16.04.1
gvfs-backends 1.28.2-1ubuntu1~16.04.1
gvfs-bin 1.28.2-1ubuntu1~16.04.1
gvfs-common 1.28.2-1ubuntu1~16.04.1
gvfs-daemons 1.28.2-1ubuntu1~16.04.1
gvfs-fuse 1.28.2-1ubuntu1~16.04.1
gvfs-libs:amd64 1.28.2-1ubuntu1~16.04.1

As far as I can see on Distrowatch, Fedora 25 uses these. Did anyone have the same issue on Fedora?


E: Just want to add that I am pretty impressed with how fast you all bundled together a certainly functional solution. Salute!


On Manjaro - which is rather top edge the gvfs stuff is on 1.30.3-1 and still its not getting above 40-50, so no fix ahead.


As we know this issue has been reported as a bug, I think someone in this thread said so. It has at least been reported in 2014 to Debian

So, how do we make developers aware of this? Do we have to make bug reports to all major distributions?

I'd still like to know if anyone is NOT having this issue?

Edit: And, how do I securely store the credentials file? I've chmod 600 the file as per this random guide, but it is still not stored in the Gnome key-ring (which, by the way, is unlocked at login, so I don't know if it is any different) like GVFS credentials. Is there a glaring security risk here?


Only to glaring eyes that have your credentials already - have the SMB creds random different from your login-creds; I do not know any way to store them in the keyring (when used with mount/fstab) - a way over a encryptfs partition that only unlocks with your creds would be possible


So you mean, put the credentials file in an encrypted volume/container that unlocks at login, this way if the SSD is stolen, it will be encrypted just like the password manager storage and the key-ring and such?


yes indeed - that's probably the only "automatic" way I can imagine to realy secure the file against an attack where the disk is accessed externally.