2

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.
  • 21
  • 1
  • 3

2 Answers2

1

I had the same error when I tried to fuse mount on a path not covered by the allow rules in /etc/apparmor.d/fusermount3. These show up in dmesg containing the text failed mntpnt match. The mount point was below /srv/, which worked with previous versions of Ubuntu. I moved the tree into /mnt/, but could have added extra mount and unmount rules to the apparmor profile.

A side note related to the other answer: my path contains a parent directory with no permissions whatsoever for other, and it mounts fine.

Walf
  • 452
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