Sshfs as regular user through fstab
Asked Answered
K

3

23

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 [email protected]:/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#[email protected]:/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?

Kiloton answered 14/11, 2013 at 7:20 Comment(0)
S
32

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#[email protected]:/remote/dir /work     fuse      user,_netdev,reconnect,uid=1000,gid=1000,idmap=user  0   0

use

sshfs#[email protected]:/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.

Scram answered 14/11, 2013 at 8:30 Comment(4)
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?Kiloton
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.Scram
The allow_other mount option exposes an unresolved security bug 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.Eastwardly
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.Vanderpool
H
4

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

Heikeheil answered 15/4, 2017 at 13:15 Comment(2)
third step actually helped with my problem, thank you!Clemmy
I guess this (third step) wouldn't work if I disabled root login in sshd.config on the remote host? I get read: Connection reset by peer.Kevakevan
V
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.

Vast answered 6/2, 2019 at 14:16 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.