Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have been using sshfs to work remotely, but it is really slow and annoying, particularly when I use eclipse on it.

Is there any faster way to mount the remote file system locally? My no.1 priority is speed.

Remote machine is Fedora 15, local machine is Ubuntu 10.10. I can also use Windows XP locally if necessary.

share|improve this question

migrated from stackoverflow.com Oct 8 '11 at 3:17

This question came from our site for professional and enthusiast programmers.

8 Answers 8

up vote 5 down vote accepted

sshfs is using the SSH file transfer protocol, which means encryption.

If you just mount via NFS, it's of course faster, because not encrypted.

are you trying to mount volumes on the same network? then use NFS.

share|improve this answer
It's not slow because of the encryption, it's slow because it's FUSE and it keeps checking the file system state. –  w00t May 19 '13 at 13:40
@w00t I don't think that it's FUSE slowing it down, and not the encryption. Changing the encryption to arcfour sped it up for me, whereas using scp was just as slow as sshfs. –  Sparhawk Sep 28 '13 at 4:57
@Sparhawk there's a difference between throughput and latency. FUSE gives you pretty high latency because it has to check the filesystem state a lot using some pretty inefficient means. arcfour gives you good throughput because the encryption is simpler. In this case latency is most important because that's what causes the editor to be slow at listing and loading files. –  w00t Sep 29 '13 at 11:16
@w00t. Ah okay. Good points. –  Sparhawk Sep 29 '13 at 12:42

Besides already proposed solutions of using Samba/NFS, which are perfectly valid, you could also achieve some speed boost sticking with sshfs by using quicker encryption (authentication would be as safe as usual, but transfered data itself would be easier to decrypt) by supplying -o Ciphers=arcfour option to sshfs. It is especially useful if your machine has weak CPU.

share|improve this answer
-oCipher=arcfour made no difference in my tests with a 141 MB file created from random data. –  Sparhawk Sep 28 '13 at 4:39
That's because there were multiple typos in the command. I've edited it. I noticed a 15% speedup from my raspberry pi server. (+1) –  Sparhawk Sep 28 '13 at 4:56

If you need to improve the speed for sshfs connections, try these options:


command would be:

sshfs remote:/path/to/folder local -oauto_cache,reconnect,defer_permissions
share|improve this answer
Thanks, worked for me! Had to remove defer_permissions though (unknown option). –  Mathieu Rodic Mar 10 at 11:35

NFS should be faster. How remote is the filesystem? If it's over the WAN, you might be better off just syncing the files back and forth, as opposed to direct remote access.

share|improve this answer

SSHFS is really slow because it transfers the file contents even if it does not have to (when doing cp). I reported this upstream and to Debian, but no response :/

share|improve this answer

Either NFS or Samba if you have large files. Using NFS with something like 720p Movies and crap is really a PITA. Samba will do a better job, tho i dislike Samba for a number of other reasons and i wouldn't usually recommend it.

For small files, NFS should be fine.

share|improve this answer

If speed is of the essence, why not consider Rsync? The trade-off is in space utilization.

A good distributed vcs like GIT can also be an alternative in some cases.

share|improve this answer

Login as root.

Access your top level directory, by using "cd /".

Then ensure that you have a mount folder created or create one using "mkdir folder_name".

After that, simply use "mount x.x.x.x:/remote_mount_directory /local_mount_directory.

if everything worked on your end, before this you should have a successful mount. You might want to check and make sure the destination directory is shared by using the "exportfs" command to gurantee they are able to be found.

Hope this helps. This is not from a lvie environment, it has been tested on a LAN using VMware and Fedora 16.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.