1

I have used sshfs on my Linux Mint machine to mount a directory from a different machine in the internet. This worked out of the box.

Then I tried the exact same command on a Ubuntu machine (Ubuntu 22.04.3 LTS) and got this error:

~$ sshfs -v <some machine on the interwebs> ~/fusessh/
fusermount3: mount failed: Permission denied

These are the permissions in my home directory on the Ubuntu machine:

drwx------ 27 my_user group_a    4096 Sep 15 14:36 .
drwx------  2 my_user group_b  4096 Aug 23 13:06 Desktop
drwx------  2 my_user group_b  4096 Aug 23 13:06 Documents
drwx------  2 my_user group_b  4096 Aug 23 13:06 Downloads
drwx------  2 my_user group_b  4096 Sep 12 14:04 fusessh

my_user is in both group_a and group_b.

~$ groups thsi
my_user : group_b sudo group_a

Edit based on the comments:

~$ ls -l /bin/fusermount3
-rwsr-xr-x 1 root root 35200 Mar 23  2022 /bin/fusermount3

In sandbox mode:

~$ unshare --map-root-user
~# ls -l /bin/fusermount3 
-rwsr-xr-x 1 nobody nogroup 35200 Mar 23  2022 /bin/fusermount3
Simon T.
  • 11
  • 1
    It's likely because mounting VFS requires sudo, but you could create a userspace mapping your user to root with unshare --map-root then try your sshfs ... command again from the new userspace and see if it works. – Raffa Sep 15 '23 at 13:26
  • The point of fuse is to work in user mode (afaik), and I need a solution that does not require sudo (I am in the sudo group but I want this to work for non-sudo users). – Simon T. Sep 15 '23 at 13:32
  • 1
    You should run unshare --map-root-user without sudo ... That is called user namespace/sandboxing and it's even safer than using your own user in the plain especially with Internet mounts ... Please see How do I use the user namespace sandbox? – Raffa Sep 15 '23 at 13:40
  • Doing this resulted in fusermount3: mount failed: Operation not permitted – Simon T. Sep 15 '23 at 13:45
  • Could you please show the output of ls -l /bin/fusermount3 – Raffa Sep 15 '23 at 14:50
  • Sure, it returns this: -rwsr-xr-x 1 nobody nogroup 35200 Mar 23 2022 /bin/fusermount3 – Simon T. Sep 19 '23 at 09:13
  • Are you doing ls -l /bin/fusermount3 from within a user namespace/sandbox or under your normal user ... If the former, then please open a new terminal and run the command again and show the output ... If the latter, then the ownership is not correct and you need to correct it with sudo chown root:root /bin/fusermount3 then run sudo chmod u+s /bin/fusermount3 – Raffa Sep 19 '23 at 09:28
  • I edited the post. I am not sure if the behavior is normal. In user mode, the ownership seems correct. With the sandbox, it seems off – Simon T. Sep 19 '23 at 09:37
  • It's correct under your user and the other output is also normal in the sandbox ... So, that's not the problem. and I'm out of ideas as to why you get fusermount3: mount failed: Permission denied except for the lack of group and especially others permissions on the mount point ... So, try chmod 0775 ~/fusessh/ and see if that works. – Raffa Sep 19 '23 at 09:45
  • It is strange, I did chmod as you put just now and it works. – Simon T. Sep 19 '23 at 09:56
  • I tested a bit more, and it seems the execute permissions are the essential thing. But now I am unable to unmount. It says Permission denied and when I do it with the GUI a small note pops up saying some data needs to be written before the device can be unmounted. – Simon T. Sep 19 '23 at 10:25
  • That might mean the write permission is also needed for others so try chmod 0777 ~/fusessh/ on the mount point while the filesystem is unmounted although I can't see how that would apply the mount itself ... If that didn't work, then you might want to mount the filesystem and check the permission while mounted. – Raffa Sep 19 '23 at 11:15
  • I have tried with 777 permissions, but still permission denied when I try to unmount. The permissions seem to be the same before mounting and when I mounted the remote folder. – Simon T. Sep 19 '23 at 14:38

1 Answers1

0

Run id to double check the user and group IDs of your accounts on both your local and remote systems. I'm guessing they're different, even if the names are the same. In that case FUSE is trying to modify the local mount point as an other user, as far as chmod and permissions are concerned. Therefore, you need to chmod o+rx ~/fusessh. The mode (permissions) of this mount point will be modified by the mode of the root of the filesystem that you mount, otherwise the directory should be empty if nothing is mounted, so giving other read and execute permissions shouldn't be much of a security risk.

In order to unmount, every directory in the mount path needs to have execute permissions. Run realpath ~/fusessh, then make sure that each directory in that path has the execute bit set for other (still assuming that UID/GID are different on each system).

Note: I post this now because I encountered these exact same issues today. To be honest, I don't know exactly how FUSE works under the hood. In my case the UID was the same on both systems, but the GID differed. Still, nothing worked until I gave permissions to other. I experimented with the uid, gid, and default_permissions mount options, but none of those fixed the issues. It seems to me that those mount options only changed their respective attributes after the filesystem was mounted, but that FUSE was operating under the UID/GID of the remote system before the mount finalized. Again, this is only speculation, but it fits the behavior.

LowTechGeek
  • 101