On Mon, Jan 25, 2010 at 02:08:47PM -0500, Chuck Lever wrote: > On Jan 25, 2010, at 2:02 PM, Whoop Whouzer wrote: >> Ok, I did that, after shutting down the server and enabling debug >> trace I tried to open the home folder of the current account (totally >> unrelated to the nfsshare), it wouldn't open at all, I got no nautilus >> at all. During the time my cursor was in busy mode I got the following >> messages in kern.log (for ubuntu 10.04 client): >> Jan 25 19:30:13 whoop-desktop kernel: [ 160.719262] NFS call fsstat >> Jan 25 19:30:37 whoop-desktop kernel: [ 184.458611] NFS: >> permission(0:16/74386), mask=0x10, res=0 >> Jan 25 19:30:37 whoop-desktop kernel: [ 184.458647] NFS call access >> Jan 25 19:30:43 whoop-desktop kernel: [ 190.721086] nfs: server >> 192.168.1.130 not responding, timed out >> Jan 25 19:30:43 whoop-desktop kernel: [ 190.721113] NFS reply statfs: >> -5 >> Jan 25 19:30:43 whoop-desktop kernel: [ 190.721116] nfs_statfs: >> statfs error = 5 ... > This verifies that your client is attempting to access the NFS server, > but doesn't tell us which file it's attempting to access. Essentially > the EIO means "failed to connect". I wonder if nautilus (or some library it uses) likes to regularly "statfs" all the filesystems it knows about? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
