Thank you for your reply. I indeed had read your solution before posting (although not before working out my own) but decided mine was superior for the following reasons:

1) You add an unnecessary number of rules to the RH-Firewall-1-INPUT chain; I use a new chain (which is tidier, and allows it to be linked in and out as necessary) and specify multiple ports per rule, which, with the added comments, makes for better readability and possibly less effort.
2) Your use of "-m tcp -p tcp"/"-m udp -p udp" is confusing and unnecessary (the tcp/udp modules are loaded automatically when the protocol is specified, as you can read in the man page).
3) You do not specify source-based rules for access, so that your NFS/lockd/mountd/statd/portmap ports are now open to the world (assuming no other firewalls are in place beyond this one; they may be for you, but that is an unreasonable assumption to make when giving advice to others). When a vulnerability is found in one of these programs---which it will be---your server will be exposed; mine won't. This also helps to protect against easily-made mistakes in /etc/exports, such as leaving a space between the client address and the options, which has the effect of specifying those options for all clients rather than the one given (and therefore potentially allowing full access---and maybe even root mapping---to the world).

If you had read the whole post you might have realized this.

I hope you can see now that my post was carefully considered and not meant as a blanket denigration of previous efforts; indeed, I gave credit to you in it for describing /etc/sysconfig/nfs earlier on in the thread.

3 members found this post helpful.

There is also this:

http://iptables.rlworkman.net/iptables-tutorial.html
http://www.linuxguruz.com/iptables/

HTH.

Works for me. Disabled iptables.

Disabling iptables is NOT a solution because it opens your system up to all sorts of other things. Disabling iptables is certainly something to try to verify iptables is your issue but once you prove it is then you should try to determine specifically what needs to be opened in iptables rather than leaving it entirely disabled.

It is much like saying you solved your sudo problem by allowing root login without requiring a password. Sure you don't have to muck with sudo any longer but the consequences of allowing root to login without a password will be far worse than the problem you think you solved.

The thread that wouldn't die. This is the 4th time its come back and we're still waiting for Jesus' 2nd coming.

Try these :

firewall-cmd --permanent --add-service mountd
firewall-cmd --permanent --add-service rpc-bind
firewall-cmd --permanent --add-service nfs
firewall-cmd --reload

if it still shows no route to host then

iptables -F

iptables -L -n -V

on Ubuntu/Debain

sudo ufw allow from <your client IP> to any port nfs

sudo ufw enable
$ sudo ufw status

Then on the NFS server run

exportfs -r -v -a