dapper: /dev/fuse not owned by group set in package config

[Patrick McFarland]

/dev/fuse is not owned by group set in package configuration, confirmed not working in dapper's 2.4.1-0ubuntu1

[Chris Moore (dooglus)]

I can confirm this:

    $ sshfs <email address hidden>: ~/sshfs/dir
    fusermount: failed to open /dev/fuse: Permission denied

The first I want to use sshfs after rebooting I have to:

    $ sudo chgrp fuse /dev/fuse

and then it works fine.

I'm using an up-to-date dapper system, with these package versions:

ii fuse-utils 2.4.2-0ubuntu1 Filesystem in USErspace (utilities)
ii libfuse2 2.4.2-0ubuntu1 Filesystem in USErspace library

[Patrick McFarland (diablod3)]

Whats really nasty about this bug is that you have to chgrp every reboot.

[Philip Axer (paxer)]

In addition to this, I had to chmod fusermount to make it executable for the fuse members! Can somone confirm this?

[John Leach (johnleach)]

Same here. /dev/fuse is root.root 0660
fuse-utils 2.4.2-0ubuntu1
udev 079-0ubuntu12

"sudo chgrp fuse /dev/fuse" fixes it until next reboot

[Darrin Auxier (dsauxier)]

I can confirm the behavior described, (chgrp fuse /dev/fuse fixes the problem in Dapper) however something else must be going on...

I compared /dev/fuse in Dapper against a Breezy installation, and /dev/fuse has root as the group in Breezy
$ ls -l /dev/fuse
crw-rw---- 1 root root 10, 229 2006-02-24 18:21 /dev/fuse

So, why does chgrp fix it (or, more accurately : why does it work in Breezy in the first place? )

For now, I'll add S99zlocal to my /etc/init.d and put the chgrp fuse /dev/fuse in there

[Alessio Caiazza (nolith)]

# cat /etc/udev/rules.d/99-fuse.rules
KERNEL="fuse", NAME="%k", MODE="0666"

after this (you must reload udev end fuse module )
 # ls -l /dev/fuse
crw-rw-rw- 1 root root 10, 229 2006-03-03 16:30 /dev/fuse

there should be an option to set groups instead of permission to write to all user.

[Ali Sheikh (asheikh)]

Isn't this really a bug in udev. At the time the /dev/fuse device file is created, the group should really be set to fuse. Re: Alessio Caiazza proposed fix, isn't it better to have the following rule:

KERNEL="fuse", NAME="%k", GROUP="fuse"

[PtOLU8zjbZxlgNOiyGyd (lkgdx5kefrptmd7ccufa-deactivatedaccount)]

I agree with Ali Sheikh. It is a bug in udevs rules files. And it is irksome!!! I've cross-linked this bug to udev's tracker.

[Scott James Remnant (Canonical) (canonical-scott)]

This is not a bug in udev.

The fuse package can ship a udev rule, just as gphoto, sane, ifupdown, etc. ship udev rules as well.

The rule it wants should probably be in a file named /etc/udev/rules.d/45-fuse.rules and look almost exactly like:

    KERNEL=="fuse", GROUP="fuse"

(Note the double-equals, and that the NAME= is not needed).

The reason this can't be shipped in the default udev rules is that we don't have a default fuse group.

[Dennis Kaarsemaker (dennis)]

Added a debdiff, tested and works on my machine. Scott, could you please apply and upload this?

[Saulius Menkevičius (saulius-menkevicius)]

I think this has been already fixed and can be closed.
WORKSFORME

[Tennessee Leeuwenburg (tennessee)]

It's broken for me as of 16 March 2006. I just installed it, and I can't make it work.

[Saulius Menkevičius (saulius-menkevicius)]

Leeuwenburg: There is another bug #1860, that you need to do sudo modprobe fuse before using fusermount, it doesn't do that automatically. Is it because of it?

[Dennis Kaarsemaker (dennis)]

And you need to add yourself to the fuse group...

These two things are not considered bugs.

