Bug 533186 - ls -la and nautilus hang browsing home directory when read .gvfs directory
Summary: ls -la and nautilus hang browsing home directory when read .gvfs directory
Keywords:
Status: CLOSED DUPLICATE of bug 493565
Alias: None
Product: Fedora
Classification: Fedora
Component: gvfs
Version: 12
Hardware: i686
OS: Linux
low
high
Target Milestone: ---
Assignee: Tomáš Bžatek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 533745 539853 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-05 14:39 UTC by BK
Modified: 2015-03-03 22:41 UTC (History)
23 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 503956
Environment:
Last Closed: 2010-01-25 15:07:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description BK 2009-11-05 14:39:35 UTC
Having this problem on F12 beta. Doesn't seem to occur on my F11 system(s). I tried killing gvfs-fuse-daemon, but no dice.

Tried killing all my processes and relogin, but after hanging for several minutes during login, I got a couple error messages loading applets, plus one saying 'Could not display "x-nautilus-desktop:///". Error: DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. ...'

...and no desktop started. Very sluggish response, selected "Shutdown..." and it took at least a minute before the prompt appeared.

After reboot, things work again. Can use system normally for a seemingly random amount of time, then bug strikes again. Anything trying to access home directory seems to lock up indefinitely.

Kernel: 2.6.31.5-96.f1.i686
gvfs-fuse: 1.4.1-.fc12.i686

+++ This bug was initially created as a clone of Bug #503956 +++

Description of problem:

After I log in, I try to open Nautilus in my home directory and Nautilus hangs or I open a Terminal and use ls -la in my home directory and the terminal hangs. Also, when I start programs like amsn for example, those programs start with default configuration. The ls command hangs if I use logged with root user or the non-privileged user. If I kill all the gvfs process all go back to normal. After doing some research I found out the commands hangs when they try to read the .gvfs directory located in my home directory.

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

gvfs-smb-1.2.3-2.fc11.x86_64
gvfs-obexftp-1.2.3-2.fc11.x86_64
gvfs-archive-1.2.3-2.fc11.x86_64
gvfs-fuse-1.2.3-2.fc11.x86_64
gvfs-1.2.3-2.fc11.x86_64
gvfs-gphoto2-1.2.3-2.fc11.x86_64

How reproducible:

Its happening every time I try to log on.

Steps to Reproduce:
1. Login in gnome
2. open the terminal in the user home directory
3. use ls -la
  
Actual results:


Expected results:


Additional info:

--- Additional comment from riva.br on 2009-06-03 10:47:19 EDT ---

Created an attachment (id=346403)
lsstrace of the ls -la

I got the lsstrace output during a ls -la test.

--- Additional comment from tbzatek on 2009-06-03 10:52:48 EDT ---

Looks like the same issue as in the bug 493565

The process to kill is gvfs-fuse-daemon

Can you test different kernels?

--- Additional comment from riva.br on 2009-06-03 13:13:56 EDT ---

Im currently running Kernel 2.6.29.4-167. I have tried Kernel versions 2.6.29.3-155.fc11.x86_64 and kernel-2.6.29.4-162.fc11.x86_64 and got the same problem

--- Additional comment from b.bellec on 2009-06-11 15:11:42 EDT ---

Same problem with nautilus & home directory, F11 x86_64.

--- Additional comment from tbzatek on 2009-06-12 04:55:27 EDT ---

Can you try older kernels, 2.6.28 or older? (any F10 kernel should do the job). e.g. http://koji.fedoraproject.org/koji/buildinfo?buildID=102955
There is very little difference between 2.6.29.4-167, 2.6.29.4-162 and 2.6.29.3-155

Another way would be to remove the gvfs-fuse package if you don't need it (though I don't recommend it).

--- Additional comment from joost on 2009-06-19 16:11:48 EDT ---

Got same problem on i386. 
This happened because I disabled the netfs service. Re-enabling this service fixed the problem.

--- Additional comment from tbzatek on 2009-06-23 05:12:25 EDT ---

Looking at the netfs initscript, it starts rpcbind besides the network services like NFS, SMB, NCP, GFS, whose shouldn't cause this issue. Can the other reporters please try starting/stopping the netfs service to see any difference?

--- Additional comment from riva.br on 2009-06-25 20:19:26 EDT ---

Hi,

I tried to stop and start the netfs service but i still got the same problem. The only work around thats working to me is killing the fusermount and gvfs-fuse-daemon processes everytime after I get logged in.

--- Additional comment from ataylor on 2009-08-16 22:06:29 EDT ---

