Cool User File Systems, Part 1: SSHFS

In keeping with our current theme of cool user-space file systems, this article examines the first user-space file system I ever used: SSHFS. SSHFS has a client that can mount and interact with a remote file system as though the file system were local. It uses sftp so it’s as secure as sftp is (I’m not a security expert so I can’t comment on the security of ssh). SSHFS can be very handy for working with remote file systems instead of copying files back and forth from remote systems or having to worry about a shared file system. People have even used it for making backups.

This article is just a quick overview of SSHFS because there are a very large number of SSHFS howto’s for various Linux distributions (Google is your friend). While the basics of installing and running SSHFS are covered here, the various howto’s are much more comprehensive.

Installing SSHFS

Installing SSHFS is actually a pretty easy affair. The first step for any FUSE based file system is to make sure that FUSE itself is included in the kernel or as a module. Many distributions already come with FUSE pre-built in the kernel. There are multiple ways to check if FUSE has been built. For example, on my Ubuntu 8.10 laptop I can look for the module in the latest kernel:

laytonjb@laytonjb-laptop:~$ ls -lsa /lib/modules/2.6.27-17-generic/kernel/fs/fuse
total 96
 4 drwxr-xr-x  2 root root  4096 2010-03-21 16:42 .
 4 drwxr-xr-x 53 root root  4096 2010-03-21 16:42 ..
88 -rw-r--r--  1 root root 83200 2010-03-11 23:57 fuse.ko

So you can see that FUSE has been built as a module (.ko) for the kernel since the file exists. You can also check if the kernel module is loaded by the kernel.

laytonjb@laytonjb-laptop:~$ /sbin/lsmod | grep -i fuse
fuse                   60956  3

These are just two ways you can check if FUSE has been built for your kernel. Another way is to install the kernel source for your distribution and then look at the kernel configuration, “.config”, in the kernel source directory and you can check if FUSE has been added to the kernel itself or as a module.

If you need to build the FUSE module for your running system you will need to follow the directions on the FUSE homepage. But basically it consists of the common steps one uses to build almost any open-source package.

$ ./configure
$ make
$ make install

These steps build a kernel module for the currently running kernel but only if you have the source for your latest kernel and the “configure” script can find it (be sure to do the last step, “make install”, as root).

Once FUSE is installed and working the next step is to install SSHFS. You can install it using the package management tools for your distribution or you can build it from source. It too has the same simple build steps of many open-source applications.

$ ./configure
$ make
$ make install

where the last step is performed as root. Just be sure to read the SSHFS page for package prerequisites. In particular for the recent versions (as of the writing of this article), you will need glib2.

As an example for this article, I will be using SSHFS on my laptop that is running Ubuntu 8.10 and a remote file system. For Ubuntu 8.10, you will need to install glib2 as well as sshfs 2.02-2 (the latest version from the SSHFS homepage is 2.2) which is easily accomplished using the Synaptic package manager.

At this point FUSE and SSHFS should be installed and we’re ready to use SSHFS.

Using SSHFS

I’m going to use a remote file system I have on a system that is not under my control (it is administered by someone else) that I can access only via ssh (and scp/sftp). The SSHFS webpage recommends not mounting the remote file system as root but instead as a user. So I will mount the remote file system in a directory (mount point) in my home account on the laptop. In particular, I will mount the file system as SSHFS_TEST on my laptop.

The command to mount the remote file system is simple,

$ sshfs remote_system: mount_point

where remote_system is the name of the remote system. If you have a different login on the remote system compared to your local systems then you need to use “remote_system” in the form, “user@remote_system”.

For this particular example, the screen shot to mount the remote system is below.

laytonjb@laytonjb-laptop:~$ sshfs [system]:[home_root]/laytonjb /home/laytonjb/SSHFS_TEST
Password:

I have removed the details to protect the innocent. The term, [system], is the name of the system, and [home_root] is the full root directory to my account on the remote system except for my login name. The last term, “/home/laytonjb/SSHFS_TEST”, is the local mount point. Note that you may have to give your password when performing the mount but after that you should not have to use your password.

If you have problems with SSHFS, then you may have problems with ssh. If you can’t mount the file system or if you get an error, you can check the problem(s) by just using ssh to the remote system. You should also check scp and sftp to make sure they are working.

Now that the file system is mounted, let’s just do a simple “ls” to check that we can access the data.

laytonjb@laytonjb-laptop:~$ ls -s SSHFS_TEST
total 44
24 configure.wrf   4 example_woodcrest  16 Makefile

The remote system has just a few files, but I can easily access them by any application that is POSIX compliant. For example, I could use “vi” to edit the file or I could use the normal command line tools, “cp”, “ls”, “mv”, “rm”, etc., to manipulate the files.

As you can see, it’s pretty easy to use SSHFS. Once it’s installed mounting remote file systems is fairly easy for any user to accomplish using their own home account.

There are a huge number of articles describing how to setup SSHFS and how it can be used. Remember that SSHFS is based on ssh so there are a number of articles on how to configure ssh to not require passwords during mount. For example, there is a good article on how to configure PAM (Pluggable Authentication Modules) and SSHFS to not use ssh passwords.

Perhaps somewhat surprisingly there are a number of article about using SSHFS as part of a backup process. For example, this article talks about how to automate backups using SSHFS.

Another group of articles is how to use SSHFS with Windows for mounting Windows volumes. For example, this article explains how to mount remote Windows volumes on Linux desktops.

But one thing to remember about SSHFS is that it uses ssh underneath so do not expect good performance from it. For example, it can be appealing to replace nfs with SSHFS since users can mount remote file systems very easily, perhaps even in HPC systems. But ssh will have to encrypt the data before sending it and then decrypt it on the receiving side, using CPU cycles and reducing throughput. But if performance is perhaps not the primary motivation for SSHFS then it is definitely something worth considering.

Summary

SSHFS was the first userspace file system I used. Years ago it allowed me to mount remote file systems on my desktop so I could easily copy, edit, and manipulate the files. It was a wonderful tool that made my life easier by far and I still use it today.

SSHFS is very easy to configure once FUSE is configured and installed. Most distributions today already have FUSE configured and installed so that usually isn’t a problem. But if you build your own kernels like I tend to do, you will need to make sure that FUSE is configured.

SSHFS is just one wonderful example of a user-space file system based on FUSE. If you have a remote file system you need to access then SSHFS is the way to go.