fusermount: failed to open /dev/fuse: Permission denied

[Terry Browning]

fuse (sshfs, encfs, ... ) fails reporting:

fusermount: failed to open /dev/fuse: Permission denied

This is because /dev/fuse is group root, when it should be group fuse
Workaround:

sudo chgrp fuse /dev/fuse

and all is well.

This is a perennial problem: Dapper, Edgy and now Feisty.

[Dan Lewis (actiondan)]

I've just got the same problem on my Feisty install on my laptop. But I'm pretty certain I didn't have to do the chgrp on other Feisty or Edgy installs I've done recently, which is strange.

[Terry Browning (ubuntu9648)]

I checked the launchpad site for the same symptoms and found them on reports for Dapper and Edgy. I only started a new bug when I didn't find a report specifically for Feisty.
I suspect group root is reintroduced, probably from upstream, and then gets patched shortly after the stable release. If you download the release quickly, you get the bug, otherwise you get a fixed version.

[Julian67 (julianhughes)]

I've had exactly the same problem. I have 3 PCs running 7.04. One of them has the default installed kernel 2.6.20-15 and is fine, the other 2 have been updated immediately on being installed to 2.6.20-16 and both have the problem with fusermount. The fix outlined above does work but it is not persistent; the problem is there again on rebooting. I added the chgrp fuse /dev/fuse command to the /etc/init.d/fuse shellscript and that has done the trick for now. I can't find any relevant differences between the PC that doesn't work as expected and the 2 others except the kernel version.

[gagarine (gagarine)]

same problem on gusty!

[Terry Browning (ubuntu9648)]

@gagarine:
I haven't had the problem with gusty beta. Other problems aplenty (not yet nailed down), but not this one.
I installed the recent 7.10 beta. Booted with some issues.
installed sshfs
added myself to the fuse group

sudo addgroup terry fuse

logged out & back in
sshfs was fine. No problem.
if you

ll /dev/fuse

you should get

crw-rw---- 1 root fuse 10, 229 2007-10-07 12:42 /dev/fuse

Maybe you're using a younger gibbon.

[gagarine (gagarine)]

Oups... I'm just forgot to logout :/ sorry for the spam.

But why don't put directly the all "desktop" user in the fuse group? Or an option in the System -> Administration -> user and group -> "user x" -> "user privilege" (graphical)?

[LAADHARI Saber (pbx06)]

first of all. let me say it is buggy.
i had to add my user to the groupe fuse, then make mount point writable by the "fuse" groupe !

and you would use -o idmap=user option to translate the id ...

[notelopuedesimaginar (notelopuedesimaginar)]

After adding the user to the fuse group, I had to reboot. Even restarting the terminal and then the Xserver was not enough. Why? Thanks!

[Terry Browning (ubuntu9648)]

When you add yourself to the fuse group, this takes effect at the *next* login.

[Terry Browning (ubuntu9648)]

@notelopuedesimaginar:
You have a good point about group fuse.

Having to add yourself to group fuse is a security feature (permissions should only be given to processes which need them).
However, the trendy young things with their shiny shiny eeepcs can't be expected to understand such things, so I agree that mortal users should be group fuse, just as they are group audio and group video.

The thing about '-o idmap=user' is a sshfs issue. Nothing to do with fuse.

PLEASE NOTE. This (bug 114212) is a dead bug. It has ceased to be. No ubuntu staff can be expected to read this.
If you want to change Ubuntu for the better: try the latest test version (currently 8.04 alpha 4), find the bug, find the corresponding bug report on launchpad, and have your say there. The maintainers will read what you write and take it seriously. They might disagree with you, but this is the way to get your bugs fixed.

[Martin Pitt (pitti)]

This was fixed in intrepid:

fuse (2.7.3-4ubuntu2) intrepid; urgency=low

  * debian/fuse-utils.postinst: Install /bin/fusermount as world executable.
    it already bails out correctly if the user does not have access to
    /dev/fuse; no reason to control access to it in two different places (and
    the permissions of the binary can't be changed in a flexible way).
  * Add debian/10-fuse-permissions.fdi: Enable hal's dynamic ACL management
    for /dev/fuse, so that local foreground consoles will have access to it.
    Install it in debian/fuse-utils.install.
  * Drop debian/fuse-utils-needs-users-added-to-fuse-group.update-notifier and
    its installation in the postinst, it's not really relevant any more.
  * See intrepid-device-permissions spec for details.

 -- Martin Pitt <email address hidden> Thu, 25 Sep 2008 17:47:10 +0200

[Nikolaus Rath (nikratio)]

The problem reappeared in jaunty.
Although fuse.conf has correct permissions, it still cannot be read:

$ python /usr/share/doc/python-fuse/examples/hello.py -s -f -o allow_other ~/tmp
fusermount: failed to open /etc/fuse.conf: Permission denied
fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf
Traceback (most recent call last):
  File "/usr/share/doc/python-fuse/examples/hello.py", line 92, in <module>
    main()
  File "/usr/share/doc/python-fuse/examples/hello.py", line 89, in main
    server.main()
  File "/usr/lib/python2.6/dist-packages/fuse.py", line 713, in main
    main(**d)
fuse.FuseError: filesystem initialization failed

$ dir /etc/fuse.conf
-rw-r----- 1 root fuse 212 2009-05-26 12:34 /etc/fuse.conf

[Anders Kaseorg (andersk)]

Nikolaus, firstly, your comment describes a different issue than this bug, as /etc/fuse.conf is very different from /dev/fuse, so it should be filed as a new report. Secondly, you should not mark your own reports as Confirmed. Thirdly, did you forget to add yourself to the fuse group?

[Martin Pitt (pitti)]

oops, ignore this.