fuse mounts hang on xattr retrieval with auditd

Created attachment 337759
tarball containing ps auwwx, .xsession-errors log

Description of problem:

With the following procedure:
[1] Reboot with init 3. On tty1 log in as root
[2] On tty1, type # init 5 as root, then GDM launches
[3] With GDM log in as non-root user to GNOME session
[4] log out from GNOME session
[5] Again log in to GNOME session as the same user on [3]

Then GNOME session hangs.

Version-Release number of selected component (if applicable):
gvfs-1.2.0-2.fc11.i586
fuse-2.7.4-3.fc11.i586

How reproducible:
Currently 100%

Steps to Reproduce:
1. See above
2.
3.

Additional info:
- The results of "ps auwwx" on each stage [1] - [5] and .xsession-errors
  are in the attached tarball
- On the stage [4], when I kill the process 3576 and 3578
  with SIGKILL, the second login to GNOME works.

Just tested according to the repro steps provided, works for me. Tested with newly created account as well as with my old personal account.

From your logs, I can see possible point of failure:

gnome-session[4402]: WARNING: Application 'gnome-settings-daemon.desktop' failed to register before timeout
gnome-session[4402]: WARNING: Application 'gnome-panel.desktop' failed to register before timeout

(imsettings-applet:4548): IMSettings-WARNING **: メソッド WhatsInputMethodRunning' の呼出に失敗しました : Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

(gnome-panel:4537): GVFS-RemoteVolumeMonitor-WARNING **: invoking IsSupported() failed for remote volume monitor with dbus name org.gtk.Private.GduVolumeMonitor: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Looks like dbus is not running in the session. Can you post `rpm -qa | grep -e dbus -e glib2` here?

Hi:

[tasaka1@localhost ~]$ rpm -qa | grep -e dbus -e glib2 | sort
dbus-1.2.12-1.fc11.i586
dbus-debuginfo-1.2.12-1.fc11.i586
dbus-devel-1.2.12-1.fc11.i586
dbus-glib-0.80-2.fc11.i586
dbus-glib-debuginfo-0.80-2.fc11.i586
dbus-glib-devel-0.80-2.fc11.i586
dbus-libs-1.2.12-1.fc11.i586
dbus-python-0.83.0-5.fc11.i586
dbus-x11-1.2.12-1.fc11.i586
glib2-2.19.10-2.fc11.i586
glib2-debuginfo-2.19.10-2.fc11.i586
glib2-devel-2.19.10-2.fc11.i586
pulseaudio-libs-glib2-0.9.15-8.test7.fc11.i586
python-slip-dbus-0.1.15-3.fc11.noarch
ruby-glib2-0.18.1-6.fc11.i586
ruby-glib2-devel-0.18.1-6.fc11.i586

Can you try upgrading to glib2-2.20.0-1.fc11? I doubt it will make any difference, but just to be sure.

