GNOME Bugzilla – Bug 525779
try to access a .Trash-$USER directory on autofs mounts
Last modified: 2008-08-02 19:45:18 UTC
The bug has been described on https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/210468 "==> syslog <== Apr 1 14:50:15 guapuraT61 kernel: [18916.265351] SELinux: initialized (dev autofs, type autofs), uses genfs_contexts Apr 1 14:50:16 guapuraT61 automount[10582]: >> /sbin/showmount: can't get address for .Trash Apr 1 14:50:16 guapuraT61 automount[10582]: lookup(program): lookup for .Trash failed Apr 1 14:50:16 guapuraT61 automount[10582]: failed to mount /net/.Trash Apr 1 14:50:16 guapuraT61 automount[10589]: >> /sbin/showmount: can't get address for .Trash-500 Apr 1 14:50:16 guapuraT61 automount[10589]: lookup(program): lookup for .Trash-500 failed Apr 1 14:50:16 guapuraT61 automount[10589]: failed to mount /net/.Trash-500 Apr 1 14:50:16 guapuraT61 automount[10597]: >> /sbin/showmount: can't get address for .Trash Apr 1 14:50:16 guapuraT61 automount[10597]: lookup(program): lookup for .Trash failed Apr 1 14:50:16 guapuraT61 automount[10597]: failed to mount /net/.Trash Apr 1 14:50:16 guapuraT61 automount[10603]: >> /sbin/showmount: can't get address for .Trash-500 Apr 1 14:50:16 guapuraT61 automount[10603]: lookup(program): lookup for .Trash-500 failed Apr 1 14:50:16 guapuraT61 automount[10603]: failed to mount /net/.Trash-500 Nautilus attempts to mount and access a .Trash-$USER directory under the autofs mount "/net" and consequently fails and reports a bunch of errors to /var/log/syslog. There should be an ignore statement somewhere so that nautilus will ignore/not create the .Trash-$USER directory on read-only directories such as nfs shares that have been exported read-only and consequently *not* attempt to use the directory."
This bug is bumming me out, and no one seems to care about it :-/. I've been seeing a problem where my system starts behaving strangely after a day or two (FireFox downloads hang and never complete and I have to kill FF; I can't access some of my NFS mounted partitions; etc.) The one thing all these have in common is that when it happens I noticed 25-30 instances of gvfsd-trash running, where normally there's just one. Of course it could well be the other way around: the NFS hangs first and that causes all the gvfsd-trash processes to hang, which in turn causes the "root" gvfsd-trash process to fork another one, etc. I can't prove it either way, so I decided to fix gvfsd-trash so it doesn't have this message any more. As I mentioned in the Launchpad bug, I consider this just a workaround: the final solution should be to create a gconf variable (for example) that contains a list of filesystem types that should be ignored--autofs should be on there by default of course. However, that's stuff I'm really unfamiliar with so maybe this simple patch will work for the short term (to be honest I'm not sure what else I'd add to the list...) If I still get the odd behavior at least I'll know it's NFS, not gvfsd-trash.
Created attachment 113130 [details] [review] Ignore any partition with a file system type of "autofs".
*** Bug 541764 has been marked as a duplicate of this bug. ***
Created attachment 114092 [details] [review] patch from bug 541764 See bug #541764 for details.
*** Bug 519870 has been marked as a duplicate of this bug. ***
I committed that patch to gvfs trunk. Thanks for the patch. Sorry Paul that it took so long to get that in.