the ports to open are 111, 2049, 4001, 4002, 4003, and 4004 both UDP and TCP.

it should then work

Thanks! I'm wondering if opening all those ports might not be overkill. I know 111 is necessary, and I'll check the others by closing them off to see what happens.

No problem

and then post the results of your finding so when enjoy the spoils, lol

FYI: Turning off iptables completely worked.

Adding rules to allow all the ports you specified didn't work.

Output of relevant part of iptables -L -n:

ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:111
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:111
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:2049
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:2049
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:4001
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:4001
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:4002
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:4002
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:4003
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:4003
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:4004
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:4004

Nailed it:

I was working on RHEL5.

After further research I found this page:
http://www.redhat.com/docs/manuals/e...onfig-nfs.html

It says:
Based on that I modified my /etc/sysconfig/nfs to have:
MOUNTD_PORT="4001"
STATD_PORT="4002"
LOCKD_TCPPORT="4003"
LOCKD_UDPPORT="4004"

I then ran "service nfs stop" and "service nfs start" to restart.

Verified with "rpcinfo -p" that it was using the expected ports.

The firewall rules I added to /etc/sysconfig/iptables were:
All the above I put BEFORE the final line which I left alone (this is default final rule - putting rules after it prevents them from working):
Once I had modified that I ran "service iptables restart" to make it load the modified rules.

After that the nfs mount on a remote host worked fine.

Note that the above work was all done on the server on which the filesystem was being exported/shared from and not the one that was doing the nfs mount.

Thanks for the thread - It hadn't occurred to me to check iptables until I stumbled across it.

One solution I found, without messing around with iptables is to mount using nfs4:

mount -t nfs4 server:/dir /mnt/point

Works every time.

2 members found this post helpful.

Interesting. It does seem NFSv4 doesn't require portmapper so I can see where that would work - so long as both hosts were capable of NFSv4. Here we have at least one host that isn't.

So, same problem. Firewall off: NFS mounts fine. Firewall on: NFS fails with "No route to host."

So, the problem is with firewall configuration, right? It's a reasonable conclusion. The tricks I thought of won't work from system-config-securitylevel. Go into /etc/sysconfig/iptables and enter the following ~above~ the final line:

The first two lines open up the port mapper.
The latter four open up all non-privileged ports as both source and destination ports.

This doesn't work, but it did change the behavior from "No route to host" to timing out. I think that's progress, but I'm not sure.

What I did notice was that just opening up the non-privileged destination ports wouldn't change the behavior (Still get "no route to host"). Opening the portmapper or the source ports gets me the timeouts.

Does that shake something loose for anyone?

Thanks!
dafydd

I don't know if you saw my last post or the one that followed it. In mine I show that this was resolved by setting the values for the ports in a (RedHat) config file.

You don't mention what distro you're on but I'm wondering how you know the ports you put in iptables are the right ones?

In the one after mine someone posted that specifying nfs version 4 avoided need to update iptables. I can't confirm that (though my follow up suggests that I likely tested it at the time).

By the way you might want to consider opening a new thread and linking back to this one. Most folks look at zero reply threads but only the people originally subscribed to this one are likely to see it.

I'm using RedHat 5.4.

nfs4 isn't working for me, for now. Exploring that more is today's project. As far as opening ports, all I did was open every non-privileged (1025-65535) port. That's only a security hole if I'm dumb enough to put a listener on a non-privileged port, or if someone tries a Man-in-the-Middle attack on a connection that was requested on a privileged port and moved to a non-privileged port. (Which is my recollection of how NFS operates.) In any case, while it changed the error message, it didn't work.

Regarding a new thread, I found this thread while searching on error messages. I don't know if a new thread would be better than letting the next guy with good Google-fu not trip over the mistakes I've made so far...

Thanks!
dafydd

If it is RHEL5.4 then what I wrote in an earlier post about /etc/sysconfig/nfs should apply. Have you tried doing that?

Also I don't really agree with you about the iptables setup. Sure its OK so long as YOU don't open a port but what if someone else does? Or what if you start a new software package that listens on a port to make internal socket connections but is now wide open to the outside because you didn't lock down all ports in the first place? Oracle for one is notorious for opening dozens of ports when it really only needs 1 or 2 available to connect from outside the box and all the rest are only for it to make socket connections. Ideally things like that would only listen on localhost (127.0.0.1) but in reality they listen on all interfaces not just loc.

I know this is an old thread, but I thought I'd make my contribution since the problem's still relevant and it's quite possible people will run into this thread looking for help with it (as I did yesterday---this was the first Google result for the query 'mount nfs "no route to host" '). Unfortunately the solutions given above range from bad (opening all higher ports) to downright awful (turning off the firewall). My solution is not perfect (I'm no expert, or else I wouldn't have been Googling it!) but it's better than the alternatives presented.

