On Mon, Nov 3, 2008 at 3:09 PM, Brian J. Murrell <brian@xxxxxxxxxxxxxxx> wrote: > On Mon, 2008-11-03 at 14:58 -0500, Kevin Coffman wrote: >> >> These are all from librpcsecgss (from the -rrr). I don't see an error here. > > Good. > >> You should have gotten output from gssd itself as well. You might >> also look for any errors on the server from rpc.svcgssd. > > Nothing. > >> This looks fine. (Assuming linux.interlinx.bc.ca is the NFS server >> and pc.interlinx.bc.ca is the client.) > > Indeed, they both are as you assume. > > So I've restarted both the rpc.svcgssd and rpc.gssd with -rrr -vvv on > the server and client (respectively) to see what more I can see but I > can't get the upcall to trigger. I would have thought simply issuing a > mount would do that, but it seems not. What exactly causes the upcall > to be made and what might prevent it from being made? There should definitely be corresponding debug output from rpc.gssd (-vvv) if you got those librpcsecgss (-rrr) messages. I would suggest that you leave off the -rrr for now as it appears to be extra clutter at this point. It might help if you run rpc.gssd in the foreground (-f) while debugging. Also, make sure this is the only rpc.gssd running. Re: the upcall. Any new mount using Kerberos should cause the upcall to create a new context with the server. Make sure the filesystem is not already mounted. After the mount, any new user accessing that mounted filesystem should cause an upcall to create a context for that user. K.C. -- 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
