Bug 503956

Summary: ls -la and nautilus hang browsing home directory when read .gvfs directory
Product: [Fedora] Fedora Reporter: Rivaldo Lira <riva>
Component: gvfsAssignee: Tomáš Bžatek <tbzatek>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: acidphlux, alexl, amlau, ataylor, b.bellec, dr.trigon, heyoka, jbacik, kost-bebix, okrh, paul, phil.ingram, tait.clarridge, tbzatek, tsmetana, vpvainio
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 533186 (view as bug list) Environment:
Last Closed: 2009-11-20 16:27:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 493565, 577927    
Bug Blocks:    
Attachments:
Description Flags
lsstrace of the ls -la none

Description Rivaldo Lira 2009-06-03 14:43:48 UTC
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:

Comment 1 Rivaldo Lira 2009-06-03 14:47:19 UTC
Created attachment 346403 [details]
lsstrace of the ls -la

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

Comment 2 Tomáš Bžatek 2009-06-03 14:52:48 UTC
Looks like the same issue as in the bug 493565

The process to kill is gvfs-fuse-daemon

Can you test different kernels?

Comment 3 Rivaldo Lira 2009-06-03 17:13:56 UTC
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

Comment 4 Benjamin Bellec 2009-06-11 19:11:42 UTC
Same problem with nautilus & home directory, F11 x86_64.

Comment 5 Tomáš Bžatek 2009-06-12 08:55:27 UTC
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).

Comment 6 Joost Ruijsch 2009-06-19 20:11:48 UTC
Got same problem on i386. 
This happened because I disabled the netfs service. Re-enabling this service fixed the problem.

Comment 7 Tomáš Bžatek 2009-06-23 09:12:25 UTC
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?

Comment 8 Rivaldo Lira 2009-06-26 00:19:26 UTC
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.

Comment 9 Alan Taylor 2009-08-17 02:06:29 UTC
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

Comment 10 Tomáš Bžatek 2009-08-17 08:09:29 UTC
(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.

Comment 11 Rivaldo Lira 2009-08-17 12:04:20 UTC
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?

Comment 12 Alan Taylor 2009-08-18 23:26:26 UTC
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

Comment 13 Alan Taylor 2009-08-19 00:17:15 UTC
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

Comment 14 John Freed 2009-08-26 01:13:46 UTC
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.

Comment 15 Phil 2009-08-28 05:55:36 UTC
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.

Comment 16 Jesus Tobajas 2009-08-30 02:03:28 UTC
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.

Comment 17 John Freed 2009-08-30 12:59:48 UTC
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.

Comment 18 Tomáš Bžatek 2009-09-01 08:13:28 UTC
Please see bug 493565#c44 for a possible workaround. This bug is still blocked by the latter one.

Comment 19 John Freed 2009-09-01 15:04:44 UTC
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.

Comment 20 Alan Clements 2009-09-09 01:11:20 UTC
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.

Comment 21 Tait Clarridge 2009-09-10 14:10:38 UTC
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

Comment 22 John Freed 2009-09-12 09:54:04 UTC
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

Comment 23 dr.trigon 2009-09-21 17:53:33 UTC
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.

Comment 24 Petr Bohac 2009-10-08 19:40:18 UTC
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).

Comment 25 Petr Bohac 2009-10-08 23:50:20 UTC
Taking back. Next reboot breaks it again

Comment 26 dr.trigon 2009-10-14 19:30:40 UTC
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 27 Ville-Pekka Vainio 2009-11-20 14:48:33 UTC
I'm still seeing this on F12. Any ideas on fixes?

Comment 28 Josef Bacik 2009-11-20 16:27:42 UTC

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

Comment 29 dr.trigon 2010-04-11 16:35:27 UTC
Same to me! Will there be a bugfix for F13?