These instructions will apply to RHEL/Centos 5. Before giving them, I'll just say that everything here is explained in the RHEL 5 Deployment Guide and relevant man pages (the important one is iptables(8)). So if you're interested in actually learning about your system, skip this and do the research yourself: you will find the answer. Lazy people read on.

The problem is caused by the (Red Hat/Centos) NFS server's firewall preventing the connection (assuming you have configured NFS/networking/etc. correctly). Instead of switching off the firewall (never do this if your machine is networked!) you'll want to open the correct ports to the correct machines in order to let the legitimate NFS traffic through. NFSv3 (used in RHEL/Centos 5) uses portmap to dynamically allocate its ports; in order to open them in the firewall rulesets we therefore have to make the port selection static. You can do this by editing the relevant sections of /etc/sysconfig/nfs (as mentioned above by MensaWater).

Quoting from section 28.1.22 of the RHEL 5 Deployment Guide, in /etc/sysconfig/nfs:

These were the preselected port numbers in my /etc/sysconfig/nfs (on Centos 5.5):

LOCKD_TCPPORT=32803
LOCKD_UDPPORT=32769
MOUNTD_PORT=892
STATD_PORT=662


Assuming yours is the same, just uncomment the relevant lines (by deleting the # at the beginning) and save the file. (Naturally, you will need root privileges for this, and for everything following.)

Now you can restart the NFS service so that the changes take place:

The firewall is still blocking the ports, but now that we know what they are we can open them. Run

to get a listing of your filter table. If you have the default settings you'll see a chain called "RH-Firewall-1-INPUT" which takes care of all the packet filtering. To keep things tidy we'll add a new chain to the mix, put the rules in it and then link it into RH-Firewall-1-INPUT.

We add the new chain, called NFSCHECK (because it checks packets to see if they're NFS-related---get it?):

(You can run the list command again to verify that this and the following commands have worked.)

Now, here is where my advice differs materially from that given above. It is sensible to limit access to your NFS server to the hosts you want to be able to use it, and block others. Your situation may be different from mine, but I'm on a small network with the (internal) IP address 192.168.1.0/24 (that is, hosts have IPs in the range 192.168.1.1-254; "24" is the subnet mask specifier), so I will use the "-s" option to limit access to hosts on that network:

(If you make a mistake at any point you can empty NFSCHECK with the 'flush' command:

and start again.)

Taking the first command above, this tells iptables to append a new rule to the NFSCHECK chain (-A NFSCHECK) that will match packets with protocol TCP (-p tcp), source addresses on the given sub-network (-s 192.168.1.0/24), coming in (-d localhost) on the given ports (we use the "multiport" module here to specify several ports in one rule; -m multiport --dports ...), with an optional comment to remind you what it's for (-m comment...). Finally, we tell iptables to allow these packets through (-j ACCEPT). The second command is the same but for UDP, with one different port number.

The last rule we need on this chain is one to pass checking back to the RH-Firewall-1-INPUT chain:
The lack of options means "match anything". "-j RETURN" means go back to the next item in the list you came from. This is because the final move now is to link this chain into RH-Firewall-1-INPUT, so that it's checked in sequence.

Now, if you have the default RH-Firewall-1-INPUT ruleset for RHEL/Centos 5.5 it will have 10 rules: you can verify this (or count yours) by listing them with the --line-numbers option:

We're going to insert these NFS checks just before the end of the chain, to save every other networking packet (which probably isn't NFS-related) from having to go through them. (Note: I am not an expert, and this may be completely unnecessary. I do not know how much processing power such filtering requires. But it seems like a reasonable idea.)

This command tells iptables to insert the rule (-I) into RH-Firewall-1-INPUT at line 10 (if your line numbers differ, replace this with the number of the final line). The rule is simply "-j NFSCHECK"; that is, every packet getting this far down the chain will be sent to NFSCHECK for checking. Anything that doesn't match the NFS rules will be RETURNed back to this point in RH-Firewall-1-INPUT and go on to the next rule, which will just deny it.

Your NFS server should now work, assuming you have configured permissions correctly in /etc/exports. The advantage of setting it up the way I have shown is that your NFS ports are not open to the Big Bad Internet, only to your own machines. I'm sure there's still a security risk in here somewhere, but it's safer than the alternatives shared here so far.

If you found this interesting and want to learn more, read the iptables(8) man page and the RHEL 5 Deployment Guide.

3 members found this post helpful.

and you think you have solution with disabling iptables...no no my friend it not solution to disable selinux/iptables ....

This is the problem with resurrecting old threads. (This is the third coming for this one and we're still waiting on the second one for Jesus. )

The post you're chiding is around 2 years old. That poster may have since achieved Linux Zen (not xen) and know all there is to be known.

Not really wanting to wade through your post I will note that not all the solutions here were as you characterized them. If you look at post #20 you'll see something very similar to what you think you've newly come up with.
http://www.linuxquestions.org/questi...2/#post3233561

0 members found this post helpful.