Bug 10840 - sshfs fails to mount remote fs since recent updates
Summary: sshfs fails to mount remote fs since recent updates
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal major
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-26 01:07 CEST by Barry Jackson
Modified: 2013-07-27 14:44 CEST (History)
1 user (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description Barry Jackson 2013-07-26 01:07:05 CEST
Description of problem:
[baz@jackodesktop ~]$ sshfs baz@zmhost:/zm-repo/pub/linux/barjac/distrib/ $HOME/iurt_uploads/iurt/
fuse: failed to open /dev/fuse: Permission denied

The same mount works correctly from Mga3 and has always worked until a couple of days ago from Cauldron.

I can still connect to the server over ssh from Cauldron.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.


Reproducible: 

Steps to Reproduce:
Comment 1 Barry Jackson 2013-07-26 12:31:25 CEST
[root@jackodesktop baz]# usermod -G fuse baz
usermod: group 'fuse' does not exist

This would explain the 'permission denied' - but why has fuse group gone AWOL?
Comment 2 Colin Guthrie 2013-07-26 13:19:59 CEST
Did it ever exist?

It's perhaps related to a systemd change where static device nodes are no longer created by udev but deferred to kmod.

This might affect the ACLs on /dev/fuse. Can you check if you had ACL privs on /dev/fuse under mga3 and that there are no ACLs on mga4? If so probably helps narrorw down the problem (and is likely related to kmod+systemd)

CC: (none) => mageia

Comment 3 Barry Jackson 2013-07-26 13:49:27 CEST
This is not related to systemd in initrd as I am now back with original initrd.

Mga4:
[baz@jackodesktop ~]$ getfacl /dev/fuse
getfacl: Removing leading '/' from absolute path names
# file: dev/fuse
# owner: root
# group: root
user::rw-
group::---
other::---

Mga3
getfacl: Removing leading '/' from absolute path names
# file: dev/fuse
# owner: root
# group: root
user::rw-
group::rw-
other::rw-
Comment 4 Barry Jackson 2013-07-26 14:23:42 CEST
Changing perms in Mga4 to match Mga3 does fix sshfs mount issue.
Comment 5 Colin Guthrie 2013-07-26 14:56:41 CEST
OK, so checking the udev rules, it seems that the perms are meant to be open:

[colin@jimmy ~]$ cd /usr/lib/udev/rules.d/
[colin@jimmy rules.d]$ grep fuse *
50-udev-default.rules:KERNEL=="fuse", MODE="0666", OPTIONS+="static_node=fuse"
99-systemd.rules:SUBSYSTEM=="module", KERNEL=="fuse", ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}+="sys-fs-fuse-connections.mount"


i.e. 666

I suspect this is a problem reported on the systemd mailing list a couple days ago regarding tmpfiles overwriting the perms of the kmod static nodes.

http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/12121

This isn't the final patch, but the principle is sound and seems like what's happening here.

Will look to apply one of the patches.
Comment 6 Colin Guthrie 2013-07-26 15:05:28 CEST
OK, the upstream commits are cherry picked but will keep open until I've had the chance to reboot and confirm the fix :)
Comment 7 Colin Guthrie 2013-07-27 13:32:52 CEST
Those patches work for me. /dev/fuse has the expected permissions. Submitted to BS now.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 8 Barry Jackson 2013-07-27 14:44:45 CEST
Nice!
Confirmed here after update and reboot perms are correct.

Note You need to log in before you can comment on or make changes to this bug.