Shouldn't nfsd be in there?
*shrug* Sure?! Why not? ;) Like I said, it worked previously, and I know I didn't mess with hosts.allow between the time it /was/ working and now, but I'll try it anyway...
Err, isn't hosts.allow the TCP wrappers config file? NFS usually runs over udp in a lan environment; I don't see how TCP wrappers could be involved.
For the host in question, I get back:
program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100003 2 udp 2049 nfs 100003 2 tcp 2049 nfs 100005 1 udp 630 mountd 100005 2 udp 630 mountd 100005 1 tcp 633 mountd 100005 2 tcp 633 mountd
Hmm, you should have entries for lockd and statd (I think) in there. The timeout could be from the client trying to contact lockd on the server, but I don't know if that happens at mount time.
It'd be helpful to to know exactly what rpc program/version the client is trying to invoke when it times out. Could you snoop the network during a mount attempt? If it's trying to talk to nfsd, then the question is why nfsd is ignoring the client. If the client is trying to talk to lockd, then the question is why lockd isn't running.
Before I go much further... is there any chance at all that this could be a kernel issue on mountING system? (The one trying to make the NFS connection to the mountED server)
Shrug, anything's possible. It'd be nice to know exactly what is failing before leaping for the kernel, though.
-- Kenneth Herron [EMAIL PROTECTED] 916-366-7338 _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
