SSHFS

SSHFS is a FUSE-based filesystem client for mounting remote directories over a Secure Shell connection.

Note: This project has been archived by its developers and is no longer developed. Alternatives include the mount feature of rclone.

Installation

Install the sshfs package.

Tip:

• If you often need to mount sshfs filesystems you may be interested in using an sshfs helper, such as qsshfs^AUR, sftpman, sshmnt^AUR or fmount.py.
• You may want to use Google Authenticator providing additional security as in two-step authentication.
• SSH keys may be used over traditional password authentication.

Mounting

In order to be able to mount a directory the SSH user needs to be able to access it. Invoke sshfs to mount a remote directory:

$ sshfs [user@]host:[dir] mountpoint [options]

For example:

$ sshfs myuser@mycomputer:/remote/path /local/path -C -p 9876

Here -p 9876 specifies the port number and -C enables compression. For more options see the #Options section.

When not specified, the remote path defaults to the remote user home directory. Default user names and options can be predefined on a host-by-host basis in to simplify the sshfs usage. For more information see OpenSSH#Client usage.

SSH will ask for the password, if needed. If you do not want to type in the password multiple times a day, see SSH keys.

Unmounting

To unmount the remote system:

$ fusermount3 -u mountpoint

Example:

$ fusermount3 -u /local/path

Options

sshfs can automatically convert between local and remote user IDs. Use the option to translate the UID of the connecting user to the remote user (GID remains unchanged):

$ sshfs myuser@mycomputer:/remote/path /local/path -o idmap=user

If you need more control over UID and GID translation, look at the options , uidfile and gidfile.

A complete list of options can be found in .

Chrooting

You may want to restrict a specific user to a specific directory on the remote system. This can be done by editing :

See also SFTP chroot. For more information check the man page for , and .

Automounting

Automounting can happen on boot, or on demand (when accessing the directory). For both, the setup happens in the fstab.

On demand

With systemd on-demand mounting is possible using /etc/fstab entries.

Example:

user@host:/remote/path /local/path  fuse.sshfs noauto,x-systemd.automount,_netdev,users,idmap=user,IdentityFile=/home/user/.ssh/id_rsa,allow_other,reconnect 0 0

The important mount options here are noauto,x-systemd.automount,_netdev.

• noauto tells it not to mount at boot
• x-systemd.automount does the on-demand magic
• _netdev tells it that it is a network device, not a block device (without it "No such device" errors might happen)

On boot

An example on how to use sshfs to mount a remote filesystem through /etc/fstab

user@host:/remote/path  /local/path  fuse.sshfs  defaults,_netdev  0  0

Take for example the fstab line

llib@192.168.1.200:/home/llib/FAH  /media/FAH2  fuse.sshfs  defaults,_netdev  0  0

The above will work automatically if you are using an SSH key for the user. See Using SSH Keys.

If you want to use sshfs with multiple users, add the following option:

[e-mail]:/home/user  /media/user   fuse.sshfs    defaults,allow_other,_netdev    0  0

Again, it is important to set the _netdev mount option to make sure the network is available before trying to mount.

Secure user access

When automounting via fstab, the filesystem will generally be mounted by root. By default, this produces undesireable results if you wish access as an ordinary user and limit access to other users.

An example mountpoint configuration:

user@host:/remote/path /local/path  fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_symlinks,identityfile=/home/user/.ssh/id_rsa,allow_other,default_permissions,uid=USER_ID_N,gid=USER_GID_N 0 0

Summary of the relevant options:

• allow_other - Allow other users than the mounter (i.e. root) to access the share.
• default_permissions - Allow kernel to check permissions, i.e. use the actual permissions on the remote filesystem. This allows prohibiting access to everybody otherwise granted by allow_other.
• uid, gid - set reported ownership of files to given values; uid is the numeric user ID of your user, gid is the numeric group ID of your user.

Troubleshooting

Checklist

Read OpenSSH#Checklist first. Further issues to check are:

1. Is your SSH login sending additional information from server's file e.g.? This might confuse SSHFS. You should temporarily deactivate server's file:
2. Keep in mind that most SSH related troubleshooting articles you will find on the web are not systemd related. Often /etc/fstab definitions wrongly begin with instead of using the syntax
3. Check that the owner of server's source directory and content is owned by the server's user.
4. The server's user ID can be different from the client's one. Obviously both user names have to be the same. You just have to care for the client's user IDs. SSHFS will translate the UID for you with the following mount options:
5. Check that the client's target mount point (directory) is owned by the client user. This directory should have the same user ID as defined in SSHFS's mount options.
6. Check that the client's mount point (directory) is empty. By default you cannot mount SSHFS directories to non-empty directories.

Connection reset by peer

• If you are trying to access the remote system with a hostname, try using its IP address, as it can be a domain name resolving issue. Make sure you edit with the server details.
• Make sure your user can log into the server (especially when using AllowUsers).
• Make sure is enabled in on the remote system.
• If you are using a non-default key name and passing it as , this will not work. You have to use , with the full path to the key.
• If your /root/.ssh/config/ is a symlink, you will be getting this error as well. See this serverfault topic
• Adding the option (as in ) can help in resolving the issue.
• If that does not reveal anything useful, you might also try adding the option .
• If you are trying to sshfs into a router running DD-WRT or the like, there is a solution here. (Note that the option can be used to the sshfs command instead of patching dropbear).
• If you see this only on boot, it may be that systemd is attempting to mount prior to a network connection being available. Enabling the appropriate wait-online service for your network manager fixes this.
• Old Forum thread: sshfs: Connection reset by peer.

Remote host has disconnected

If you receive this message directly after attempting to use sshfs:

• First make sure that the remote machine has sftp installed! It will not work, if not.
• Then, check that the path of the in on the remote machine is valid.

fstab mounting issues

To get verbose debugging output, add the following to the mount options:

ssh_command=ssh\040-vv,sshfs_debug,debug

Note: Here, \040 represents a space which fstab uses to separate fields.

To be able to run and see the debug output, remove the following:

 noauto,x-systemd.automount

Some directories are empty

sshfs by default does not support symlinks. If those directories happened to be symlinks, use:

$ sshfs user@host:/remote/path /local/path -o follow_symlinks

Files not refreshed

If you see old content on remote, consider using option :

$ sshfs user@host:/remote/path /local/path -o dir_cache=no

Limited transfer on fast network

If you observe transfer than is lower than your network capabilities and high CPU usage on the party where files are copied from, disable compression (remove -C option or set ).

See also

• How to mount chrooted SSH filesystem, with special care with owners and permissions questions.