(In reply to comment #3)
> Can you try upgrading to glib2-2.20.0-1.fc11? I doubt it will make any
> difference, but just to be sure.
Oh, that build is failed, disregard my comment, my mistake.

Can you please check selinux status? (getenforce)
Also please check dmesg for any segfaults and avc denials.

We had some troubles with gvfs-fuse-daemon not exiting after logout, but it shouldn't cause failures on second login. I don't see anything like 3576 (fusermount) or 3578 (mount) here, make sure you don't have anything like this in /etc/fstab.

[tasaka1@localhost ~]$ getenforce
Disabled

My fstab is:
-----------------------------------------------------
/dev/VolGroup00/LogVol00 / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
/dev/VolGroup00/LogVol02 /home ext3 defaults 1 2
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
LABEL=/tmp /tmp ext3 defaults 1 2
/dev/VolGroup00/LogVol01 /usr ext3 defaults 1 2
LABEL=/var /var ext3 defaults 1 2
/dev/sda6 swap swap defaults 0 0
#/dev/sda2 /mnt/Windows-VFAT vfat noauto,owner,user,codepage=932,iocharset=euc-jp,posix,umask=0022 1 2
#/dev/sda1 /mnt/Windows-NTFS-3g ntfs-3g noauto,ro,locale=ja_JP.UTF-8 0 0
------------------------------------------------------
( Now I commented out the last 2 lines but the result is the
  same )

Its kinda weird that you see the fusermount and mount processes after the first login. These are supposed to be shortlived things that run and exit, only gvfs-fuse-daemon should be running for any longer period.

So, it seems to me that the process of mounting the fuse filesystem on ~/.gvfs somehow hangs.

Maybe you could try attaching to the fusermount and/or mount processes and get a backtrace?

Can you try the following in your first running session? Mount some ftp or sftp filesystem using Nautilus, make sure you can browse it. Then go to ~/.gvfs, you should see those mounts there. Check again if you can browse the mounts. I was wondering if the gvfs-fuse-daemon works as expected for you.

Created attachment 338039
screenshot of nautilus

First for this:

(In reply to comment #8)
> Can you try the following in your first running session? Mount some ftp or sftp
> filesystem using Nautilus, make sure you can browse it. Then go to ~/.gvfs, you
> should see those mounts there. Check again if you can browse the mounts. I was
> wondering if the gvfs-fuse-daemon works as expected for you.

Well, the actual result for this is:
When I launch $ nautilus from uxterm:
- nautilus won't show the contents of my home directory.
  (please see the attached png file)
  When I move the mouse pointer on nautilus, the mouse pointer
  shows it is still under processing.
- By "File -> Connect to Server" (I guess, my locale is ja_JP),
  mounting ftp server succeeds.
- I don't know how to go to ~/.gvfs on nautilus, because of the issue I wrote
  first

Created attachment 338049
gdb log

And gdb log is attached.

Note:
For process 3707, when trying to attach this process,
gdb itself hangs, so I had to kill gdb.

Created attachment 338060
ps auwwx when logged in GNOME session with kernel 2.6.27.x

(In reply to comment #7)
> Its kinda weird that you see the fusermount and mount processes after the first
> login. These are supposed to be shortlived things that run and exit, only
> gvfs-fuse-daemon should be running for any longer period.

Well, I tried to reboot with kernel-2.6.27.21-170.2.56.fc10.i686
and actually
- 2nd login to GNOME succeeds
- There are no "fusermount" "mount" process

[GOOD] kernel-2.6.27.21-170.2.56.fc10.i686
[BAD ] kernel-2.6.29.1-35.rc1.fc11.i586
[BAD ] kernel-2.6.29.1-46.fc11.i586

Created attachment 338061
dmesg (2.6.29.1-46.fc11.i586)

(In reply to comment #11)
> Well, I tried to reboot with kernel-2.6.27.21-170.2.56.fc10.i686
> and actually
> - 2nd login to GNOME succeeds
> - There are no "fusermount" "mount" process
>
> [GOOD] kernel-2.6.27.21-170.2.56.fc10.i686
> [BAD ] kernel-2.6.29.1-35.rc1.fc11.i586
> [BAD ] kernel-2.6.29.1-46.fc11.i586
Good catch, 2.6.29-21.fc11.x86_64 here, no problems with fuse.

(In reply to comment #9)
> - nautilus won't show the contents of my home directory.
> (please see the attached png file)
> When I move the mouse pointer on nautilus, the mouse pointer
> shows it is still under processing.
This is weird. Were there any nautilus errors on the uxterm shell? Could be
broken thumbnailer, but that should not make Nautilus unusable.
> - I don't know how to go to ~/.gvfs on nautilus, because of the issue I wrote
> first
You can use other tools, like mc (Midnight Commander) in a terminal or bash
commands

Created attachment 338081
nautilus output on terminal

With 2.6.29.1-46.fc11.i586:

(In reply to comment #13)
> (In reply to comment #11)
> (In reply to comment #9)
> > - nautilus won't show the contents of my home directory.
> > (please see the attached png file)
> > When I move the mouse pointer on nautilus, the mouse pointer
> > shows it is still under processing.
> This is weird. Were there any nautilus errors on the uxterm shell? Could be
> broken thumbnailer, but that should not make Nautilus unusable.

nautilus output is attached here.

> > - I don't know how to go to ~/.gvfs on nautilus, because of the issue I wrote
> > first
> You can use other tools, like mc (Midnight Commander) in a terminal or bash
> commands

Well, actually I tried
$ ls -al ~/.gvfs
$ cd ~/.gvfs
but they all hang... It seems that nautilus is hanging just
because nautilus cannot access to ~/.gvfs

By the way with kernel 2.6.27.21-170.2.56.fc10.i686
--------------------------------------------------------
$ ls -al ~/.gvfs
合計 24
dr-x------ 3 tasaka1 tasaka1 0 2009-04-04 01:06 .
drwx------. 244 tasaka1 tasaka1 20480 2009-04-04 01:06 ..
drwx------ 1 tasaka1 tasaka1 0 1970-01-01 09:00 ftp %28ftp.riken.go.jp%29
--------------------------------------------------------

Hmm, it seems like there is something wrong in the kernel wrt fuse mounts. But I don't see anything weird in the dmesg output.

Any chance you could try various kernel versions to try to figure out the first broken one?

Umm.. After installing various old kernel and updating
rpms, suddenly I got unable to reproduce this issue even with
kernel-2.6.29.1-52.fc11.i586, kernel-2.6.29.1-54.fc11.i586 ????
I don't know what actually changed, however currently
2nd login to GNOME works...

If it is still impossible for me to reproduce this issue
within 2 days, I will close this bug...

Once close this bug, thanks.

mount S ffff8801356bc340 0 2506 2499
ffff8800b194fc18 0000000000000086 0000000002362000 0000000081878430
ffff8800b194fc68 ffffffff8178a380 ffff8800b1f40380 ffff8800b1f40380
ffffffff8178a380 0000000100000696 ffff88012c091720 ffff8800b1f40000
Call Trace:
[<ffffffff8102bfb3>] ? default_spin_lock_flags+0x9/0xe
[<ffffffffa03a3afb>] fuse_get_req+0xc1/0x166 [fuse]
[<ffffffff8105ec23>] ? autoremove_wake_function+0x0/0x39
[<ffffffffa03a41e6>] fuse_getxattr+0x58/0x14f [fuse]
[<ffffffff810ecd57>] ? mntput_no_expire+0x36/0x150
[<ffffffff8118189a>] get_vfs_caps_from_disk+0x52/0xcd
[<ffffffff810df522>] ? path_to_nameidata+0x29/0x3e
[<ffffffff81088381>] audit_copy_inode+0x83/0xb1
[<ffffffff810888c7>] __audit_inode+0x1ee/0x1fd
[<ffffffff810df628>] ? path_put+0x22/0x26
[<ffffffff810dfbf4>] audit_inode+0x28/0x2a
[<ffffffff810e18f9>] do_path_lookup+0x150/0x173
[<ffffffff810e2dfc>] user_path_at+0x56/0x93
[<ffffffff810ecd57>] ? mntput_no_expire+0x36/0x150
[<ffffffff810db03c>] sys_readlinkat+0x2d/0x91
[<ffffffff813b02bc>] ? trace_hardirqs_on_thunk+0x3a/0x3c
[<ffffffff810db0bb>] sys_readlink+0x1b/0x1d
[<ffffffff810113ba>] system_call_fastpath+0x16/0x1b
bash S ffff880138c6a700 0 2922 2896
ffff88009f3dbba8 0000000000000086 00000000069f3000 0000000081879530
ffff88009f3dbbf8 ffffffff8178a380 ffff88009f1f1aa0 ffff88009f1f1aa0
ffffffff8178a380 00000001000006c6 ffff8800ad8fae40 ffff88009f1f1720
Call Trace:
[<ffffffff8102bfb3>] ? default_spin_lock_flags+0x9/0xe
[<ffffffffa03a3afb>] fuse_get_req+0xc1/0x166 [fuse]
[<ffffffff8105ec23>] ? autoremove_wake_function+0x0/0x39
[<ffffffffa03a41e6>] fuse_getxattr+0x58/0x14f [fuse]
[<ffffffff810ecd57>] ? mntput_no_expire+0x36/0x150
[<ffffffff8118189a>] get_vfs_caps_from_disk+0x52/0xcd
[<ffffffff810df522>] ? path_to_nameidata+0x29/0x3e
[<ffffffff81088381>] audit_copy_inode+0x83/0xb1
[<ffffffff810888c7>] __audit_inode+0x1ee/0x1fd
[<ffffffff810df628>] ? path_put+0x22/0x26
[<ffffffff810dfbf4>] audit_inode+0x28/0x2a
[<ffffffff810e18f9>] do_path_lookup+0x150/0x173
[<ffffffff810e2dfc>] user_path_at+0x56/0x93
[<ffffffff813b043a>] ? _spin_lock+0xe/0x11
[<ffffffff810ecd57>] ? mntput_no_expire+0x36/0x150
[<ffffffff810db1a0>] ? cp_new_stat+0xe3/0xf0
[<ffffffff810db517>] vfs_stat_fd+0x24/0x4f
[<ffffffff810db5b5>] sys_newstat+0x27/0x41
[<ffffffff8108a89e>] ? audit_syscall_entry+0x11e/0x14a
[<ffffffff813b02bc>] ? trace_hardirqs_on_thunk+0x3a/0x3c
[<ffffffff810113ba>] system_call_fastpath+0x16/0x1b
lsof S ffff88006792bc28 0 3492 1
ffff88006792bc18 0000000000000082 ffff8800280403f0 0000000081879530
ffff88006792bc68 ffffffff8178a380 ffff88006ccb31c0 ffff88006ccb31c0
ffffffff8178a380 00000001000006c6 ffff88013aa9c560 ffff88006ccb2e40
Call Trace:
[<ffffffff8102bfb3>] ? default_spin_lock_flags+0x9/0xe
[<ffffffffa03a3afb>] fuse_get_req+0xc1/0x166 [fuse]
[<ffffffff8105ec23>] ? autoremove_wake_function+0x0/0x39
[<ffffffffa03a41e6>] fuse_getxattr+0x58/0x14f [fuse]
[<ffffffff810ecd57>] ? mntput_no_expire+0x36/0x150
[<ffffffff8118189a>] get_vfs_caps_from_disk+0x52/0xcd
[<ffffffff810df522>] ? path_to_nameidata+0x29/0x3e
[<ffffffff81088381>] audit_copy_inode+0x83/0xb1
[<ffffffff810888c7>] __audit_inode+0x1ee/0x1fd...

fs/fuse/dev.c:104
        intr = wait_event_interruptible(fc->blocked_waitq, !fc->blocked);

The reporter asked for this bug to be closed, so I'm going to close it. If this is still happening with current kernels (kernel-2.6.29.2-126.fc11 or newer) please re-open.

reopening once again, it still happens. Happening on kernels as late as 2.6.30-rc5-next-20090511 if that's new enough for you.

(In reply to comment #21)
> reopening once again, it still happens. Happening on kernels as late as
> 2.6.30-rc5-next-20090511 if that's new enough for you.

Can you clarify the scenario needed to reproduce this issue? So far it seems that only the two if you in this bug (and now only you) are seeing this issue, so I'm going to have a hard time leaving this on the blocker list.

Can't explain it at all. I've had it happen on both of the last 2 F11 installs I did. Never seemed to do it to start with and then pop, it would start to happen. I reinstalled with the exact same set of package out of rawhide and it would work for a while. Then it would come back.... Updating/changing kernels obviously has no affect....

If you see fusermount and mount after you are logged in you hit the problem...

-Eric

I don't think we have enough information about this issue to really block the release. It is annoying yes, and we'll want to get it fixed, but I don't think we'll hold the release for this issue.

eparis: Could this related to your authentication/user_info settings?

The only thing interesting about my user is that I have it as an selinux confined user, staff_u

semanage login -a -s staff_u -r s0-s0:c0.c1023 eparis

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

*** Bug 506539 has been marked as a duplicate of this bug. ***

Several interesting comments can be found in bug 506539

Just so people know, as root, if you kill -9 both the 'mount' and 'fusermount' process, everything starts to work just fine. Need to find a way to strace the mount/fusermount. But I reinstalled and it went away. I'm sure it'll come back....

Hi there, I am the guy from ex Bug 506539.
It is pretty clear, that it's any fuse thing which can cause this hang of things which want to read the fuse-mounted directorys - i.e. also sshfs.

So I just straced sshfs as root, mounting user blub of moviestation:/home/blub into /root/temp/huch (in the middle I had to enter the password, until this part it works, after entering the password it pukes a lot more into the strace output file and stops when it tries to access the freshly created mountpoint, at least this is where the strace stops as you can see). For the hackerkiddies out there: Its a dummy user with a dummy password on a dummy machine running on freebsd.

Maybe this helps a bit (I am absolutely not the one who is able to interpret that strace stuff - so maybe the whole action is a bit naive).

I mean - err - fuse just *has* to work! Really! (But you know this already I guess :) )

What's also interesting. I know for sure that sshfs did work right after installing fedora 11, also after installing that famous first 110 MB updates (reduced to bits by presto), and so did gvfs.
That would mean nothing less than this is *not* kernel related in the first line. Maybe other kernel modules start to fight back after a while, I dunno.

I will hang in the strace output file of my sshfs experiment within the next minutes.
Regards, Herr Irrtum

Created attachment 348532
straced output of sshfs as root which fails to mount something

straced output of sshfs as root, mounting user blub of moviestation:/home/blub into /root/temp/huch

hmmm, not as interesting as I might have hoped. Can you do with with -f added to strace?

(In reply to comment #33)
> hmmm, not as interesting as I might have hoped. Can you do with with -f added
> to strace?

it was already straced with -f, sorry.

But some new brain storm fodder:

I tried it once more in a slightly different setting (as user, which is the mail purpose of fuse - not as root)
Fusemount did hang as usually so I had to kill it (did that as root).
And then there was a interesting output on the user console:

>fusermount: failed to access mountpoint /home/xxxxx/xxxx/temp: Permission denied

You have to know, I created temp as a user , just "mkdir temp" so permissions looked like this before usermount:

>drwxrwxr-x 2 user usergroup 4096 19. Jun 09:58 temp

Now after killing any fuse process, permissions look different:

>d?????????? ? ? ? ? ? temp

errr?!

This reminds me of things years ago: To use fusermount as a user, the user has to be in a group, fuse.
Is this still the case, especially on fedora?!
On my system, there is no group "fuse". and so my user is not part of this.
My user is not even part of "users" its just user: username(500); prim.group: username(500) and additionally group: vboxusers.
But fuse is even failing under "root", so this is probably not something to hunt down in the first line.

Anyway, researching more about this, I stumbled upon this:
<https://bugs.launchpad.net/ubuntu/+source/sshfs-fuse/+bug/123501>

where someone is pointing out, that /dev/fuse should have the right permissions set.

Mine is
>crw-rw-rw- 1 root root 10, 229 19. Jun 2009 /dev/fuse

For me this looks quite sane at least to make fuse to work for root.

.
Enough bubbling.

------------------------------------------------------------------------------
The priority question is: Why is fuse changing the permissions of a mount point to

>>d?????????? ? ? ? ? ? mountpoint

permanently, even after killing all fuse processes?
------------------------------------------------------------------------------

What I personally wonder is, if a fuse group is necessary on fedora (I guess, no).

+++ Solution ++++ Solution +++ Solution ++++

I can not cry it out loud enough - sorry for a slightly notable enthusiasm overkill :) - but I found the solution (it is not *exactly* the source of it, but in a unspecific way it is).

Today I got a new regular kernel per yum update.

Tried out sshfs - still the same.

Now I did again some research - and all in all it is really easy - you only need to know how fuse ticks to get to the solution.

Fuse is "file system in userspace". It relies heavily on sysfs, which just makes something like a file system in userspace possible at least.
But sysfs at fedora is not something you get as a "single app" it is just a lib which is used by... udev.

So basically udev (something like a "device in userland") makes fuse possible.

So I just did

>yum reinstall udev

rebooted just in case.

And that was it!
Fuse works in all it's beauty.

Regards,
Herr Irrtum

PS. One question remains: What did alter udev in such a bad way?! If I find out, I'll post it (but I hope I never will experience this again)

I think I found what is causing this udev problem.

The suspicious thing is the virtual box kernel module - but I am not sure if it is really to blame - because if I remove it from the services (so lsmod does not list it) and even remove it's udev ruleset entry under /etc/udev/rules.d (and rebooting) fuse does not come back to live.

So at the moment I can't use fuse, and I don't know how to re enable it - even reinstalling udev does not work for now.

Why do I find Virtual box suspicious?

At first, when I talk about virtual box, I mean the "Personal Use and Evaluation License" edition - installed from the fedora rpm at the vbox website - not the OSE edition from rpmfusion!

The normal mechanism is:
When getting a new kernel via yum update, self compiled kernel modules like "vboxdrv" have to be compiled again.

So when I got my last kernel update, the virtual box kernel module (in short "vboxdrv") did not load because it was build for the old kernel. I was not aware of this because I don't use virtual box all the time. After reinstalling udev, fuse did work again (as described in my last post here).

But after a time I had to use virtual box, had to compile vboxdrv again (this is archived almost automatically by activating a script via "/etc/init.d/vboxdrv setup").
Now it took some time that I had to use fuse again - and to discover it does not work again. So the only new kernel module I did install for sure was vboxdrv.

The thing which speaks against my theory is, that removing vboxdrv from the init scripts and removing it's ruleset from udev does not help. In the beginning of my bug reports (before the kernel update) I even did uninstall the whole vbox package (because this was supposed in some forum), which did not help either.

So maybe it is the script which starts when doing "/etc/init.d/vboxdrv setup" and doing something strange... but I do not have time right now to look at it.

Can someone confirm this correlation with Virtual Box, or even confirm if compiling any "own" kernel modules may disturb fuse or udev?

I have this appear on a fresh installation of F11 x86_64. I can rmdir the ~/.gvfs using the rescue disk, but a few days later, it again becomes inaccessible and causes programs to hang trying to stat() ~/.gvfs.

Not running Virtual Box or custom kernel.

Are there any particular tests or logs you'd like run/collected to get to the bottom of this?

*** Bug 510870 has been marked as a duplicate of this bug. ***

*** Bug 513050 has been marked as a duplicate of this bug. ***

I get this bug without VirtualBox installed, but on the other hand, I do have VMware. But I wasn't running it at the time, and I haven't even been able to compile the kernel modules for this new kernel yet, so they couldn't have been loaded. On the other hand, I do have the RPMfusion akmods and akmod-nvidia-173xx, plus their own kmod-nvidia-173xx packages, giving me extra kernel modules. Currently using kernel-PAE-2.6.29.6-213.fc11.i686, gvfs-1.2.3-8.fc11.i586, fuse-2.7.4-3.fc11.i586, udev-141-4.fc11.i586, and kmod-nvidia-173xx-2.6.29.6-213.fc11.i686.PAE-173.14.18-2.fc11.11.i686.

And just to add a bit to why this needs to be fixed, this has been causing things like mlocate's daily updatedb and the daily rkhunter to hang when they hit the user's directory, so for example my mlocate.db hasn't been successfully updated since the 24th. And when I realize this is happening again, I have to go through the process list, kill-9ing updatedb and rkhunter process left and right.

Plain clean F11 installation, same problem here.

I first noticed it two days after a clean install, the gnome file manager freezes when opening the home (and only the home) directory.

I killed all gvfs related processes, reinstalled udev (as the poster in comment #35 and so far its working ok.

There is definitely something wrong here.

Ok - and let me add...

Today I noticed that cron.daily had stopped running. The cron error log said that /etc/cron.daily was locked by another process... seemed simple, until lsof /etc/cron.daily also hung.

I was rather perplexed. lsof without parameters also hung. Turned off selinux (setenforce 0) ... same issue.

did strace lsof /etc/cron.daily... low and behold, last line was a user's /home/<user>/.gvfs.

Killed all the mounts (fusermount, mount, daemon, etc.) and anacron kicked right in and started running the overdue jobs.

Needless to say, that user space activities affect system administrative functions isn't really a good thing.

I have looked at the upstream bug reports, and would suggest absent the necessary upstream philosophical changes that fedora disable the feature by default.

*** Bug 517946 has been marked as a duplicate of this bug. ***

After playing with some seedit utilities I ended up unable to use any fuse file
systems. Trying to mount a fuse system would just freeze along the way leaving
the mount point in an intermediate state. For example trying to do
 ls ~/.gvfs
would just hang. Another consequence is that nautilus would freeze when trying
to look at my home directory (because of the presence of .gvfs)

After a lot of exploration I found that the culprit was the audit service and
in particular a rule that got added by some utilites along the way.

Removing this rule fixed the problem. After this all fuse mount started to work
again.

I guess this is probably a kernel bug...
Comments from BZ 517946:

I know I have audit rules loaded (auditctl -l) how many other people who are experiencing this problem have audit rules loaded?

Version-Release number of selected component (if applicable):
Fedora 11
audit-1.7.13-1.fc11
a bunch of kernels:
kernel-2.6.29.4-167.fc11.i586, kernel-2.6.29.6-217.2.7.fc11.i586

How reproducible:
Always

Steps to Reproduce:
1. have the the following rule in /etc/audit/audit.rules
-a exit,always -S chroot
2. have the auditd service started
3. Try to mount any fuse filesystem (logging in in gnome will try to mount
     ~/.gvfs)
4. Any access to the mount will block, for example try:
    ls ~/.gvfs
5. Also note that some additional processes are left running (like a mount -i
...)

Actual results:
The ls just hangs there and does not return to the shell unless it is killed.

Expected results:
The ls should run normally, display results (maybe nothing) and return to the
shell.

FWIW, I do have that audit rule as well. Haven't tried removing as I've removed gvfs.

(In reply to comment #44)

Hi Eric,
thanks a lot - you did a hell of a detectives job finding out about that auditd service (which I never ever would have suspected - I thought it just "collects security related events in a dedicated audit log" as i.e. system-config-services is hinting).
Anyway: Just commenting out that...

"# -a exit,always -S chroot"

...line from /etc/audit/audit.rules and restarting the daemon did not help here (but maybe "/etc/init.d/auditd restart" isn't strict enough).

However...

*brutally halting auditd with "/etc/init.d/auditd stop" did the job*

...and sshfs was working again!

So thanks again for fighting down to the source of that bug!

Regards,
Herr Irrtum

PS: Sidenote: I still have selinux disabled.

PS2: I am not sure if it is a good idea to disable auditd completely, as I am absolutely confused about what it's good for anyway (as security logging does not seem to be the only purpose... but maybe I am wrong again here). So don't use this as a general workaround as long as you do not know what you are doing!

I removed ALL the rules from /etc/audit/audit.rules and things started working again, even with auditd running.

I restored them one at a time and restarting auditd. I discovered that restoring ANY rule would cause the bug.

I did some research and discovered that these rules are related to SELinux. In a recent upgrade from FC9 to FC11, I changed the SELinux status in /etc/selinux/config from Permissive to Disabled. When I changed it back and rebooted (and sat through the relabeling of my entire filesystem), voila, everything is back to normal. I have restored all the audit rules and restarted auditd, with no trouble.

Just some FYI. I do not have selinux or audit installed at all and I have this problem. For me, the priority on this ticket is high as it is breaking my backups (they hang every night when trying to lstat .gvfs).

Same here, selinux is disabled and audit is not installed and I'm also having this problem.

Yes, I clearly spoke too soon. The problem went away temporarily, but then returned with a vengeance (I actually tried to USE gvfs-fuse). I removed gvfs-fuse (and totem) and the problem went away, though the bug remains.

over at <a href=https://bugzilla.redhat.com/show_bug.cgi?id=503956>Bug 503956</a>, a sister to this bug, some users are reporting success by running fsck. It didn't work for me, however.

I am running F11 x86_64. I do not have VirtualBox. I am not using any fuse filesystem except the auto-mounted /home/mkanat/.gvfs (which I'm not *using*, it's just *there*). I have no custom audit rules. SELinux is in permissve mode.

After logging out in GNOME, I 100% of the time could not log back in again unless I rebooted or did a "kill -9" on the hung gvfs*/*mount processes.

I did:

restorecon -Rv /home/mkanat

And now I can consistently log out and log in again without a hang.

One odd thing is that it actually told me that it couldn't correct the /home/mkanat/.gvfs file's context, but it seems to be OK now anyway (system_u:object_r:fusefs_t:s0). I unfortunately did not check what its context was before the restorecon.

*** Bug 528970 has been marked as a duplicate of this bug. ***

This is a bit more information based on another user's struggles getting fuse back. The system is F11 x86_64, 2.6.30.9-96.fc11.x86_64.

Punch line: service stop auditd;fuseiso <.iso> <dir>; service start auditd
... and I can accomplish what is needed to use fuse modules.

The server had been running since ... F9(?) with SELinux disabled. Note that restorecon (as in comment 53) returned immediately while SELinux is disabled. I changed /etc/sysconfig/selinux to SELINUX=permissive, rebooted, and relabeled. Note that disabling auditd did not prevent the hang until after the relabel and SELinux was running in permissive mode.

This is similar to comment 47, except the default auditd rules do show this bug.

Note that this bug occured with any fuse filesystem (including the demo 'hello' one available at the sourceforge site for the project.)

Will somebody who doesn't have audit installed and is still seeing this problem get sysrq-t when the box hangs so I can see where we're stuck.

To get sysrq-t you want to be root and do

echo 1 > /proc/sys/kerne/sysrq
echo t > /proc/sysrq-trigger

and then get /var/log/messages. If you cannot log in as root from the console ore something like that you can just edit /etc/sysctl.conf and set kernel.sysrq = 1 and then reboot, and then when the box hangs you can hit alt+sysrq(printscrn)+t and then get /var/log/messages.

I'm interested in the output from sysrq-t for anyone who has audit disabled and is able to hit this issue. I think you would just need to reproduce then

echo "7 7 7 7" > /proc/sys/kernel/printk
echo t > /proc/sysrq-trigger

Then attack /var/log/messages

(In reply to comment #55)
> This is a bit more information based on another user's struggles getting fuse
> back. The system is F11 x86_64, 2.6.30.9-96.fc11.x86_64.
>
> Punch line: service stop auditd;fuseiso <.iso> <dir>; service start auditd
> ... and I can accomplish what is needed to use fuse modules.
>
> The server had been running since ... F9(?) with SELinux disabled. Note that
> restorecon (as in comment 53) returned immediately while SELinux is disabled.
> I changed /etc/sysconfig/selinux to SELINUX=permissive, rebooted, and
> relabeled. Note that disabling auditd did not prevent the hang until after the
> relabel and SELinux was running in permissive mode.
>
> This is similar to comment 47, except the default auditd rules do show this
> bug.
>
> Note that this bug occured with any fuse filesystem (including the demo 'hello'
> one available at the sourceforge site for the project.)

Brief Follow up. I disabled selinux (in /etc/sysconfig/selinux) and rebooted, and am now able to use fuse after stopping auditd. I think the only substantial change was the relabel when I had booted into permissive?

Patch posted upstream, we'll see if its acceptable

http://marc.info/?l=linux-fsdevel&m=125805866918258&w=2

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

When audit is enabled (for example by readahead-collector), there is a deadlock
when gvfs-fuse-daemon launches mount (through fuse lib) to update fstab, and
mount calls readlink to canonalize the mountpoint, and audit requests the
xattrs of this directory, which is mounted so fuse asks the daemon which is currently blocked in waitpid, waiting for mount to exit.

The simple patch is (in fuse) to not wait for mount to return when updating
fstab.

This is exactly the same bug that happened with ntfs-3g in bug 486619 but was only fixed in the internal copy of fuse code.

*** Bug 503956 has been marked as a duplicate of this bug. ***

Ok it seems that Miklos's inclination is to fix this by making mount/fusermount
not canonicalize the mountpoint so we don't run into this problem. I'll keep
this bug updated with the progress on the problem, hopefully we'll have
something workable in fedora soonish.

I'm marking this as a common bug for Fedora 12.

Does anyone have the patch described in comment 61?

bug still exists in 2.6.31.12-174.2.3.fc12. Is anyone working this? Is there any information needed to fix it?

This is not a kernel bug. It is a fuse-utils/util-linux bug. I believe the util-linux package has been updated but the fuse-utils package has not. I'm reassigning to fuse-utils and hopefully we can get the fix.

http://kerneltrap.org/mailarchive/linux-fsdevel/2009/11/12/6569103/thread

Explains the details. You should call mount with --no-canonicalize

*** Bug 533186 has been marked as a duplicate of this bug. ***

eric: not possible in F12 currently, as that option was only added to util-linux-ng 2.17 (as discussed in the thread you link). Perhaps we should port it to 2.16 for F12?

Nominating for F13Target since this is listed on F12 Common Bugs.

*** Bug 562451 has been marked as a duplicate of this bug. ***

I think the relationship to F13Target is the wrong way around.

Running LXDE on an up-to-date FC alpha RC4 with the following:
gvfs-obexftp-1.5.4-2.fc13.i686
gvfs-fuse-1.5.4-2.fc13.i686
gvfs-gphoto2-1.5.4-2.fc13.i686
gvfs-archive-1.5.4-2.fc13.i686
gvfs-smb-1.5.4-2.fc13.i686
gvfs-1.5.4-2.fc13.i686
kernel-2.6.33-0.52.rc8.git6.fc13.i686
util-linux-ng-2.17.1-1.fc13.i686
fuse-2.8.1-4.fc13.i686
fuse-libs-2.8.1-4.fc13.i686

Had my roxterm lock up when I entered the command: ls -al

At the time of the lockup:
~$ ps aux | grep gvfs
a 1696 0.0 0.0 7900 2048 ? S 05:19 0:00 /usr/libexec/gvfsd
a 1712 0.0 0.0 5232 1416 ? S 05:19 0:00 /usr/libexec//gvfs-fuse-daemon /home/a/.gvfs
root 1780 0.0 0.0 1996 696 ? S 05:19 0:00 fusermount -o rw,nosuid,nodev,subtype=gvfs-fuse-daemon -- /home/a/.gvfs
root 1797 0.0 0.0 4572 724 ? S 05:19 0:00 /bin/mount -i -f -t fuse.gvfs-fuse-daemon -o rw,nosuid,nodev,user=a gvfs-fuse-daemon /home/a/.gvfs

Killing job 1797 unlocked the system and the listing proceeded

I believe I've encountered this problem when using the fusecompress package on Fedora 12. If a fusecompress mount is listed in fstab (as auto) then the Fedora will hang during boot. If the mount is carried out in rc.local then the system will boot but the mount will never complete.

A workaround until someone applies the fixes...

mv /usr/libexec/gvfsd /usr/libexec/gvfsd.hangs.see-bugzilla-493565

... and live without gvfs for the time being.

(In reply to comment #76)
> A workaround until someone applies the fixes...
>
> mv /usr/libexec/gvfsd /usr/libexec/gvfsd.hangs.see-bugzilla-493565
>
> ... and live without gvfs for the time being.
Please do not post such ideas here in bugzilla. I won't be dealing with bugs reporting completely broken desktop just because someone's suggestion. This is not Ubuntu forums...

Any chance this is getting fixed soon? It really messes up software development for utilities that walk the file system.

(In reply to comment #77)
> (In reply to comment #76)
> > A workaround until someone applies the fixes...
> >
> > mv /usr/libexec/gvfsd /usr/libexec/gvfsd.hangs.see-bugzilla-493565
> >
> > ... and live without gvfs for the time being.
> Please do not post such ideas here in bugzilla. I won't be dealing with bugs
> reporting completely broken desktop just because someone's suggestion. This is
> not Ubuntu forums...

This bug is almost a year old and effects 3 of my 4 machines daily. Is there a work-a-round that is acceptable?

1) The solution proposed in comment #76 is not a "workaround," it entirely disables the offending software.
2) The only known workaround is in comment #30, which is to kill -9 all fusermount processes and any related mount processes. You may also, if you wish, kill the gvfs-fuse-daemon, which will prevent a recurrence until the next reboot.
3) The only known solution is to disable or remove gvfs-fuse. The problem with disabling it by the method in comment #76 is that it will be re-enabled (and re-broken) when and if an upgrade occurs. Unfortunately, the Fedora packaging gods decided that Totem depends on gvfs-fuse (even though it doesn't), and therefore anytime you upgrade or reinstall Totem, this bug will be back if you use the comment #76 method.
4) The only "acceptable" solution, therefore, is to remove gvfs-fuse entirely (#yum remove gvfs-fuse). This will also remove Totem from your system. See comment #50. Given the choice between excluding Totem (there are many other video players around) vs. a system that hangs every time anyone using Nautilus logs in, I choose to live without Totem.
5) Removing gvfs-fuse entirely means it will not automatically upgrade if and when this bug is fixed. (The solution has been found but not yet incorporated into Fedora; see comment #68 and comment #70.) Thus, subscribe to this bug for news.

> (In reply to comment #79)
> (In reply to comment #77)
> > (In reply to comment #76)
> > > A workaround until someone applies the fixes...
> > >
> > > mv /usr/libexec/gvfsd /usr/libexec/gvfsd.hangs.see-bugzilla-493565
> > >
> > > ... and live without gvfs for the time being.
> > Please do not post such ideas here in bugzilla. I won't be dealing with bugs
> > reporting completely broken desktop just because someone's suggestion. This is
> > not Ubuntu forums...
>
> This bug is almost a year old and effects 3 of my 4 machines daily. Is there a
> work-a-round that is acceptable?

"Unfortunately, the Fedora packaging gods decided that Totem depends on gvfs-fuse (even though it doesn't), and therefore anytime you upgrade or reinstall Totem, this bug will be back if you use the comment #76 method."

There are no 'Fedora packaging gods', just packagers. The Totem packager is Bastien Nocera. He's not a god. I've checked. If you think the dependency is incorrect, file a bug. He will either remove it or explain why he considers it to be a dependency. Note that Fedora has no concept of soft dependencies, so packagers sometimes set hard dependencies on packages which aren't strictly _required_ for the software to function, if they feel that most users will expect the 'optional' functionality to be present, and would not know how to add it manually.

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

This bug should block F13Target rather than depend on F13Target (since this bug can be fixed without fixing F13Target). I do not have permissions to fix this myself.

Fixed dependency/block relationships.

This bz depends on 577947, since we need mount to have the --no-canonicalize option. Once util-linux-ng is updated, fuse can be updated to 2.8.3 and this problem will go away.

Are the target bugs actually used for anything these days? I think I've seen some discussion about Fedora possibly not using target bugs at all in the future. Should this bug rather depend on the Fedora 13 Blocker bug?

It's not a release blocking issue.

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Re comment 86, I can see that this might not block the release, but in that case is there a status that says, if this bug isn't fixed by F13, remove the software from the release?

Just how defective does software have to be to be pulled? Something that verifiably prevents all logins every time it is used would seem to me to be a problem.

Re comment 70, this makes total sense to me but it should be backported to F11 too.

Re comment 81, thanks for the info!

"Re comment 86, I can see that this might not block the release, but in that
case is there a status that says, if this bug isn't fixed by F13, remove the
software from the release?"

No.

"Just how defective does software have to be to be pulled? Something that
verifiably prevents all logins every time it is used would seem to me to be a
problem."

I don't know if there's a definitive policy on this. You could perhaps bring it to the attention of FESCo or the packaging committee?

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Ok now that

https://bugzilla.redhat.com/show_bug.cgi?id=577947

has made it into F12, all that needs to be done is fuse needs to be updated to 2.8.3. Once thats done this problem will go away.

*** Bug 582878 has been marked as a duplicate of this bug. ***

Very annoying bug, nice to see
a progress with it.
But I am having the different
trace, in my case the lstat causes
the problem, and not readlink().
Does this make any difference?

mc S ffff88007b1ba800 0 3628 2668 0x00000080
 ffff8800354a9cc8 0000000000000082 000000006d2c3a80 ffffffff81a01218
 00000010354a9c38 ffffffff8112eef5 ffff8800354a9fd8 ffff8800354a9fd8
 ffff88005291c9f8 000000000000f980 0000000000015740 ffff88005291c9f8
Call Trace:
 [<ffffffff8112eef5>] ? dput+0x45/0x131
 [<ffffffffa0443c77>] fuse_get_req+0xae/0x13f [fuse]
 [<ffffffff810748ab>] ? autoremove_wake_function+0x0/0x39
 [<ffffffff811ec9fc>] ? inode_has_perm+0x7a/0x90
 [<ffffffffa0444596>] fuse_do_getattr+0x3c/0x24b [fuse]
 [<ffffffff8110b643>] ? virt_to_head_page+0xe/0x2f
 [<ffffffff811ece51>] ? dentry_has_perm+0x5a/0x70
 [<ffffffffa044606b>] fuse_update_attributes+0x30/0x5f [fuse]
 [<ffffffffa04460e3>] fuse_getattr+0x49/0x4e [fuse]
 [<ffffffff8111f985>] vfs_getattr+0x48/0x66
 [<ffffffff8111f9ee>] vfs_fstatat+0x4b/0x62
 [<ffffffff8111fa60>] vfs_lstat+0x1e/0x20
 [<ffffffff8111fa81>] sys_newlstat+0x1f/0x3d
 [<ffffffff81125373>] ? path_put+0x22/0x26
 [<ffffffff81011d32>] system_call_fastpath+0x16/0x1b

Here is what I did to (temporarily?) fix the problem:

yum remove gvfs-fuse totem-nautilus totem gvfs-smb bluez nautilus gvfs-gphoto2 gvfs-archive gvfs gvfs-obexftp gnome-bluetooth pulseaudio-module-bluetooth
rm -rf ~/.gvfs
reboot
yum install gvfs-fuse totem-nautilus totem gvfs-smb bluez nautilus gvfs-gphoto2 gvfs-archive gvfs gvfs-obexftp gnome-bluetooth pulseaudio-module-bluetooth
reboot

Obviously, this is a quick fix until the problem is really solved -- hopefully in F13.

I forgot to add what I current have on my system--

totem-2.28.5-1.fc12.x86_64
pulseaudio-module-bluetooth-0.9.21-5.fc12.x86_64
nautilus-extensions-2.28.4-2.fc12.x86_64
nautilus-sendto-2.28.2-2.fc12.x86_64
gvfs-archive-1.4.3-7.fc12.x86_64
bluez-cups-4.58-1.fc12.x86_64
gnome-bluetooth-libs-2.28.6-2.fc12.x86_64
gvfs-smb-1.4.3-7.fc12.x86_64
totem-nautilus-2.28.5-1.fc12.x86_64
bluez-4.58-1.fc12.x86_64
brasero-nautilus-2.28.3-1.fc12.x86_64
bluez-libs-4.58-1.fc12.x86_64
gvfs-1.4.3-7.fc12.x86_64
gvfs-obexftp-1.4.3-7.fc12.x86_64
nautilus-2.28.4-2.fc12.x86_64
totem-pl-parser-2.28.2-1.fc12.x86_64
gvfs-gphoto2-1.4.3-7.fc12.x86_64
totem-mozplugin-2.28.5-1.fc12.x86_64
gvfs-fuse-1.4.3-7.fc12.x86_64
gnome-bluetooth-2.28.6-2.fc12.x86_64

(In reply to comment #92)
...
> rm -rf ~/.gvfs
...

This will reliably delete all data from your active mounts (FTP, SFTP, SMB etc.).

"ls -la" in the home directory also hangs on F13.

I can also confirm this happens on F13.

Confirming bug in F13 . The same after all updates .

ARGH - This are really the audit-rules
After comment out them fuse works again

So the following report from me is the same and has nothing to do with umask
https://bugzilla.redhat.com/show_bug.cgi?id=585302
______________________________________

[root@srv-rhsoft:~]$ cat /etc/audit/audit.rules
# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 320

# Feel free to add below this line. See auditctl man page
# -w /etc/passwd -p wa -k password-file
# -w /etc/group -p wa -k password-file
# -w /etc/shadow -p wa -k password-file
# -w /etc/gshadow -p wa -k password-file
# -w /root/.ssh/authorized_keys2 -p wa -k ssh-keyfile

I'm not running auditd and I still get hangs on 'ls -al ~', so it's doubtful that audit's involved.

*** Bug 585302 has been marked as a duplicate of this bug. ***

(In reply to comment #99)
> I'm not running auditd and I still get hangs on 'ls -al ~', so it's doubtful
> that audit's involved.

I can confirm this too .

I disabled audit service, removed gvfs.fuse via yum but still having this problem.

After repeating these steps in F12 I wrote above, there was no problem .
But in F13 it does not help. I can view home folder a couple of times after reboot then it hangs after 5~6 minutes uptime.

In response to comment #101, this must be some new problem. Can you give the output of ps -ef | grep mount during the hang? Can you also run

echo t > /proc/sysrq-trigger

and then attach the resulting output in /var/log/messages?

Fuse still needs to be updated to take advantage of the new --no-canonicalize option in util-linux. Until fuse is updated to 2.8.3 or later this problem will continue to happen. I'm not the maintainer of fuse for Fedora so I can't do it, whoever owns the package is going to have to do it.

I'll update fuse shortly.

Folks, next time, please, file tickets against fuse and not against fuse-utils.

fuse-2.8.4-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/fuse-2.8.4-1.fc12

fuse-2.8.4-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/fuse-2.8.4-1.fc11

fuse-2.8.4-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/fuse-2.8.4-1.fc13

Folks, please install fuse from updates-testing and leave a comment in Bodhi about whether this build fixes this issue or not.

I, personally, can't say anything about this issue because I don't use gfvs at all (although it does installed on my machines as a dependency) - at least this build doesn't break anything.

The update above works. Problem solved.

fuse-2.8.4-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.

fuse-2.8.4-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.

fuse-2.8.4-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.

Tested on fedora 12 with fuse-2.8.4-1.fc12. fusecompress still hangs the system on boot if auto mounted in fstab.

(In reply to comment #111)
> fuse-2.8.4-1.fc11 has been pushed to the Fedora 11 stable repository. If
> problems still persist, please make note of it in this bug report.

Still hangs on Fedora 11, which is using util-linux-ng version 2.14.2-11.

If I understand comment #68 and comment #70 correctly, the solution requires a "--no-canonicalize" option for mount. I have no idea where in the guts of the system this would take place, but I also understand from the same comment that util-linux-ng needs to be at least version 2.17 for this to work.

Since util-linux-ng goes SO deep into the system, I am wary of any experimenting. I assume, therefore, that I will need to upgrade at least to FC12 for this to work, but I also see from comment #70 that it hasn't been ported there, either. In fact, the latest I can see for FC12 is 2.16.2-9, so perhaps this will work only with FC13?

In any case, this part of the solution seems to rest with the maintainer of util-linux-ng, who I think is Karel Zak, not with Peter Lemenkov.

I see that Peter Lemenkov asked for comments to be left in Bodhi, which will be my next effort :)

(In reply to comment #108)
> Folks, please install fuse from updates-testing and leave a comment in Bodhi
> about whether this build fixes this issue or not.
>
> I, personally, can't say anything about this issue because I don't use gfvs at
> all (although it does installed on my machines as a dependency) - at least this
> build doesn't break anything.

Though this fix was pushed to FC11, it doesn't solve the problem, as util-linux-ng was never upgraded on FC11. (See comment #70)

From comment #89, I see that util-linux-ng was upgraded on FC12, so perhaps the solution is to move to FC12, but it's kinda pointless to upgrade fuse on FC11 when its companion util-linux-ng problem remains.

> (In reply to comment #111)

> Still hangs on Fedora 11, which is using util-linux-ng version 2.14.2-11.

I was not aware of the status of util-linux-ng in F-11. I'm afraid that it won't be upgraded at all considering that F-11 will be EOLed very soon.

Anyway, I believe that I did my part of job.

> Since util-linux-ng goes SO deep into the system, I am wary of any
> experimenting. I assume, therefore, that I will need to upgrade at least to
> FC12 for this to work, but I also see from comment #70 that it hasn't been
> ported there, either. In fact, the latest I can see for FC12 is 2.16.2-9, so
> perhaps this will work only with FC13?

Yes, I'm afraid so - in order to fix this issue util-linux-ng should be upgraded in F-12 too.

Ok, since now fuse-related part of work was finished, I'm switching this ticket to util-linux-ng, which should be updated in F-12 in order to completely fix this issue.

Hmm..., bug 577947, I see:

* Mon Apr 12 2010 Karel Zak <email address hidden> 2.16.2-9
- fix #577947 - need --no-canonicalize option for mount

bodhi - 2010-05-07 17:25:08
This update has been pushed to stable

https://admin.fedoraproject.org/updates/util-linux-ng-2.16.2-9.fc12?_csrf_token=76c49b8f4800907c7c5dc3f082bf3e5a4a9262d9

Not sure if this is related but it was the bug that came out on a google search and it seems to have similar origin, i.e. fuse.

Question, are fuse mounts supposed to survive reboots?

They did for me once. X hang on my x86_64 nightly updated F13 when trying to display a quite large image from wikipedia. Mouse worked, not keyboard. Ssh'ed from another machine, killed a couple of things to see if I could recover but eventually needed to shutdown -r.

I have pam_ssh installed and modify the pam scripts so I log in with my ssh passphrase. I log on with gdm but run don't run gnome, xinit/xsession/fvwm instead.

When I logged on again I noticed I couldn't ssh to any of the places I usually do, without entering my passphrase, like ssh-agent wasn't proper. Logged off and on a couple of times and no go. Eventually I found that I still had another system fuse mounted, just like it was before the machine was rebooted.

Unmounted that fs, logged off then on, and things are normal again. Strange and scary. Not sure I can replicate it again.

The underlying mount command that is hanging does not hang for users that belong to the 'video' system group.

I took users out of that group which they get put into by default, and the problem happened consistently. Once I put them back in and killed the hung mount processes, the problem no longer happens.

For those following this, I think this bug has reappeared
in Fedora 17. The symptoms are extremely similar (even
the FUSE "hello" example hangs), and disabling selinux fixes
it (but *not* just setting selinux to permissive).

https://bugzilla.redhat.com/show_bug.cgi?id=812798