On Tue, Aug 03, 2010 at 11:55:24PM +0200, Michael Guntsche wrote: > On 03 Aug 10 17:36, J. Bruce Fields wrote: > > > Aug 3 23:12:23 gibson kernel: RPC: AUTH_GSS upcall timed out. > > > Aug 3 23:12:23 gibson kernel: Please check user daemon is running. > > > > > > Of course all the daemons on the server are running and the system seems > > > to work fine otherwise. > > > > That's actually a client-side complaint--if you're seeing it on the > > server then it's probably the server trying to do a callback to an NFSv4 > > client. Are you running rpc.gssd as well as rpc.svcgssd on the server? > > Might want to if you want delegations to work (but it's not a critical > > problem). > Yes, rpc.gssd as well as rpc.svcgssd is running on the server. To make > matters worse I noticed something else with sec=krb5. This messages > appears on first access to a file either read or write. Not always, it > seems that it reappears after some timeout but it is sparmming my logs > nevertheless. But what's worse is that I now got a Stale NFS file handle > on the lost+found directory of the export. A lot of question marks and > then just the name. I am now running with sec=sys and cannot up to now > was not able to reproduce this problem. Is it possible that does two > problems are related or are they completely separate from each other? I doubt they're related. Is there something special about the lost+found directory that would lead to stale filehandles? I can't think why there would be. --b. > FYI the patched nfs-utils version is only running on the server for now > but I do not think that this is the problem. -- 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
