1

So I have a permission problem with my sshfs mount:

root@server01:/mnt# sshfs -o uid=$(id -u www-data) -o gid=$(id -g www-data) user@host:/path mountpoint
root@server01:/mnt# ls -Zlah
total 12K
drwxr-xr-x  3 root     root     ? 4.0K Nov 29 20:00 .
drwxr-xr-x 23 root         1001 ? 4.0K Nov 29 13:03 ..
drwxrwxrwx  1 www-data www-data ? 4.0K Nov 29 18:53 mountpoint
root@server01:/mnt# getfacl mountpoint/
# file: mountpoint/
# owner: www-data
# group: www-data
user::rwx
group::rwx
other::rwx
root@server01:/mnt# sudo -u www-data ls -lah
ls: cannot access mountpoint: Permission denied
total 8.0K
drwxr-xr-x  3 root root 4.0K Nov 29 20:00 .
drwxr-xr-x 23 root 1001 4.0K Nov 29 13:03 ..
d?????????  ? ?    ?       ?            ? mountpoint

Maybe the problem lies here:

root@server01:/mnt# mount
# unrelated stuff skipped
user@host:/path/ on /mnt/mountpoint type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0)

Here it says the uid and gid of the mount are both 0, which is root. But on my mount command and when using ls as root, it tells me everything belongs to gid/uid 33 which is www-data.

  • @Christopher Umm, yes? I don't seem to understand the implications. If by client you mean the machine where I run sshfs. I run sshfs on the same machine as the commands I quoted. And it seems to work because on the same machine where I use sudo -u www-data, ls also tells me the stuff belongs to www-data. – Nobody Nov 29 '16 at 19:39
  • I have seen similar problems with NFS several times. Have you tried to reconnect it? Can you list what you have with mount | grep /mnt? (Im new to sshfs). – hschou Nov 29 '16 at 19:42
  • @Christopher But am I not mounting the remote side so that it gets the uid and gid of local-side-user www-data? – Nobody Nov 29 '16 at 19:50
  • @Christopher I think that's what I'm doing. – Nobody Nov 29 '16 at 19:55
  • 1
    Related: Why does root get Permission denied when accessing FUSE directory . FUSE by default doesn't quite follow the classic permission model. – Mark Plotnick Nov 29 '16 at 20:14
4

sshfs = FUSE, you are mounting as root, then trying to access using another user.

for a joke / test, you can sshfs as regular user, then switch to root, cd, ohh permission denied, how can root be denied, it's root...

run sshfs as the user you want to access.

update with example:

**test**@mike-laptop4:/mnt$ sshfs mike@192.0.2.0:/home/mike moo
test@mike-laptop4:/mnt$ ls moo/
src
mike@mike-laptop4:/mnt$ ls moo 
ls: cannot access 'moo': Permission denied
mike@mike-laptop4:/mnt$ sudo su
root@mike-laptop4:/mnt# ls moo 
ls: cannot access 'moo': Permission denied

and vice versa:

**mike**@mike-laptop4:/mnt$ sshfs mike@192.0.2.0:/home/mike moo
mike@mike-laptop4:/mnt$ ls moo
src
test@mike-laptop4:/mnt$ ls moo
ls: cannot access 'moo': Permission denied
mike@mike-laptop4:/mnt$ sudo su
root@mike-laptop4:/mnt# ls moo
ls: cannot access 'moo': Permission denied

UPDATE, Expand on solutions:

Solution 1: mount as the user required to access the data (security preference).

$ sshfs mike@192.0.2.0:/home/mike moo

Using this option will allow only the mounting user to access the data.


The following 2x solution require (unless mounting as root, root shouldn't be used for sshfs);

/etc/fuse.conf user_allow_other

Solution 2: allow any user on the box access

$ sshfs -o allow_other mike@192.0.2.0:/home/mike moo

Literally any user on the source host can create,edit,delete files, this is a terrible idea in most circumstances, and I can't imaging would ever be allowed in a PCI environment.

Not only do you risk all the data on the remote, but you risk a local user manipulating data that can be later used by another local user.

Solution 3: allow any user on the box, but honor local filesystem perms.

$ sshfs -o allow_other,default_permissions mike@192.0.2.0:/home/mike moo

This option is much more acceptable than the last owing to the fact that only users authorized by the local filesystem will be allowed to access / edit files in the mount.

It would also be possible to setup group based permissions.

  • Thank you. Although the real answer really is in @Mark Plotnick's comment, there is the option "-o allow_other" to sshfs which I think should fix it (will test later. Logging in as www-data is not something I want to do). – Nobody Nov 29 '16 at 22:01
  • how is my answer not real? i identified your issue :) – mikejonesey Nov 29 '16 at 22:57
  • I think the comment identifying my issue was first, and it also solved the issue instead of just pointing it out. But usually it's the other way round: comments pointing out the issue and answers solving it. ;-) So if you want to add the solution to your answer (maybe even explaining what exactly it does, because for now I'm not entirely sure), I can upvote and accept. – Nobody Nov 29 '16 at 23:02
  • Also in hindsight I'm not even entirely sure the question is not a duplicate. But it's only a duplicate once you know the answer, so I don't know. – Nobody Nov 29 '16 at 23:06
  • pretty sure I had answered first, and provided a solution, but maybe i was mistaken, updated with 3 options. – mikejonesey Nov 30 '16 at 0:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.