Red Hat Bugzilla – Bug 506539
homedirs blocked from ls -a after graphical login (kdm and gdm), because of faulty gvfs
Last modified: 2010-03-29 14:45:56 EDT
Created attachment 348298 [details]
Screenshot of Dolphin, Nautilus and ls failing all togehter showing $HOME
Description of problem:
All of the sudden: ls -la did stop working in homedirs this morning. Without an obvious cause. It literally stops by not responding to ls -a, not showing anything. ls without attribute works (not showing .dot entries of course). "cat .bashrc" and similar commands work, it is also possible to cd into subdirs of ~ (also hidden subdirs like .kde).
This is not affecting the root users homedir (/root). However doing this:
>ls -a \home\some_user
does not work (as you can probably see - done from root account).
ls -la works *only* on $HOME if I change into a tty text console right after booting (GDM / KDM login already visible) but before logging in per KDM or GDM (gnome and kde are both affected). When logging out again of KDE or Gnome (so only the GDM / KDM Login Dialog is displayed) ls -a is now also not working in a tty text console.
Affected are ls -a, ls -A (and other ls and ll combinations with a), Dolphin (saying "no elements"), nautilus (just showing a busy mouse-pointer forever), Krusader (not responding after changing to ~) and probably other filemanagers and apps trying to list content in ~. Definitely any "Save under" file dialoges of apps - they work, but need ages for this.
What I've tried so far to get rid of this:
doing a fsck --> nothing found, nothing better
changing from kdm to gdm and back --> nothing better
disable selinux --> nothing better
reenable selinux (targeted mode) --> nothing better
creating a new fresh user and logging in with this account, also after a fresh reboot --> same here
Conclusions out of my experiments: It's definitely *not* about the contents of the homedir. It's not about the filesystem (ext3 btw). Shouldn't be SELinux. May be a policy thing...
I am not the only one facing this problem:
Version-Release number of selected component (if applicable):
can't say which thing causes this. Sorry if you think this is filed at the wrong place - really, there is no drawer for that kind of thing.
It's a very fresh fedora 11 install (5 days running)
- newest yum updates are there,
- also rpmfusion (free and nonfree) are enabled, adobe repos too
- testing is not enabled in any way, never was
Hard to say - it occurred today and is not going away
Steps to Reproduce:
just install a fresh fedora 11 (no updating old fedoras) and do some package installs, nothing spectacular, no heavy by hand modifications, use it as desktop system, wait a week and... maybe... maybe you get it.
What packages did I install before this happend as far as I remember:
- seedit policy (asks for writing config and to reboot, after this I just disabled selinux to get cups working [you know, that "cups not working with selinux problem" well known since fedora9 at least])
(yes, I was bored :) ; meanwhile I deinstalled all 3 of them, but the in parts 32 bit libs remained unfortunatelly)
unstable almost unusable system, due to failed dirlistings of $HOME; i.e. waiting for the "save under" dialog in apps like gimp works (thanks god)... after like 10 minutes
a system where I can peacefully say "ls -lA" at $HOME - even as a root in some users home
Just one question: Why is all this happen to me and not one of the dev-guys?!
Created attachment 348309 [details]
an strace of ls -a stopping directly at the file .gvfs
This makes so much sense, but I did forgot about it in the first place. an strace of ls -la. And see what happens: ls stops exactly at looking up .gvfs
And furthermore: While I can "cat .bashrc" I can not "cat .gvfs" ."cat" simply stops responding.
So this seems to be the root of all evil .gvfs - I can not investigate more now, cause I have a son of 4 and he is hungry now :)
Will be back later (maybe)
I did forget to strace ls -la . Sorry. Now this is done and showing that the file .gvfs is causing the trouble.
Ok - it's solved for me. I did deinstall gvfs - and *zack* I could ls -lA again in peace. Personally I am not interessted in *why* gvfs is failing, because in the first line I am a KDE user (after 3 years being bored to death by gnome :) could not resist to tell you :) ).
However... some notes:
If GVFS runs into a problem, it should not lead into the troubles of just blocking the whole homedir because a dynamic somewhat non functional .gvfs is there. It's like the gvfs devs try to hide this behind a nebulous mist where no one would think about GVFS as the trouble maker, cause any other trail which could lead to it is in a non functional state. I am sure that is not the case and hopefully just a unlucky coincidence. Aehem.
Also I have to mention: Uninstalling GVFS per package kit GUI means also bye bye to Nautilus and the Mozilla Totem Plugins. Why that? I mean, the functionality of Nautilus is somewhat limited in an up to date Gnome Env without GVFS - but non functional? Sounds like Windows and MSIE. No reason to deinstall it imho. This is absolutely the case for the totem mozilla plugins. What has a multimedia player in a browser ever to deal with gvfs? Uninstalled automatically... I call that way bad packaging.
Last thing. If gvfs is installed (as it is automatically in newer GNOMEs), why the heck has it to be activated when I start KDE? To put it in a fictional claim which of course is beyond reality but somewhat in the air (i.e. for the guys of the computer rainbow press): Why are gnome apps cowardly trying to shoot my KDE in the back?
Well - umm - very last thing: There is the chance, that my SE Linux Actions (especially "seedit policy" which creates a completely new feature set, including renaming the original ini file in /etc/selinux, but also switching selinux completely off ["disabled"]) are the source of the faulty GVFS. This is something someone should check out. But not me - for me this day was rotten and I am glad my shiny KDE is doing it again...
Thank you for the detailed feedback (and stories about the end of the world). This is the same issue as reported in bug 493565 and bug 503956. I'm going to close this one, feel free to add any of your comments to the bug 493565.
This is caused by gvfs-fuse-daemon, resp. the active fuse mount in ~/.gvfs. Quick workaround can be either killing gvfs-fuse-daemon or removing the gvfs-fuse package.
In fact, this looks like a deadlock somewhere between kernel and fuse. We're not facing this issue here, any clues leading to proper reproducer would be appreciated. One hint you could try is to run different kernel.
One more thing: what does `gvfs-mount -l` say to you? (should be empty list unless you use some Gnome app).
(In reply to comment #3)
> Also I have to mention: Uninstalling GVFS per package kit GUI means also bye
> bye to Nautilus and the Mozilla Totem Plugins. Why that? I mean, the
> functionality of Nautilus is somewhat limited in an up to date Gnome Env
> without GVFS - but non functional? Sounds like Windows and MSIE. No reason to
> deinstall it imho. This is absolutely the case for the totem mozilla plugins.
> What has a multimedia player in a browser ever to deal with gvfs? Uninstalled
> automatically... I call that way bad packaging.
GVFS is not a hard link-time dependency, you would only strip the VFS functionality completely and end up with local-only access. Nautilus would work that way (though it would not do any mount operations) but Totem and other apps are using various gvfs backend to access resources on the internet (e.g. http media streaming). This is why we made gvfs a hard dependency.
The gvfs-fuse package is optional, only extending functionality to non-GIO applications, not affecting the GIO/GVFS system at all. It's been pulled in during Fedora installation (comps) and can be removed. Dependency hell is unfortunate, it's a common issue in Fedora.
> Last thing. If gvfs is installed (as it is automatically in newer GNOMEs), why
> the heck has it to be activated when I start KDE?
This is more a question for the KDE team. AFAIK there's a KIO slave bridging GIO (resp. GVFS) to KDE. You may also have several common services running, like NetworkManager applet or Totem mentioned.
> Well - umm - very last thing: There is the chance, that my SE Linux Actions
> (especially "seedit policy" which creates a completely new feature set,
> including renaming the original ini file in /etc/selinux, but also switching
> selinux completely off ["disabled"]) are the source of the faulty GVFS.
Switching SELinux off surely shouldn't cause these problems.
*** This bug has been marked as a duplicate of bug 493565 ***
Thanks lots of Tomáš, taking your time for this very detailed answer.
Unbelievable in fact that you've answered this, considering this bug is a duplicate.
In fact I was going to write something here right now, because today it occurred to me that I run in exactly the same problems when using sshfs. So I was about to point my fingers to fuse - and to apologize to the GVFS packagers... Was not that nice, what I had to tell about gvfs - especially when facing the fact, that fuse is the faulty thing here (which of course I did not realise yesterday...)
So take my apologies and I am happy to read (or even comment if necessary) further in 493565.
Thanks Tomáš and regards,