Often one wants a shared access to files across machines. Traditionally one uses the network file system (nfs). The network file server works as follows: There is an nfs server that exports some directories in its filesystem hiearchy to various nfs clients that mount these directory over the network into their file system hierarchy. As a result, each of the clients shares the directories exported by the nfs server.
However a lot of times you just have to mount a directory from a server to your local computer and in these cases NFS it’s not so useful, sshfs it’s much better
Sshfs is a filesystem client based on the SSH File Transfer Protocol. Since most SSH servers already support this protocol it is very easy to set up: i.e. on the server side there’s nothing to do. On the client side mounting the filesystem is as easy as logging into the server with ssh.
How it works.
Sshfs is a userspace file system (fuse) that works over ssh, or rather sftp. Fuse is an implementation of filesystem primitives in userspace rather than in kernel space. This essentially means that users can mount and unmount file system without having to be root. Sshfs makes use of the sftp subsystem to do the remote file system operations. Thus all the great features of ssh holds true, i.e. key based authentication, use of ssh-agents.
$ aptitude install sshfs # as root. $ sudo aptitude install sshfs # if you are on Unbutu $ pacman -S sshfs # as root on an Arch machine
On Fedora it looks like it is called
fuse-sshfs so something like this should work.
$ yum install fuse-sshfs
How to mount a filesystem
Once sshfs is installed running it is very simple:
> sshfs hostname: mountpoint
Note, that it’s recommended to run it as user, not as root. For this to work the mountpoint must be owned by the user. If the username is different on the host you are connecting to, then use the “username@host:” form. If you need to enter a password sshfs will ask for it (actually it just runs ssh which ask for the password if needed). You can also specify a directory after the “:”. The default is the home directory.
$ sshfs [email protected]:/home/linuxaria /mnt/linuxaria.com -C -p 2222
2222 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!
To unmount the filesystem:
> fusermount -u mountpoint
Automounting on Startup on Debian/Ubuntu:
Add a line similar to this one to your /etc/fstab :
sshfs#$USER@far:/projects /home/$USER/far_projects fuse defaults,idmap=user 0 0
Note that you have to change $USER to your login name when editing fstab, but it is not necessary when typing commands (the shell does it for you in that case). The idmap=user option ensures that files owned by the remote user are owned by the local user. If you don’t use idmap=user, files in the mounted directory might appear to be owned by someone else, because your computer and the remote computer have different ideas about the numeric user ID associated with each user name. idmap=user will not translate UIDs for other users.
Another solution would be to put the following line in your crontab (edit
/etc/crontab with sudo privileges):
@reboot sshfs [email protected]:/dir/dir /home/username/mount/xxx
But since ubuntu’s password manager is not present when the command is run you need to use a password-less private/public key pair to authenticate with the ssh server in question (or a similar method of authentication). This would mount it on every reboot.
Using the GUI
Alternatively you can mount a directory over SSHFS using the Gnome “Connect to Server” tool in the desktop Places menu. In the tool, set the service type to SSH and fill in the boxes as needed. If a password is required when connecting then you will be prompted for it. Unmounting a SSHFS connection is the same as for any other volume. Open the File Browser (Nautilus). In the Places panel on the left click the arrow next to the SSHFS mount you want to disconnect or right-click it and select “Unmount”.
Automounting on Arch-Linux (or systemd systems in general)
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)
USERNAME@HOSTNAME_OR_IP:/REMOTE/DIRECTORY /LOCAL/MOUNTPOINT fuse.sshfs defaults,_netdev 0 0
Take for example the fstab line
[email protected]:/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.
Ssh is working but not sshfs.
A common error that people have reported is that ssh works but sshfs fails. If this happens, check whether your sftp subsystem is working. Most probably this too would fail or work incorrectly. One of the main reasons why sshfs/sftp does not work is because your startup scripts in the remote machine prints stuff on the screen. To check this out, try the following command.
$ ssh ppk@remote /bin/true
If this command produces any output then you are in trouble. You have to fix your startup script in your remote machine —
.bashrc , if you are using bash as your default shell. The startup script should check whether the standard output is a terminal before it outputs something. For this protect your output generating commands inside a
test -t 1 block as follows
$ cat .bash_profile if [ -t 1 ] # Check if stdout is connected to a terminal then echo "The answer is 42" fi