On Mon, Jul 11, 2011 at 3:38 PM, Gaetan Bisson wrote:

One thing I noticed: after reboot, the fuse module failed to be autoload when I ran stuff like sshfs; I had to add it to the MODULES array in /etc/rc.conf. That might be something worth mentioning.

Thanks for catching this. It was not intentional. I have not tested with sshfs myself, but this is what I see on my system: % ls /lib/udev/devices loop0 % ls /dev/fuse -lah crw------- 1 root root 10, 229 Jul 11 15:13 /dev/fuse So, the fuse device node seems to be created. Do you see the same? Does installing udev-compat fix it? Cheers, Tom

[2011-07-11 16:02:15 +0200] Thomas Bächler:

Permissions are incorrect here, should be 0666, otherwise a user cannot access it and trigger the module autoloading.

Sorry I was AFK for some time. You are correct: it was a permission issue on /dev/fuse that I had. -- Gaetan

[2011-07-11 11:41:59 -0400] Dan McGee:

On Mon, Jul 11, 2011 at 11:38 AM, Gaetan Bisson wrote:

...

You are correct: it was a permission issue on /dev/fuse that I had.

This isn't a permission error you had; it is likely a permission error every single person will have, so it needs to get addressed somehow.

Right. (That's what I meant but it came out wrong.) -- Gaetan

On Mon, Jul 11, 2011 at 6:56 PM, Evangelos Foutras wrote:

On 11 July 2011 18:41, Dan McGee wrote:

...

On Mon, Jul 11, 2011 at 11:38 AM, Gaetan Bisson wrote:

...

[2011-07-11 16:02:15 +0200] Thomas Bächler:

...

Permissions are incorrect here, should be 0666, otherwise a user cannot access it and trigger the module autoloading.

Sorry I was AFK for some time.

You are correct: it was a permission issue on /dev/fuse that I had.

This isn't a permission error you had; it is likely a permission error every single person will have, so it needs to get addressed somehow.

The permissions are wrong here as well.

Below are the results of using 'git bisect' and installing the resulting packages in a VM, rebooting, and seeing if /dev/fuse has 600 or 666 permissions:

(Reverting this commit [1] in the udev 172-1 package fixes the wrong permissions on /dev/fuse. I don't understand the changes in that commit myself, so I'll leave further troubleshooting to Tom and the other experts. :p)

c112873b5bc9ebbae39c32f502bc6211f33546cc is the first bad commit commit c112873b5bc9ebbae39c32f502bc6211f33546cc Author: Kay Sievers Date:   Mon May 30 02:12:02 2011 +0200

   rules: static_node - use 0660 if group is given to get the cigar

   >> On Tue, May 24, 2011 at 15:33, Tom Gundersen wrote:    >    > Close, but no cigar. Looks like the static nodes are not assigned    > permissions 0660 even if a gid is set (the nodes have perms 0600).    >    > Cheers,    >    > Tom

:040000 040000 4bc113a62daff05dadc05d3812d66a702d7e1849 d893668f602bb9079b721a26e880333b7e7932f8 M      udev

[1] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=c112873

Thanks for debugging (and sorry for being late in replying). This does look like an upstream bug introduced when fixing the other upstream bug we found with the last release :-) I'll look into it in more detail and pass it on. Expect a 172-2 in testing once this has been sorted out. Cheers, Tom

Am 11.07.2011 15:38, schrieb Gaetan Bisson:

[2011-07-11 12:15:59 +0200] Tom Gundersen:

...

A new udev version is in [testing], please test and signoff.

One thing I noticed: after reboot, the fuse module failed to be autoload when I ran stuff like sshfs; I had to add it to the MODULES array in /etc/rc.conf. That might be something worth mentioning.

Apart from that, signoff both.

The /dev/fuse device should be present with or without 'fuse' being loaded. Can you verify this? Any access to /dev/fuse will then trigger autoloading the fuse module.