Difference between revisions of "SSHFS"

From ArchWiki
Jump to: navigation, search
m (sshfs doesn't need root)
(Shutdown hangs when sshfs is mounted: does not hang for me - fix your systemd configuration)
 
(101 intermediate revisions by 39 users not shown)
Line 1: Line 1:
 +
[[Category:File systems]]
 
[[Category:Secure Shell]]
 
[[Category:Secure Shell]]
 +
[[Category:Network sharing]]
 +
[[es:SSHFS]]
 
[[it:Sshfs]]
 
[[it:Sshfs]]
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.
+
[[ja:Sshfs]]
 +
[[ru:SSHFS]]
 +
[[zh-hans:SSHFS]]
 +
{{Related articles start}}
 +
{{Related|SCP and SFTP}}
 +
{{Related|SFTP chroot}}
 +
{{Related|Pure-FTPd}}
 +
{{Related|SSH}}
 +
{{Related|sftpman}}
 +
{{Related articles end}}
 +
 
 +
[https://github.com/libfuse/sshfs SSHFS] is a FUSE-based filesystem client for mounting directories over [[SSH]].
  
 
== Installation ==
 
== Installation ==
To install the needed packages, do:
 
# pacman -S sshfs
 
This should install {{Pkg|fuse}} and {{Pkg|sshfs}}, and maybe other packages.
 
  
== Usage ==
+
[[Install]] the {{Pkg|sshfs}} package.
First a kernel module should be loaded, so as ''root'', do:
+
 
# modprobe fuse
+
{{Tip|If you often need to mount sshfs filesystems you may be interested in using an sshfs helper, such as {{AUR|qsshfs}}, [[sftpman]], {{AUR|sshmnt}} or [https://github.com/lahwaacz/Scripts/blob/master/fmount.py fmount.py].}}
 +
 
 +
=== Mounting ===
  
Check if fuse is active.
+
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:
#systemctl list-units --all|grep fuse
 
sys-module-fuse.device    loaded active  plugged      /sys/module/fuse
 
  
 +
$ sshfs ''[user@]host:[dir] mountpoint [options]''
  
=== Mounting ===
 
You will use the command {{Ic|sshfs}}. To mount a remote directory:
 
$ sshfs ''USERNAME@HOSTNAME_OR_IP:/PATH LOCAL_MOUNT_POINT SSH_OPTIONS''
 
 
For example:
 
For example:
$ sshfs sessy@mycomputer:/home/sessy /mnt/sessy -C -p 9876
 
Where {{Ic|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.
+
$ sshfs myuser@mycomputer:/remote/path /local/path -C -p 9876
 +
 
 +
Here {{ic|-p 9876}} specifies the port number and {{ic|-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 {{ic|~/.ssh/config}} to simplify the ''sshfs'' usage. For more information see [[Secure Shell#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]].
  
SSH will ask for the password, if needed. If you do not want to type in your password 49 times a day, then read this: [http://linuxmafia.com/~karsten/Linux/FAQs/sshrsakey.html How to Use RSA Key Authentication with SSH] or [[Using SSH Keys]].
+
{{Tip|[[Google Authenticator]] can be used with sshfs for additional security.}}
  
 
=== Unmounting ===
 
=== Unmounting ===
 +
 
To unmount the remote system:
 
To unmount the remote system:
  $ fusermount -u ''LOCAL_MOUNT_POINT''
+
 
 +
  $ fusermount -u ''local_mount_point''
 +
 
 
Example:
 
Example:
 +
 
  $ fusermount -u /mnt/sessy
 
  $ fusermount -u /mnt/sessy
  
== Tips ==
+
== Options ==
To quickly mount a remote dir, do some file-management and unmount it, put this in a script:
+
 
  sshfs USERNAME@HOSTNAME_OR_IP:/PATH LOCAL_MOUNT_POINT SSH_OPTIONS''
+
''sshfs'' can automatically convert between local and remote user IDs. Use the {{ic|1=idmap=user}} option to translate the UID of the connecting user to the remote user {{ic|myuser}} (GID remains unchanged):
mc ~ LOCAL_MOUNT_POINT
+
 
fusermount -u LOCAL_MOUNT_POINT''
+
  $ sshfs myuser@mycomputer:/remote/path /local/path -o idmap=user
  
This will mount the remote directory, launch MC, and unmount it when you exit.
+
If you need more control over UID and GID translation, look at the options {{ic|1=idmap=file}}, {{ic|uidfile}} and {{ic|gidfile}}.
  
==Chrooting==
+
== Chrooting ==
  
You may want to jail a (specific) user to a directory.To do this, edit {{ic|/etc/ssh/sshd_config}}:
+
You may want to restrict a specific user to a specific directory on the remote system. This can be done by editing {{ic|/etc/ssh/sshd_config}}:
  
{{hc|/etc/ssh/sshd_config|.....
+
{{hc|/etc/ssh/sshd_config|
Match User someuser  
+
.....
       ChrootDirectory /chroot/%u
+
Match User ''someuser''
       ForceCommand internal-sftp #to restrict the user to sftp only
+
       ChrootDirectory ''/chroot/%u''
 +
       ForceCommand internal-sftp
 
       AllowTcpForwarding no
 
       AllowTcpForwarding no
 
       X11Forwarding no
 
       X11Forwarding no
.....}}
+
.....
 +
}}
 +
 
 +
{{Note|The chroot directory '''must''' be owned by root, otherwise you will not be able to connect.}}
 +
 
 +
See also [[SFTP chroot]]. For more information check the {{man|5|sshd_config}} man page for {{ic|Match}}, {{ic|ChrootDirectory}} and {{ic|ForceCommand}}.
 +
 
 +
== Automounting ==
 +
 
 +
Automounting can happen on boot, or on demand (when accessing the directory). For both, the setup happens in the [[fstab]].
 +
 
 +
{{Note|Keep in mind that automounting is done through the root user, therefore you cannot use hosts configured in {{ic|.ssh/config}} of your normal user.
  
{{Note|The chroot directory '''must''' be owned by root, otherwise you will not be able to connect.
+
To let the root user use an SSH key of a normal user, specify its full path in the {{ic|IdentityFile}} option.
For more info check the manpages for {{Ic|Match, ChrootDirectory}} and {{Ic|ForceCommand}}.}}
 
  
==Helpers==
+
'''And most importantly''', use each sshfs mount at least once manually '''while root''' so the host's signature is added to the {{ic|/root/.ssh/known_hosts}} file.
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.
+
=== On demand ===
  
==Automounting==
+
{{Expansion|Is there a way to make this work with a passphrase-protected private key? E.g. it prompts for the passphrase at first access. Alternatively, clearly state that it's not possible and why.}}
Automounting can happen on boot, or on demand (when accessing the directory). For both, the setup happens in {{ic|/etc/[[fstab]]}}.
 
  
===On demand===
+
With systemd on-demand mounting is possible using {{ic|/etc/fstab}} entries.
With systemd on-demand mounting is possible using /etc/fstab entries.
 
  
 
Example:
 
Example:
 +
 
  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
 
  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''.
 
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)
 
  
===On boot===
+
* ''noauto'' tells it not to mount at boot
An example on how to use sshfs to mount a remote filesystem through {{ic|/etc/[[fstab]]}}
+
* ''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)
 +
 
 +
{{Note|After editing {{ic|/etc/fstab}}, (re)start the required service: {{ic|systemctl daemon-reload && systemctl restart <target>}} where {{ic|<target>}} can be found by running {{ic|systemctl list-unit-files --type automount}} }}
 +
 
 +
{{Tip|{{AUR|autosshfs-git}} do not require editing {{ic|/etc/fstab}} to add a new mountpoint. Instead, regular users can create one by simply attempting to access it (with e. g. something like {{ic|ls ~/mnt/ssh/[user@]yourremotehost[:port]}}). {{AUR|autosshfs-git}} uses AutoFS. Users need to be enabled to use it with {{ic|autosshfs-user}}.}}
 +
 
 +
=== On boot ===
 +
 
 +
An example on how to use sshfs to mount a remote filesystem through {{ic|/etc/fstab}}
 +
 
 
  USERNAME@HOSTNAME_OR_IP:/REMOTE/DIRECTORY  /LOCAL/MOUNTPOINT  fuse.sshfs  defaults,_netdev  0  0
 
  USERNAME@HOSTNAME_OR_IP:/REMOTE/DIRECTORY  /LOCAL/MOUNTPOINT  fuse.sshfs  defaults,_netdev  0  0
  
 
Take for example the ''fstab'' line
 
Take for example the ''fstab'' line
 +
 
  llib@192.168.1.200:/home/llib/FAH  /media/FAH2  fuse.sshfs  defaults,_netdev  0  0
 
  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]].
 
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:
 
If you want to use sshfs with multiple users:
 +
 
  user@domain.org:/home/user  /media/user  fuse.sshfs    defaults,allow_other,_netdev    0  0
 
  user@domain.org:/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.
+
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:
 +
 
 +
USERNAME@HOSTNAME_OR_IP:/REMOTE/DIRECTORY  /LOCAL/MOUNTPOINT  fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_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.
 +
 
 +
== Troubleshooting ==
 +
 
 +
=== Checklist ===
 +
 
 +
Read the [[Secure_Shell#Checklist|SSH Checklist]] Wiki entry first. Further issues to check are:
 +
 
 +
1. Is your SSH login sending additional information from server's {{ic|/etc/issue}} file e.g.? This might confuse SSHFS. You should temporarily deactivate server's {{ic|/etc/issue}} file:
 +
 
 +
$ mv /etc/issue /etc/issue.orig
 +
 
 +
2. Keep in mind that most SSH related troubleshooting articles you will find on the web are '''not''' Systemd related. Often {{ic|/etc/fstab}} definitions wrongly begin with {{ic|''sshfs#''user@host:/mnt/server/folder ... fuse ...}} instead of using the syntax {{ic|user@host:/mnt/server/folder ... fuse.''sshfs'' ... ''x-systemd'', ...}}.
 +
 
 +
3. Check that the owner of server's source folder and content is owned by the server's user.
 +
 
 +
$ chown -R USER_S: /mnt/servers/folder
 +
 
 +
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:
 +
 
 +
uid=''USER_C_ID'',gid=''GROUP_C_ID''
 +
 
 +
5. Check that the client's target mount point (folder) is owned by the client user. This folder should have the same user ID as defined in SSHFS's mount options.
 +
 
 +
$ chown -R USER_C: /mnt/client/folder
 +
 
 +
6. Check that the client's mount point (folder) is empty. By default you cannot mount SSHFS folders to non-empty folders.
 +
 
 +
7. If you want to automount SSH shares by using an SSH public key authentication (no password) via {{ic|/etc/fstab}}, you can use this line as an example:
 +
 
 +
''USER_S''@''SERVER'':/mnt/on/server      /nmt/on/client        fuse.sshfs      x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/''USER_C''/.ssh/id_rsa,allow_other,default_permissions,uid=''USER_C_ID'',gid=''GROUP_C_ID'',umask=0  0 0
 +
 
 +
Considering the following example settings ...
  
==Options==
+
SERVER = Server host name (serv)
 +
USER_S = Server user name (pete)
 +
USER_C = Client user name (pete)
 +
USER_S_ID = Server user ID (1004)
 +
USER_C_ID = Client user ID (1000)
 +
GROUP_C_ID = Client user's group ID (100)
  
sshfs can automatically convert your local and remote user IDs.
+
you get the client user's ID and group ID with
  
Add the ''idmap'' option with ''user'' value to translate UID of connecting user:
+
$ id USERNAME
  
# sshfs -o idmap=user sessy@mycomputer:/home/sessy /mnt/sessy -C -p 9876
+
this is the final SSHFS mount row in {{ic|/etc/fstab}};
  
If you have a different login on the remote system, it can still work if you provide the ssh standard option ''User'':
+
pete@serv:/mnt/on/server      /nmt/on/client        fuse.sshfs      x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/pete/.ssh/id_rsa,allow_other,default_permissions,uid=1004,gid=1000,umask=0  0 0
  
# sshfs -o idmap=user,User=sessy2 sessy@mycomputer:/home/sessy /mnt/sessy -C -p 9876
+
8. If you know another issue for this checklist please add it the list above.
  
(I've used first form, second is based on docs, so YMMV, but it should at least be close)
+
=== Connection reset by peer ===
  
== Troubleshooting ==
 
===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 {{ic|/etc/hosts}} with the server details.
 
* 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 {{ic|/etc/hosts}} with the server details.
* If you are using non-default key names and are passing it as {{Ic|-i .ssh/my_key}}, this won't work. You have to use {{Ic|-o IdentityFile<nowiki>=</nowiki>/home/user/.ssh/my_key}}, with the full path to the key.
+
* If you are using non-default key names and are passing it as {{ic|-i .ssh/my_key}}, this will not work. You have to use {{ic|-o IdentityFile<nowiki>=</nowiki>/home/user/.ssh/my_key}}, with the full path to the key.
* Adding the option '{{Ic|sshfs_debug}}' (as in '{{Ic|sshfs -o sshfs_debug user@server ...}}') can help in resolving the issue.
+
* If your {{ic|/root/.ssh/config}} is a symlink, you will be getting this error as well. See [http://serverfault.com/questions/507748/bad-owner-or-permissions-on-root-ssh-config this serverfault topic]
* If you're trying to sshfs into a router running DD-WRT or the like, there is a solution [http://www.dd-wrt.com/wiki/index.php/SFTP_with_DD-WRT here].
+
* Adding the option '{{ic|sshfs_debug}}' (as in '{{ic|sshfs -o sshfs_debug user@server ...}}') can help in resolving the issue.
* Forum thread: [https://bbs.archlinux.org/viewtopic.php?id=27613 sshfs: Connection reset by peer]
+
* If that doesn't reveal anything useful, you might also try adding the option '{{ic|debug}}'
 +
* If you are trying to sshfs into a router running DD-WRT or the like, there is a solution [http://www.dd-wrt.com/wiki/index.php/SFTP_with_DD-WRT here]. (note that the -osftp_server=/opt/libexec/sftp-server option can be used to the sshfs command in stead of patching dropbear)
 +
* Old Forum thread: [https://bbs.archlinux.org/viewtopic.php?id=27613 sshfs: Connection reset by peer]
 +
* Make sure your user can log into the server (especially when using AllowUsers)
 +
* Make sure {{ic|Subsystem sftp /usr/lib/ssh/sftp-server}} is enabled in {{ic|/etc/ssh/sshd_config}}.
 +
 
 +
{{Note| When providing more than one option for sshfs, they must be comma separated. Like so: '{{ic|sshfs -o sshfs_debug,IdentityFile<nowiki>=</nowiki></path/to/key> user@server ...}}')}}
 +
 
 +
=== 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 {{ic|Subsystem sftp}} in {{ic|/etc/ssh/sshd_config}} on the remote machine is valid.
 +
 
 +
=== Freezing apps (e.g. Gnome Files, Gedit) === 
 +
 
 +
{{Warning|This prevents the recently used file list from being populated and may lead to possible write errors.}}
 +
 
 +
If you experience freezing/hanging (stopped responding) applications, you may need to disable write-access to the {{ic|~/recently-used.xbel}} file.
 +
 
 +
# chattr +i /home/USERNAME/.local/share/recently-used.xbel
 +
 
 +
See the following [https://bugs.archlinux.org/task/40260 bug report] for more details and/or solutions.
 +
 
 +
=== fstab mounting issues ===
 +
 
 +
To get verbose debugging output, add the following to the mount options:
  
{{Note| When providing more than one option for sshfs, they must be comma separated. Like so: '{{Ic|sshfs -o sshfs_debug,IdentityFile<nowiki>=</nowiki></path/to/key> user@server ...}}')}}
+
ssh_command=ssh\040-vv,sshfs_debug,debug
===Remote host has disconnected===
+
{{Note|Here, {{ic|\040}} represents a space which fstab uses to separate fields.}}
* 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.
 
{{Note|The default value for Subsystem should be {{ic|Subsystem sftp /usr/lib/ssh/sftp-server}}}}
 
* you can check this by typing {{Ic|find /  grep XXXX}} where XXXX is the path of the subsystem
 
  
===Thunar has issues with FAM and remote file access=== 
+
To be able to run {{ic|mount -av}} and see the debug output, remove the following:
 +
  noauto,x-systemd.automount
  
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 {{Pkg|gamin}}.  Gamin is derived from fam.
+
== See also ==
  
==See also==
 
* [[sftpman]] - an sshfs helper tool
 
* [[SSH]]
 
 
* [http://wiki.gilug.org/index.php/How_to_mount_SFTP_accesses How to mount chrooted SSH filesystem], with special care with owners and permissions questions.
 
* [http://wiki.gilug.org/index.php/How_to_mount_SFTP_accesses How to mount chrooted SSH filesystem], with special care with owners and permissions questions.
 +
* [http://www.admin-magazine.com/HPC/Articles/Sharing-Data-with-SSHFS SSHFS – Installation and Performance] — Comparison with NFS and optimization tips.

Latest revision as of 10:59, 8 August 2017

SSHFS is a FUSE-based filesystem client for mounting directories over SSH.

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 qsshfsAUR, sftpman, sshmntAUR or fmount.py.

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 ~/.ssh/config to simplify the sshfs usage. For more information see Secure Shell#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.

Tip: Google Authenticator can be used with sshfs for additional security.

Unmounting

To unmount the remote system:

$ fusermount -u local_mount_point

Example:

$ fusermount -u /mnt/sessy

Options

sshfs can automatically convert between local and remote user IDs. Use the idmap=user option to translate the UID of the connecting user to the remote user myuser (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 idmap=file, uidfile and gidfile.

Chrooting

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

/etc/ssh/sshd_config
.....
Match User someuser 
       ChrootDirectory /chroot/%u
       ForceCommand internal-sftp
       AllowTcpForwarding no
       X11Forwarding no
.....
Note: The chroot directory must be owned by root, otherwise you will not be able to connect.

See also SFTP chroot. For more information check the sshd_config(5) man page for Match, ChrootDirectory and ForceCommand.

Automounting

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

Note: Keep in mind that automounting is done through the root user, therefore you cannot use hosts configured in .ssh/config of your normal user.

To let the root user use an SSH key of a normal user, specify its full path in the IdentityFile option.

And most importantly, use each sshfs mount at least once manually while root so the host's signature is added to the /root/.ssh/known_hosts file.

On demand

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Is there a way to make this work with a passphrase-protected private key? E.g. it prompts for the passphrase at first access. Alternatively, clearly state that it's not possible and why. (Discuss in Talk:SSHFS#)

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

Example:

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 is a network device, not a block device (without it "No such device" errors might happen)
Note: After editing /etc/fstab, (re)start the required service: systemctl daemon-reload && systemctl restart <target> where <target> can be found by running systemctl list-unit-files --type automount
Tip: autosshfs-gitAUR do not require editing /etc/fstab to add a new mountpoint. Instead, regular users can create one by simply attempting to access it (with e. g. something like ls ~/mnt/ssh/[user@]yourremotehost[:port]). autosshfs-gitAUR uses AutoFS. Users need to be enabled to use it with autosshfs-user.

On boot

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

USERNAME@HOSTNAME_OR_IP:/REMOTE/DIRECTORY  /LOCAL/MOUNTPOINT  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:

user@domain.org:/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:

USERNAME@HOSTNAME_OR_IP:/REMOTE/DIRECTORY  /LOCAL/MOUNTPOINT  fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_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.

Troubleshooting

Checklist

Read the SSH Checklist Wiki entry first. Further issues to check are:

1. Is your SSH login sending additional information from server's /etc/issue file e.g.? This might confuse SSHFS. You should temporarily deactivate server's /etc/issue file:

$ mv /etc/issue /etc/issue.orig

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 sshfs#user@host:/mnt/server/folder ... fuse ... instead of using the syntax user@host:/mnt/server/folder ... fuse.sshfs ... x-systemd, ....

3. Check that the owner of server's source folder and content is owned by the server's user.

$ chown -R USER_S: /mnt/servers/folder

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:

uid=USER_C_ID,gid=GROUP_C_ID

5. Check that the client's target mount point (folder) is owned by the client user. This folder should have the same user ID as defined in SSHFS's mount options.

$ chown -R USER_C: /mnt/client/folder

6. Check that the client's mount point (folder) is empty. By default you cannot mount SSHFS folders to non-empty folders.

7. If you want to automount SSH shares by using an SSH public key authentication (no password) via /etc/fstab, you can use this line as an example:

USER_S@SERVER:/mnt/on/server      /nmt/on/client        fuse.sshfs      x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/USER_C/.ssh/id_rsa,allow_other,default_permissions,uid=USER_C_ID,gid=GROUP_C_ID,umask=0   0 0

Considering the following example settings ...

SERVER = Server host name (serv) USER_S = Server user name (pete) USER_C = Client user name (pete) USER_S_ID = Server user ID (1004) USER_C_ID = Client user ID (1000) GROUP_C_ID = Client user's group ID (100)

you get the client user's ID and group ID with

$ id USERNAME

this is the final SSHFS mount row in /etc/fstab;

pete@serv:/mnt/on/server      /nmt/on/client        fuse.sshfs      x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/pete/.ssh/id_rsa,allow_other,default_permissions,uid=1004,gid=1000,umask=0   0 0

8. If you know another issue for this checklist please add it the list above.

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/hosts with the server details.
  • If you are using non-default key names and are passing it as -i .ssh/my_key, this will not work. You have to use -o IdentityFile=/home/user/.ssh/my_key, 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 'sshfs_debug' (as in 'sshfs -o sshfs_debug user@server ...') can help in resolving the issue.
  • If that doesn't reveal anything useful, you might also try adding the option 'debug'
  • If you are 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)
  • Old Forum thread: sshfs: Connection reset by peer
  • Make sure your user can log into the server (especially when using AllowUsers)
  • Make sure Subsystem sftp /usr/lib/ssh/sftp-server is enabled in /etc/ssh/sshd_config.
Note: When providing more than one option for sshfs, they must be comma separated. Like so: 'sshfs -o sshfs_debug,IdentityFile=</path/to/key> user@server ...')

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 Subsystem sftp in /etc/ssh/sshd_config on the remote machine is valid.

Freezing apps (e.g. Gnome Files, Gedit)

Warning: This prevents the recently used file list from being populated and may lead to possible write errors.

If you experience freezing/hanging (stopped responding) applications, you may need to disable write-access to the ~/recently-used.xbel file.

# chattr +i /home/USERNAME/.local/share/recently-used.xbel

See the following bug report for more details and/or solutions.

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 mount -av and see the debug output, remove the following:

 noauto,x-systemd.automount

See also