Hello,

Fedora 11, x86_64. Same symptoms.
netfs service was not running but re-enabling it didn't help.
Killing the gvfs-fuse-daemon after boot didn't help.
Tried killing the fusermount process - didn't help.

The only thing that has worked for me was 
#yum remove gvfs-fuse
This also removed 5 dependencies, but no ill effects so far. It is interesting, I then tried
#yum install gvfs-fuse
and this only reinstalled gvfs-fuse, none of the dependencies that were removed. However, the problem came back.

So #yum remove gvfs-fuse works for me.

I would like to say that I think this is a high priority item. If I had not found a fix (I hope!!), I'd have installed another distro for now, as this bug basically makes my home directory unusable.

BRgds/Alan

--- Additional comment from tbzatek on 2009-08-17 04:09:29 EDT ---

(In reply to comment #9)
> Killing the gvfs-fuse-daemon after boot didn't help.
> Tried killing the fusermount process - didn't help.
These processes are started within desktop session, separate set for each one. The ones after boot may be spawned within gdm (not touching your home directory).

> This also removed 5 dependencies, but no ill effects so far. It is interesting,
What do you mean by 5 dependencies? Could you be more specific?

> I then tried
> #yum install gvfs-fuse
> and this only reinstalled gvfs-fuse, none of the dependencies that were
> removed. 
That's correct, the gvfs-fuse package doesn't have strict dependencies, other than fuse.

> However, the problem came back.
Have you tried different kernels? Different series, 2.6.28 - 2.6.30

> I would like to say that I think this is a high priority item. If I had not
> found a fix (I hope!!), I'd have installed another distro for now, as this bug
> basically makes my home directory unusable.
Might be interesting to try compiling your own vanilla kernel. If the problem persists, you will likely face the same issue with other distros. Still nobody came with proper reproducer.

--- Additional comment from riva.br on 2009-08-17 08:04:20 EDT ---

Hi,

I still have the problems. Recently I realized that the file .gvfs in my home directory is strange. As after kill the process Im able to browse the home directory, I found out that the .gvfs is showing the following information in the ls -la:

d??????????  ? ?    ?         ?            ? .gvfs

Im not able to chmod or delete the .gvfs.

Any tips about how to fix this problem?

--- Additional comment from ataylor on 2009-08-18 19:26:26 EDT ---

Tomas,

Re the dependencies you asked about, following is from yum.log (there are only 4 dependencies, not 5 as I said in my original post):

Aug 17 08:57:17 Erased: totem-nautilus
Aug 17 08:57:26 Erased: totem
Aug 17 08:57:31 Erased: gvfs-fuse
Aug 17 08:57:31 Erased: totem-mozplugin
Aug 17 08:57:31 Erased: totem-gstreamer


Rgds/Alan

--- Additional comment from ataylor on 2009-08-18 20:17:15 EDT ---

Tomas,

Re the dependencies you asked about, following is from yum.log (there are only 4 dependencies, not 5 as I said in my original post):

Aug 17 08:57:17 Erased: totem-nautilus
Aug 17 08:57:26 Erased: totem
Aug 17 08:57:31 Erased: gvfs-fuse
Aug 17 08:57:31 Erased: totem-mozplugin
Aug 17 08:57:31 Erased: totem-gstreamer


Rgds/Alan

--- Additional comment from okrh on 2009-08-25 21:13:46 EDT ---

Same problem here. I recently upgraded to FC 11 from FC 9 on an i586.

The problem originates when I log off GDM and then log in again. 

When I log off GDM, three gv-related processes are left behind:
 /usr/libexec//gvfs-fuse-daemon /home/guest/.gvfs
 fusermount -o rw,nosuid,nodev,subtype=gvfs-fuse-daemon -- /home/guest/.gvfs
 /bin/mount -i -f -t fuse.gvfs-fuse-daemon -o rw,nosuid,nodev,user=guest gvfs-fuse-daemon /home/guest/.gvfs

The first is owned by the user ('guest' in this case) and the second and third are owned by root.

When I try to log in again (as 'guest'), Nautilus starts up VERY slowly. If I let it finish, it generates two blank "Error" windows and nothing else -- no panel even; /var/log/messages says:
gnome-session[11333]: WARNING: Application 'gnome-panel.desktop' failed to register before timeout

If instead I kill the three processes, things return more or less to normal. Sometimes, however, I have two 'gvfsd' processes running at once, and in those cases (I think if and only if) Nautilus does not start in my desktop directory, but rather my home directory. Logging out and in fixes that problem.

This is reproducible with all non-privileged logins on my system.

I have always run netfs, so I don't think that's related.

When I do 'ls -la ~/.gvfs' after killing the various processes I get this:

ls: cannot access .gvfs: Transport endpoint is not connected

...which I suppose makes sense because fuserdaemon is stopped.

--- Additional comment from phil.ingram.net on 2009-08-28 01:55:36 EDT ---


same issue.

[pb@pimp ~]$ rpm -qa |grep gvfs
gvfs-archive-1.2.3-12.fc11.i586
gvfs-fuse-1.2.3-12.fc11.i586
gvfs-obexftp-1.2.3-12.fc11.i586
gvfs-gphoto2-1.2.3-12.fc11.i586
gvfs-1.2.3-12.fc11.i586
gvfs-smb-1.2.3-12.fc11.i586
[pb@pimp ~]$ uname -r
2.6.29.6-217.2.8.fc11.i686.PAE

This also caused issues with updatedb and yum update's testing transaction phase.  I had to do # kill -s 9 <pid> to get rid of all traces of gvfs-fuse before i could even see my home folder.  The weird thing was that using the bookmarked shortcuts in the left hand pane I was able to get in to some subdirectories but not others - eg ~/Download but not ~/Documents - both were accessed using the bookmark.

--- Additional comment from heyoka.org on 2009-08-29 22:03:28 EDT ---

I had this problem after unmount /home/$user/.gvfs, I restart my computer and had this problem.the solution was to create the group fuse and add my $user to group fuse.

--- Additional comment from okrh on 2009-08-30 08:59:48 EDT ---

That didn't help for me. There was already an empty fuse group, so I added myself and a bunch of other users, including root. Reinstalled gvfs-fuse, rebooted, no change in behavior (still hangs when trying to stat ~/.gvfs). So I removed gvfs-fuse again.

--- Additional comment from tbzatek on 2009-09-01 04:13:28 EDT ---

Please see bug 493565#c44 for a possible workaround. This bug is still blocked by the latter one.

--- Additional comment from okrh on 2009-09-01 11:04:44 EDT ---

Thanks for this. It led me to a solution that works on my machine, which I will post over there. Basically, I had disabled SELinux, and by setting it to Permissive, all was fine.

--- Additional comment from acidphlux on 2009-09-08 21:11:20 EDT ---

I've found that this corruption occurs after I reboot after an update. To fix it I have to reboot umount the /home partition and force an fsck. The problem is corrected by fsck quickly but still an annoyance.

--- Additional comment from tait.clarridge on 2009-09-10 10:10:38 EDT ---

I can confirm that my issues were resolved by running fsck.

Easiest way to run an fsck without going through the mess of unmounting and such, do the following AS ROOT:

touch /forcefsck
shutdown -r now

This will force an fsck on reboot and reboot your system. 

[10:06 AM] xxxx @ xxxx [~] $  uname -a

Linux xxxx 2.6.30.5-43.fc11.x86_64 #1 SMP Thu Aug 27 21:39:52 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

[10:06 AM] xxxx @ xxxx [~] $  rpm -qa | grep fuse

fuse-libs-2.7.4-3.fc11.x86_64
fuse-2.7.4-3.fc11.x86_64
gvfs-fuse-1.2.3-12.fc11.x86_64

[10:06 AM] xxxx @ xxxx [~] $  rpm -qa | grep gvfs

gvfs-smb-1.2.3-12.fc11.x86_64
gvfs-gphoto2-1.2.3-12.fc11.x86_64
gvfs-1.2.3-12.fc11.x86_64
gvfs-obexftp-1.2.3-12.fc11.x86_64
gvfs-archive-1.2.3-12.fc11.x86_64
gvfs-fuse-1.2.3-12.fc11.x86_64

--- Additional comment from okrh on 2009-09-12 05:54:04 EDT ---

Turns out SELinux wasn't the culprit, as the problem soon returned.

fsck did nothing to help my situation, which remains the same.

If I log in and kill the two root-owned processes (mount and fusermount), the system no longer hangs, and on subsequent login/logout there is no hang. However, I am still seeing this message:

ls: cannot access .gvfs: Transport endpoint is not connected

--- Additional comment from dr.trigon on 2009-09-21 13:53:33 EDT ---

I think I may have the same problem.

Some observations from here (they may help to sort this out):

1.) I think this bug also affects Adobe Reader 9 to freeze during startup
2.) Today I was connected to another lan (at the university) than usual (at home). This connection was made by wifi and fact is; during that connection my 'home' was listable (accessable by nautilus) and Adobe Reader worked. (Now at home again they refuse to work (again))

