nfs error: No route to host when starting apache ...

Rick Macklem rmacklem at uoguelph.ca
Fri Apr 1 23:33:33 UTC 2011


> I just setup an nfs mount between two servers ...
> 
> ServerA, nfsd on 192.168.1.8
> ServerB, nfs client on 192.168.1.7
> 
> I have a jail, ServerC, running on 192.168.1.7 ... most operations
> appear
> to work, but it looks like 'special files' of a sort aren't working,
> for
> when I try and startup Apache, I get:
> 
> [Fri Apr 01 19:42:02 2011] [emerg] (65)No route to host: couldn't grab
> the
> accept mutex
> 
> When I try and do a 'newaliases', I get:
> 
> # newaliases
> postalias: fatal: lock /etc/aliases.db: No route to host
> 
> Yet, for instance, both MySQL and PostgreSQL are running without any
> issues ...
> 
> So, the mount is there, it is readable, it is working ... I can ssh
> into
> the jail, I can create files, etc ...
> 
> I do have rpc.lockd and rpc.statd running on both client / server
> sides
> ...
> 
Since rpc.lockd and rpc.statd expect to be able to do IP broadcast
(same goes for rpcbind), I suspect that might be a problem w.r.t.
jails, although I know nothing about how jails work?

> I'm not seeing anything in eithr the man page for mount_nfs *or* nfsd
> that
> might account / corect for something like this, but since I'm not sure
> what "this" is exactly, not sure exactl what I should be looking for
> :(
> 
> Note that this behaviour happens at the *physical* server level as
> well,
> having tested with using postalias to generate the same 'lock' issue
> above
> ...
> 
> Now, I do have mountd/nfsd started iwth the -h to bind them to
> 192.168.1.8
> ... *but*, the servers themselves, although on same switch do have
> different default gateways ... I'm not seeing anything within the man
> page
> for, say, rpc.statd/rpc.lockd that allows me to bind it to the
> 192.168.1.0/24 IP, so is it binding to my public IP instead of my
> private?
> So nfsd / mount_nfs can talk find, as they go thorugh 192.168.1.0/24
> as
> desired, but rpc.statd/rpc.lockd are the public IPs and not able to
> talk
> to each other?
> 
> Thx ...
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"


More information about the freebsd-questions mailing list