On Jun 15, 2013, at 12:28 PM, John Haiducek <jhaiduce@xxxxxxxxx> wrote: > On 06/15/2013 10:27 AM, Chuck Lever wrote: >> On Jun 15, 2013, at 11:24 AM, John Haiducek<jhaiduce@xxxxxxxxx> wrote: >> >>> On 06/14/2013 02:13 PM, Chuck Lever wrote: >>>> On Jun 14, 2013, at 3:49 PM, John Haiducek<jhaiduce@xxxxxxxxx<mailto:jhaiduce@xxxxxxxxx>> wrote: >>>> >>>>> On Jun 14, 2013 11:05 AM, "Chuck Lever"<chuck.lever@xxxxxxxxxx<mailto:chuck.lever@xxxxxxxxxx>> wrote: >>>>>> >>>>>> On Jun 14, 2013, at 1:57 AM, John Haiducek<jhaiduce@xxxxxxxxx<mailto:jhaiduce@xxxxxxxxx>> wrote: >>>>>> >>>>>>> Jun 11 20:28:23 tbm rpc.gssd[8959]: Name or service not known while getting full hostname for 'tbm.enterprise.local' >>>>>> gssd thinks your client's hostname is "tbm.enterprise.local," which has no DNS entry. >>>>> That is the correct client hostname, and according to the 'host' command it is in dns. What would cause the host command to find it when gssd can't? >>>>> >>>> The error message is from utils/gssd/krb5_util.c:get_full_hostname(). If get_full_hostname() fails, then gssd can't search your client's keytab. >>>> >>>> Figure out why that getaddrinfo(3) call is failing to find a canonical name for "tbm.enterprise.local" -- that could be a client system configuration problem as much as a DNS misconfiguration. >>> Ok, I think I fixed the DNS problem. I was running avahi, and apparently you can't use avahi and also have a DNS server with a domain ending in .local. Shutting down avahi fixed it, although if I wanted to keep avahi working I could probably fix this by changing my domain to end in something other than .local. >>> >>> But now the mount command hangs and never returns. I get this in /var/log/syslog: >>> >>> Jun 15 09:19:36 tbm rpc.idmapd[16253]: New client: 24 >>> Jun 15 09:19:36 tbm rpc.gssd[16258]: dir_notify_handler: sig 37 si 0x7fffb0fb3330 data 0x7fffb0fb3200 >>> Jun 15 09:19:37 tbm rpc.gssd[16258]: dir_notify_handler: sig 37 si 0x7fffb0fb3330 data 0x7fffb0fb3200 >>> Jun 15 09:19:37 tbm rpc.gssd[16258]: dir_notify_handler: sig 37 si 0x7fffb0fb3330 data 0x7fffb0fb3200 >>> Jun 15 09:19:37 tbm rpc.gssd[16258]: destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt24 >>> Jun 15 09:19:37 tbm rpc.idmapd[16253]: Stale client: 24 >>> Jun 15 09:19:37 tbm rpc.idmapd[16253]: #011-> closed /var/lib/nfs/rpc_pipefs/nfs/clnt24/idmap >>> Jun 15 09:19:53 tbm rpc.gssd[16258]: dir_notify_handler: sig 37 si 0x7fffb0fb3330 data 0x7fffb0fb3200 >>> Jun 15 09:19:53 tbm rpc.idmapd[16253]: New client: 25 >>> >>> I might be missing something, but none of these entries look like errors. Where else should I look? >> You can boost the verbosity of the debugging messages from gssd. Start it with "-vv" or "-vvv". >> > > Already have it gssd running with -vvv. On the client, "sudo rpcdebug -m nfs -s all" And try the mount. Look in /var/log/messages for output. Did you tell us what kernel release you are running on client and server? "uname -a" -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
