Ubuntu Server 18.04 – Mounting remote directories with SSHFS

Getting Started with the IIS Manager in IIS

Earlier in this chapter, we took a look at several ways in which we can set up a Linux file server, using Samba and/or NFS. There’s another type of file sharing solution I haven’t mentioned yet, the SSH Filesystem (SSHFS). NFS and Samba are great solutions for designating file shares that are to be made available to other users, but these technologies may be more complex than necessary if you want to set up a temporary file-sharing service to use for a specific period of time. SSHFS allows you to mount a remote directory on your local machine, and have it treated just like any other directory. The mounted SSHFS directory will be available for the life of the SSH connection. When you’re finished, you simply disconnect the SSHFS mount.

There are some downsides when it comes to SSHFS, however. First, performance of file transfers won’t be as fast as with an NFS mount, since there’s encryption that needs to be taken into consideration as well. However, unless you’re performing really resource-intensive work, you probably won’t notice much of a difference anyway. Another downside is that you’d want to save your work regularly as you work on files within an SSHFS mount, because if the SSH connection drops for any reason, you may lose data. This logic is also true of NFS and Samba shares, but SSHFS is more of an on-demand solution and not something intended to remain connected and in place all the time.

To get started with SSHFS, we’ll need to install it:

sudo apt install sshfs 

Now we’re ready to roll. For SSHFS to work, we’ll need a directory on both your local Linux machine as well as a remote Linux server. SSHFS can be used to mount any directory from the remote server you would normally be able to access via SSH. That’s really the only requirement. What follows is an example command to mount an external directory to a local one via SSHFS. In your tests, make sure to replace┬ámy sample directories with actual directories on your nodes, as well as use a valid user account:

sshfs myuser@ /mnt/myfiles 

As you can see, the sshfs command is fairly straightforward. With this example, we’re mounting /share/myfiles on to /mnt/myfiles on our local machine. Assuming the command didn’t provide an error (such as access denied, if you didn’t have access to one of the directories on either side), your local directory should show the contents of the remote directory. Any changes you make to files in the local directory will be made to the target. The SSHFS mount will basically function in the same way as if you had mounted an NFS or Samba share locally.

When we’re finished with the mount, we should unmount it. There are two ways to do so. First, we can use the umount command as the root (just like we normally would):

sudo umount /mnt/myfiles 

Using the umount command isn’t always practical for SSHFS, though. The user that’s setting up the SSHFS link may not have root permissions, which means that he or she won’t be able to unmount it with the umount command. If you tried the umount command as a regular user, you would see an error similar to the following:

umount: /mnt/myfiles: Permission denied 

It may seem rather strange that a normal user can mount an external directory via SSHFS, but not unmount it. Thankfully, there’s a specific command a normal user can use, so we won’t need to give them root or sudo access:

fusermount -u /mnt/myfiles 

That should do it. With the fusermount command, we can unmount the SSHFS connection we set up, even without root access. The fusermount command is part of the Filesystem in Userspace (FUSE) suite, which is what SSHFS uses as its virtual filesystem to facilitate such a connection. The -u option, as you’ve probably guessed, is for unmounting the connection normally. There is also the -z option, which unmounts the SSHFS mount lazily. By lazy, I mean it basically unmounts the filesystem without any cleanup of open resources. This is a last resort that you should rarely need to use, as it could result in data loss.

Connecting to an external resource via SSHFS can be simplified by adding an entry for it in /etc/fstab. Here’s an example entry using our previous example:

myuser@    /mnt/myfiles    fuse.sshfs  rw,noauto,users,_netdev  0  0 

Notice that I used the noauto option in the fstab entry, which means that your system will not automatically attempt to bring up this SSHFS mount when it boots. Typically, this is ideal. The nature of SSHFS is to create on-demand connections┬áto external resources, and we wouldn’t be able to input the password for the connection while the system is in the process of booting anyway. Even if we set up password-less authentication, the SSH daemon may not be ready by the time the system attempts to mount the directory, so it’s best to leave the noauto option in place and just use SSHFS as the on-demand solution it is. With this /etc/fstab entry in place, any time we would like to mount that resource via SSHFS, we would only need to execute the following command going forward:

mount /mnt/myfiles 

Since we now have an entry for /mnt/myfiles in /etc/fstab, the mount command knows that this is an SSHFS mount, where to locate it, and which user account to use for the connection. After you execute the example mount command, you should be asked for the user’s SSH password (if you don’t have password-less authentication configured) and then the resource should be mounted.

SSH sure does have a few unexpected tricks up its sleeve. Not only is it the de facto standard in the industry for connecting to Linux servers, but it also offers us a neat way of transferring files quickly and mounting external directories. I find SSHFS very useful in situations where I’m working on a large number of files on a remote server but want to work on them with applications I have installed on my local workstation. SSHFS allows us to do exactly that.

Comments are closed.