[Chris (bridgeriver)]

I just ran into the /dev/fuse permissions problem on Edgy (upgraded from Dapper, upgraded from Breezy I think).

The problem was a mistake in the file /etc/udev/rules.d/40-fuse.rules. It is supposed to contain:

KERNEL=="fuse", NAME="%k", MODE="0666"

but it actually contains

KERNEL="fuse", NAME="%k", MODE="0666"

(i.e., there's one equals sign instead of two after the KERNEL keyword).

The result seems to be that the rule is disabled, and /dev/fuse appears with permissions which permit only user=root and group=root instead of all users as intended.

To fix the permissions, you can add the missing "=" to the file, then do
modprobe -r fuse
modprobe fuse

and then do

ls -lF /dev/fuse

to confirm that the new permissions took effect.

[Philip Kovac (pkovac)]

I can confirm this bug on Feisty. Luckily it seems I don't have to make this change every boot. Regardless, it causes Fuse to not simply "just work" out of the box.

[Oliver Grawert (ogra)]

did you use feisty from any herd CD to install ? there was a bug in an early release of this package where the wrong (debians udev file) file was installed as /etc/udev/rules.d/40-fuse.rules. the correctd package in feisty (2.6.3-1ubuntu2) should supply this file corerected with a sequence number of 45 and delete the old one. please check if you have two of the fuse rules files in /etc/udev/rules.d/.

[Michael Crider (mecrider)]

Maybe Philip's case was like mine. I did a fresh install of Feisty, keeping only my home directory from Edgy, last week, and have kept it updated. Today I added the sshfs package, which also added a fuse related package. When I first ran sshfs, I deduced from the error message that I needed to be part of the fuse group. I added myself, then logged out and back in. I still got the error listed at the top. Certain that I had found a bug, I googled and got this page. After reading through all the comments, I checked the udev rules, and they were right. Then I looked again at the file permissions again on /dev/fuse, and noticed the time and date stamp were from last time I rebooted. Apparently the fuse module was already getting loaded before the installation of fuse-utils, but with root:root ownership. I did "sudo modprobe -r fuse" followed by "sudo modprobe fuse" and everything worked. I only relate this in case the same thing happens to someone else.

[Antti Kaihola (akaihola)]

In Feisty, /dev/fuse is initially owned by root/root. After doing sudo modprobe -r fuse ; sudo modprobe fuse, the owner changes to root/fuse.

[Oliver Grawert (ogra)]

lets try that then :)

 fuse (2.6.5-1ubuntu2) gutsy; urgency=low
 .
   * drop postinst code for MAKEDEV and udevcontrol reload_rules we dont need
     either in ubuntu and it most likely fixes the /dev/fuse ownership problems
     from launchpad bug 5105.

couls someone test this on gutsy i assume it fixes all the ownership probs.

[Benjamin Rubin (bnrubin)]

Appears to work in Gutsy now.

I didn't check if a fuse group existed before adding my user to it, but I did have to manually put my user in the group.

In addition, the permissions on /dev/fuse did not take effect until I rebooted my computer,

[rogerdpack (rogerdpack)]

NB that the group fuse isn't created until you install the "right" package

$ sudo apt-get install sshfs # possibly just installing fuse-utils would do the trick.

--i.e. Installing fuse2 and libfuse-dev apparently is enough to create /dev/fuse but not create its group (?)

Even after that, you may still need to add yourself to the fuse group, and also probably reboot.

symptoms (works as root, but not as any other user)

[16:09:42 - 09-10-19] /home/rdp/dev/temp %ls -l /dev/fuse
crw-rw---- 1 root root 10, 229 Sep 4 20:11 /dev/fuse

[16:09:19 - 09-10-19] /home/rdp/dev/temp %ls -l
ls: cannot access compressed_dir: Permission denied
total 4
d????????? ? ? ? ? ? compressed_dir

Note also that a lacking
/etc/udev/rules.d/99-fuse.rules
file means you need to install the packages above.
Thanks!
-r