A few years ago, mounting remote filesystems between linux boxes was a mystery to me. I wrote this little HowTo to help others who are trying to mount files between two systems over a network when you want a secure, encrypted tunnel for all transfers between the two systems. In another page I will discuss how to mount WINDOWS folders from Linux, mapping them to local folders on the Linux box.

The cool thing about SSHFS is that on the server side (providing the mounted resource) , any mapped WINDOWS shares are available over SSHFS (presumably mounted with a mount -t cifs command) as well as any Linux folders and any other mounted resources on the Linux server. So using ONE linux box you could mount multiple WINDOWS shares as well as mount various NFS shares to different sub-directories on the Linux server and unify all the mounts under one parent directory on the primary Linux box. Then a simple mount to the parent directory holding the various mounts explained above would offer a unified directory structure of shares all available through one file server: encrypted & secure, all with SSHFS (yay!).

Rsync and SCP are out there, I know, but they are limited in scope. Sometimes you may want to access files on a remote server for editing purposes, to access them as though they were a local resource, securely; not just copy them (like an FTP connection) or like Rsync or SCP. It is sometimes desired to have more persistent, locally available resource that offers the benefits of an encrypted, private connection while maintaining the appearance of a locally available resource between the two computers: this is where SSHFS comes into play.

These instructions are Debian-specific (though not much different under Fedora).

WARNING: Make backups of any modified files PRIOR to modifying them, use this HOWTO document at your own RISK!

SSHFS allows one to mount directories over SECSH2 protocols, as implemented by OpenSSH: Essentially mapping a drive over SSH. It uses the FUSE user-space filesystem framework project which essentially lets any program (in this case SSH) to create a virtual filesystem. Debian (Sarge, Ubuntu, etc.) users should be able to install the SSH filesystem by typing the following command.

sudo apt-get install sshfs

NOTE: In the Ubutnu 10.04, I have found that the above command is sometimes insufficient (especially on 64bit systems). If you get any errors while trying the commands on this page (such as FUSERMOUNT errors), then instead of the above command, you need to type this:

sudo aptitude install build-essential libcurl4-openssl-dev libxml2-dev libfuse-dev comerr-dev libfuse2 libidn11-dev libkadm55 libkrb5-dev libldap2-dev libselinux1-dev libsepol1-dev pkg-config fuse-utils sshfs

Installing SSHFS also creates a user group known as FUSE. You will need to add your non-root user to this group by typing

sudo usermod -a -G fuse username

Once this is done, your non-root user will be able to access the resources made available by FUSE. Graphically in Ubuntu, you could go to System->Administration->Users and Groups, select the group “fuse” and then add yourself to this group.

Once you’ve added your regular non-root user to the FUSE group, mapping the remote resource over SSH is pretty elementary. However, you will only be able to execute the sshfs command as ROOT. Any mounting of any resource by ROOT will exclude it from your regular non-root user, so to allow your non-root user access to the remote resource you will need to first tell the FUSE module to allow for the option of non-root users accessing FUSE resources. To do so you need to add an option to the /etc/fuse.conf file. Simply . . .

sudo gedit /etc/fuse.conf and add the line below (or kedit if you use KDE. On my Ubuntu system, my fuse.conf was empty, so I added this one line and that’s all the file contains) . . .


This option will allow you to use -o allow_other in your SSHFS command which will allow your non-root user access to the specific resource you’re mounting. The above line (user_allow_other) must appear on a line by itself. There is no value, just the presence of the option. Once this is saved, you can then use the -o allow_other option in your SSHFS command and it will execute properly.

There is one more system file to edit. In order for Linux to see the virtual filesystems created by FUSE, the kernel needs to be aware of the existence of the FUSE module in your MODPROBE file. Again, run your favorite text editor,

sudo gedit /etc/modules and add the line below (or kedit if you use KDE) at the end of the file add . . .


On a line by itself, this simply tells Linux to load the FUSE module on boot. This will take effect on your next reboot. However, you probably don’t want to reboot right now to load the module in your current session, so we can force linux to load the FUSE module on the fly by executing the following command as ROOT or using SUDO.

sudo modprobe fuse

This will work for the duration of your session. Once your reboot your newly-edited /etc/modules file will properly load the FUSE module and the “sudo modprobe fuse” command won’t be necessary in the future.

At this point you have all of the tools necessary to mount a remote filesystem and map it to a local folder on your local machine. The SSHFS command requires a few key pieces of information.

  1. Username (do you have access to the remote machine? if so, what username, does NOT need to be the root user)
  2. IP or hostname (what machine are you connecting to? works via name, domain or IP)
  3. remote folder (what remote folder path do you want?)
  4. local folder to use (where to you want to virtually represent the remote contents?)

An example of a command to mount a remote system, including the above key elements, would look similar to this:

sshfs user@hostname:/path/to/remote/folder /path/to/local/folder -o allow_other -p 8000

A sample with the above variables filled in might look like this . . .

sshfs john@ /home/john/reports  -o allow_other -p 8000

In the above example, John is using the “john” user to connect to (his linux box at work) and mapping the /home/john/work/reports directory on his work server to his home server locally, to /home/john/reports.

The -o option allows for his non-root user (john on his home machine) to actually access the files on his home PC (without this, he would only be able to interact with the files as the ROOT user).

The -p 8000 option is not necessary. If your work box uses the default SSH port (22) then this option is not needed. However, many servers use different ports to avoid common portscans and hack attempts by random bots, so I made up the port 8000 as an example non-standard port number.

If/when you’re done with the mounted-folder, you can simply unmount it with the umount command.

umount /home/john/reports

(unmounting the local side disconnects the localized virtual resource.)

The main SSHFS command does not need to be typed over and over, you could easily create a short text file and make it executable so you can simply type the text filename and it will execute the long command.

Again use your favorite text editor (no need to do this as root).

gedit workmount

(or any filename you like) and type your long SSHFS command, and save the file.

Once saved, from command line type the following . . . (make sure you’re in the same path as the filename otherwise you will have to specify the full path to the filename)

chmod 700 filename

This will make the text file executable (like a batch file in WINDOWS). From command line you can simply type in the future . . .


. . . and you’d be prompted for the password to the remote computer. Once entered, your share will be mounted, enjoy!