You can use sshfs to mount a remote system - accessible via SSH - to a local folder, so you will be able to do any operation on the mounted files with any tool (copy, rename, edit with vim, etc.). Using sshfs instead of shfs is generally preferred as a new version of shfs hasn't been released since 2004.
- 1 Installation
- 2 Usage
- 3 Chrooting
- 4 Helpers
- 5 Automounting
- 6 Options
- 7 Troubleshooting
- 8 See also
First a kernel module should be loaded, so as root, do:
# modprobe fuse
Check if fuse is active:
systemctl list-units --all|grep fuse
sys-module-fuse.device loaded active plugged /sys/module/fuse
You will use the command
sshfs. To mount a remote directory:
$ sshfs USERNAME@HOSTNAME_OR_IP:/PATH LOCAL_MOUNT_POINT SSH_OPTIONS
$ sshfs sessy@mycomputer:/home/sessy /mnt/sessy -C -p 9876
9876 is the port number.
Also, make certain that before connecting, you set the file permissions for any local client folders you will attempt to mount a remote directory to. I.e., do not have everything owned by root! You could also run the mount command as a regular user, it should work as well.
To unmount the remote system:
$ fusermount -u LOCAL_MOUNT_POINT
$ fusermount -u /mnt/sessy
You may want to jail a (specific) user to a directory.To do this, edit
..... Match User someuser ChrootDirectory /chroot/%u ForceCommand internal-sftp #to restrict the user to sftp only AllowTcpForwarding no X11Forwarding no .....
If you often need to mount sshfs filesystems you may be interested in using an sshfs helper, such as sftpman.
It provides a command-line and a GTK frontend, to make mounting and unmounting a simple one click/command process.
Automounting can happen on boot, or on demand (when accessing the directory). For both, the setup happens in
With systemd on-demand mounting is possible using
user@host:/remote/folder /mount/point 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's a network device, not a block device (without it "No such device" errors might happen)
An example on how to use sshfs to mount a remote filesystem through
USERNAME@HOSTNAME_OR_IP:/REMOTE/DIRECTORY /LOCAL/MOUNTPOINT fuse.sshfs defaults,_netdev 0 0
Take for example the fstab line
firstname.lastname@example.org:/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:
email@example.com:/home/user /media/user fuse.sshfs defaults,allow_other,_netdev 0 0
Again, it's important to set the _netdev mount option to make sure the network is available before trying to mount.
Secure user access
When automounting via
/etc/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:
USERNAME@HOSTNAME_OR_IP:/REMOTE/DIRECTORY /LOCAL/MOUNTPOINT fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/USERNAME/.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.
sshfs can automatically convert your local and remote user IDs.
Add the idmap option with user value to translate UID of connecting user:
# sshfs -o idmap=user sessy@mycomputer:/home/sessy /mnt/sessy -C -p 9876
If you have a different login on the remote system, it can still work if you provide the ssh standard option User:
# sshfs -o idmap=user,User=sessy2 sessy@mycomputer:/home/sessy /mnt/sessy -C -p 9876
(I've used first form, second is based on docs, so YMMV, but it should at least be close)
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 solving issue. Make sure you edit
/etc/hostswith the server details.
- If you are using non-default key names and are passing it as
-i .ssh/my_key, this won't work. You have to use
-o IdentityFile=/home/user/.ssh/my_key, with the full path to the key.
- Adding the option '
sshfs_debug' (as in '
sshfs -o sshfs_debug user@server ...') can help in resolving the issue.
- If you're trying to sshfs into a router running DD-WRT or the like, there is a solution here. (note that the -osftp_server=/opt/libexec/sftp-server option can be used to the sshfs command in stead of patching dropbear)
- Forum thread: sshfs: Connection reset by peer
Remote host has disconnected
- If you recieve this message directly after attempting to use sshfs, try checking the path of your Subsystem listed in /etc/ssh/sshd_config on the remote machine to see if it is valid.
- You can check this by typing
find / grep XXXXwhere XXXX is the path of the subsystem
Thunar has issues with FAM and remote file access
If you experience remote folders not displaying, getting kicked back to the home directory, or other remote file access issues through Thunar, replace fam with. Gamin is derived from fam.
Shutdown hangs when sshfs is mounted
Systemd may hang on shutdown if an sshfs mount was mounted manually and not unmounted before shutdown. To solve this problem, create this file (as root):
[Unit] After=network.target [Service] RemainAfterExit=yes ExecStart=-/bin/true ExecStop=-/usr/bin/pkill sshfs [Install] WantedBy=multi-user.target
Then enable the service:
systemctl enable killsshfs.service