This is what I have to say at the moment, next time when I'm at the university I will try to reproduce this behaviour.

--- Additional comment from bohacpetr on 2009-10-08 15:40:18 EDT ---

I had same problem. Today I updated to udev.x86_64 141-7.fc11 fom updates-testing and it seams it helped, at least for now. After reboot no problematic processes running (fusermount and it's child proces mount).

--- Additional comment from bohacpetr on 2009-10-08 19:50:20 EDT ---

Taking back. Next reboot breaks it again

--- Additional comment from dr.trigon on 2009-10-14 15:30:40 EDT ---

NOT a solution, BUT a work-a-round was posted in fedora forum, look at http://forums.fedoraforum.org/showthread.php?t=229819 (linked from http://forums.fedoraforum.org/showthread.php?t=225871).
I did this:

 cp /usr/libexec/gvfs-fuse-daemon /usr/libexec/gvfs-fuse-daemon.bak
 echo > /usr/libexec/gvfs-fuse-daemon
 ls /usr/libexec/gvfs-fuse-daemon -la

and the size of my new "pached" file was 1 byte. This worked for me after reboot, BUT I have to say I'm NOT familiar with 'gvfs-fuse-daemon' and so I have no clue how this (somehow brute-force) solution affects the rest of the system/fedora install.

Comment 1 Tomáš Bžatek 2009-11-09 10:05:42 UTC
*** Bug 533745 has been marked as a duplicate of this bug. ***

Comment 2 Hicham HAOUARI 2009-11-10 17:42:52 UTC
"pkill -9 fusermount && pkill -9 mount " is the current workaround for me

Comment 3 Bug Zapper 2009-11-16 15:08:49 UTC
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

Comment 4 Andreas Osowski 2009-11-21 19:50:15 UTC
*** Bug 539853 has been marked as a duplicate of this bug. ***

Comment 5 xpumax.sl 2009-11-21 20:06:04 UTC
same bug here.

Fedora 12 i686 DVD-Install
kernel 2.6.31.5-127.fc12.i686.PAE

nautilus can't view home when the permissions of .gvfs are broken (as in Bug 539853 ).

When the permissions are broken this happens:

As user:
$ ls -l
          shows content of /home/$USER
$ ls -la
          hangs (Ctrl+c doesn't react. Must be killed)

As root:
$ ls -l
          shows content of /home/$USER
$ ls -la
         shows content of /home/$USER :
         ...
         d?????????  ? ?      ?          ?             ? .gvfs
         ...


After reboot, things work again. Can use system normally for a seemingly random
amount of time, then bug strikes again.

Comment 6 clive 2009-11-27 14:25:17 UTC
same bug here, fully updated F12 fresh install.

2.6.31.5-127.fc12.i686.PAE

Name       : nautilus
Arch       : i686
Version    : 2.28.1
Release    : 4.fc12

Comment 7 Albert 2009-12-07 20:00:13 UTC
same bug here, fully updated F12 fresh install.

I removed gvfs-fuse, which in turn removed totem and totem-nautilus.

Comment 8 Jacob Masaki 2010-01-23 17:27:27 UTC
There's a few workarounds on the forums, which involve disabling the gvfs-fuse module without uninstalling it.  

However, on my machine I disabled SELinux and the problems went away.

Comment 9 Jacob Masaki 2010-01-24 18:10:04 UTC
Okay, it looks like disabling SELinux didn't help long term (perhaps it was just the correct number of reboots).  

The workaround from the forums (which probably breaks something somewhere...) is:

#!/bin/sh
# place in /etc/X11/xinit/xinitrc.d/
# Needs to be named something like 00-gvfs-disable-fuse.sh so it gets loaded early.  

GVFS_DISABLE_FUSE=1
export GVFS_DISABLE_FUSE

Comment 10 Tomáš Bžatek 2010-01-25 15:07:36 UTC
(In reply to comment #9)
> The workaround from the forums (which probably breaks something somewhere...)
> is:
Uhm, please don't do such crazy workarounds, this is not the right way to fix this problem. You'd lose a lot of other functionality in your desktop.

See bug 493565 for details and possible solutions, particularly comments 44, 46, 67 and 68. Fixed F12 packages are being worked on, should be already fixed in rawhide. We just need to wait now, time to close it here.

*** This bug has been marked as a duplicate of bug 493565 ***


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