mount to NFS server 'julie' failed: No route to host

don fisher hdf3 at comcast.net
Thu Apr 12 21:32:02 UTC 2012


On 04/12/12 13:58, Rick Stevens wrote:
> On 04/12/2012 01:37 PM, don fisher wrote:
>> On 04/12/12 13:21, Greg Woods wrote:
>>> On Thu, 2012-04-12 at 11:33 -0700, don fisher wrote:
>>>> This one keeps coming back on F16:-( I can ssh to and from the host, so
>>>> part of the system knows it is there. I exported the file systems on
>>>> julie again to make sure that was set up. What can "No route to host"
>>>> mean?
>>>
>>> Sounds like a firewall problem. "julie" may be allowing ssh but not
>>> allowing NFS. Check the output of "iptables -L -v" on julie. There are
>>> probably rules that allow TCP port 22 and drop everything not explicitly
>>> allowed by default.
>>>
>>> NFS is a very hard protocol to write firewall rules for because it uses
>>> ports that vary. I generally don't use NFS in an environment where I
>>> need to have the firewall turned on.
>>>
>>> Easy test: on julie, run "systemctl stop iptables.service" and then see
>>> if you can NFS-mount files from it. (Don't forget to run "systemctl
>>> start iptables.service" afterwards when you are done to make sure you
>>> don't leave julie vulnerable, until you determine if the environment is
>>> safe to run without a firewall).
>>>
>>> --Greg
>> When I disabled iptables.service on julie I was able to mount it. I I
>> run system-config-firewall, nfs is enabled. What else do I need to
>> enable?
>>
>> The output from iptables -L -v is:
>> sudo iptables -L -v
>> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>> pkts bytes target prot opt in out source destination
>> 7 460 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
>> 0 0 ACCEPT icmp -- any any anywhere anywhere
>> 0 0 ACCEPT all -- lo any anywhere anywhere
>> 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:ftp
>> 0 0 ACCEPT udp -- any any anywhere 224.0.0.251 state NEW udp dpt:mdns
>> 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:nfs
>> 0 0 ACCEPT udp -- any any anywhere anywhere state NEW udp dpt:ipp
>> 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:ipp
>> 0 0 ACCEPT udp -- any any anywhere anywhere state NEW udp dpt:ipp
>> 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:ssh
>> 0 0 ACCEPT udp -- any any anywhere anywhere state NEW udp dpt:netbios-ns
>> 0 0 ACCEPT udp -- any any anywhere anywhere state NEW udp dpt:netbios-dgm
>> 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:netbios-ssn
>> 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp
>> dpt:microsoft-ds
>> 0 0 ACCEPT udp -- any any anywhere anywhere state NEW udp dpt:netbios-ns
>> 0 0 ACCEPT udp -- any any anywhere anywhere state NEW udp dpt:netbios-dgm
>> 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:https
>> 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:http
>> 0 0 REJECT all -- any any anywhere anywhere reject-with
>> icmp-host-prohibited
>>
>> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>> pkts bytes target prot opt in out source destination
>> 0 0 REJECT all -- any any anywhere anywhere reject-with
>> icmp-host-prohibited
>>
>> Chain OUTPUT (policy ACCEPT 4 packets, 368 bytes)
>> pkts bytes target prot opt in out source destination
>
> NFS uses a lot of ports via portmapper (portmap, rpc.statd, rpc.mountd),
> not just nfsd. You need to get julie to accept connections to those
> ports. The problem is that the ports vary from startup to startup
> (which is why portmapper is used).
>
> You can lock which ports each service uses by editing the
> /etc/sysconfig/nfs file and adjusting the values there. Once that's
> done, make sure julie has those ports allowed in its firewall and
> restart the nfs server.
>
> Alternately, if this is a private network, you could put in a firewall
> rule that allows all incoming connections on that private network.
In the old days, there were files /etc/hosts.allow and /etc/hosts.deny. 
As I recall, they had something to do with tcpd. Do they serve any 
purpose with ipchains?

Thanks,
don


More information about the users mailing list