Bug 506539 - homedirs blocked from ls -a after graphical login (kdm and gdm), because of faulty gvfs
homedirs blocked from ls -a after graphical login (kdm and gdm), because of f...
Status: CLOSED DUPLICATE of bug 493565
Product: Fedora
Classification: Fedora
Component: gvfs (Show other bugs)
11
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Enrico Scholz
Fedora Extras Quality Assurance
:
Depends On: 493565 577927
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-17 13:01 EDT by Herr Irrtum
Modified: 2010-03-29 14:45 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-18 09:48:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot of Dolphin, Nautilus and ls failing all togehter showing $HOME (81.75 KB, image/jpeg)
2009-06-17 13:01 EDT, Herr Irrtum
no flags Details
an strace of ls -a stopping directly at the file .gvfs (16.68 KB, text/plain)
2009-06-17 13:57 EDT, Herr Irrtum
no flags Details

  None (edit)
Description Herr Irrtum 2009-06-17 13:01:02 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:

>su -
>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:
<http://forums.fedoraforum.org/showthread.php?p=1228444&posted=1#post1228444>

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

How reproducible:
-----------------
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])
- smc
- ufo-ai
- itris
(yes, I was bored :) ; meanwhile I deinstalled all 3 of them, but the in parts 32 bit libs remained unfortunatelly) 


  
Actual results:
---------------

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

Expected results:
-----------------

a system where I can peacefully say "ls -lA" at $HOME - even as a root in some users home

Additional info:
----------------
Just one question: Why is all this happen to me and not one of the dev-guys?!
Comment 1 Herr Irrtum 2009-06-17 13:57:51 EDT
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)
Comment 2 Herr Irrtum 2009-06-17 14:00:00 EDT
I did forget to strace ls -la . Sorry. Now this is done and showing that the file .gvfs is causing the trouble.
Comment 3 Herr Irrtum 2009-06-17 15:53:06 EDT
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...

Regards.
Herr Irrtum
Comment 4 Tomáš Bžatek 2009-06-18 09:48:59 EDT
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 ***
Comment 5 Herr Irrtum 2009-06-18 13:02:37 EDT
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,
Herr Irrtum

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