18

I'd like to mount a remote directory through sshfs on my Debian machine, say at /work. So I added my user to fuse group and I run:

sshfs user@remote.machine.net:/remote/dir /work

and everything works fine. However it would be very nice to have the directory mounted on boot. So I tried the /etc/fstab entry given below:

sshfs#user@remote.machine.net:/remote/dir /work     fuse      user,_netdev,reconnect,uid=1000,gid=1000,idmap=user  0   0

sshfs asks for password and mounts almost correctly. Almost because my regular user has no access to the mounted directory and when I run ls -la /, I get:

d?????????   ? ?        ?               ?            ? work

How can I get it with right permissions trough fstab?

Sventimir
  • 1,653
  • 3
  • 13
  • 21

3 Answers3

28

Using option allow_other in /etc/fstab allows other users than the one doing the actual mounting to access the mounted filesystem. When you booting your system and mounting your sshfs, it's done by user root instead of your regular user. When you add allow_other other users than root can access to mount point. File permissions under the mount point still stay the same as they used to be, so if you have a directory with 0700 mask there, it's not accessible by anyone else but root and the owner.

So, instead of 

sshfs#user@remote.machine.net:/remote/dir /work     fuse      user,_netdev,reconnect,uid=1000,gid=1000,idmap=user  0   0

use

sshfs#user@remote.machine.net:/remote/dir /work     fuse      user,_netdev,reconnect,uid=1000,gid=1000,idmap=user,allow_other  0   0

This did the trick for me at least. I did not test this by booting the system, but instead just issued the mount command as root, then tried to access the mounted sshfs as a regular user.

  • It worked, thank you very much! I assumed `uid` and `gid` parameters should set ownership of the directory after mount, but apperntly they do something else. Could you be so kind to explain, what? – Sventimir Nov 14 '13 at 08:52
  • 2
    The uid and gid parameters do set the uid/gid of the stuff under the mount, however, these are secondary to the fact that sshfs by default allows access to files under the mount only to the user who has performed the mount. The mount point itself is only accessible to the user doing the mount, except when allowed to other users (= -o allow_other) or to the root (= -o allow_root). In your case the mounting user was root, thus access to other users than the root had to be given exclusively with -o allow_root. –  Nov 14 '13 at 10:36
  • The allow_other mount option exposes an [unresolved security bug](https://github.com/libfuse/libfuse/issues/15) in the Linux kernel: if the default_permissions mount option is NOT used along with allow_other, the results of the first permission check performed by the file system for a directory entry will be re-used for subsequent accesses as long as the inode of the accessed entry is present in the kernel cache - even if the permissions have since changed, and even if the subsequent access is made by a different user. – MountainX Feb 10 '18 at 01:15
  • The `uid` and `gid` also indicate the user and group that will be mapped through the mount. If you need more than just those then you need to set `idmap=file`. – OrangeDog Feb 26 '21 at 16:45
3

Also to complement previous answer:

  1. You should prefer the [user]@[host] syntax over the sshfs#[user]@[host] one.

  2. Make sure you allow non-root users to specify the allow_other mount option in /etc/fuse.conf

  3. Make sure you use each sshfs mount at least once manually while root so the host's signature is added to the .ssh/known_hosts file.

    $ sudo sshfs [user]@[host]:[remote_path] [local_path] -o allow_other,IdentityFile=[path_to_id_rsa]

REF: https://wiki.archlinux.org/index.php/SSHFS

Martin Brousseau
  • 87
  • 5
0

Also, complementing the accepted answer: there is a need that the user on the target has a right to shell, on target machine: sudo chsh username -> /bin/bash.

I had a user who had /bin/false, and this caused problems.

Marten Sytema
  • 1,826
  • 2
  • 20
  • 28