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:
Created attachment 346403 [details] lsstrace of the ls -la I got the lsstrace output during a ls -la test.
Looks like the same issue as in the bug 493565 The process to kill is gvfs-fuse-daemon Can you test different kernels?
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
Same problem with nautilus & home directory, F11 x86_64.
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).
Got same problem on i386. This happened because I disabled the netfs service. Re-enabling this service fixed the problem.
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?
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.
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
(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.
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?
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
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.
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.
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.
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.
Please see bug 493565#c44 for a possible workaround. This bug is still blocked by the latter one.
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.
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.
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
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
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.
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).
Taking back. Next reboot breaks it again
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.
I'm still seeing this on F12. Any ideas on fixes?
*** This bug has been marked as a duplicate of bug 493565 ***
Same to me! Will there be a bugfix for F13?