Every now and then I have issues with my NFS setup, server-side or client-side. And since I don’t usually handle NFS all that often, I always forget how to solve it and end up wasting a ton of time debugging and searching and stuff.
SO I finally, seconds before posting a long question on serverfault.com, managed to pin it down once again.
So, long story short:
– pretty much most of the problems regarding NFS come from firewall: server-side, client-side and/or router-side. So make sure to disable them all and see if that works. If it does, I’ll explain later how to make it work with your firewall enabled as well
– then, there are NFS server and NFS client configuration issues. There are plenty of how-tos out there for this
So how to troubleshoot a firewall/iptables issue? The most common flag for this problem is “connection timeout”. If you get it, it’s most likely a firewall/routing issue.
What I just did now, in my case, is to set up my firewall rules such a way that all drops are going to a special “mydrop” target, in which I drop everything.
Then, I have some scripts made which cancels, restores and enables logging in the firewall.
The logging script will cancel the firewall, then restore it (this cleans up stuff) then it adds logging like:
iptables -I mydrop -m limit --limit 2/sec -j LOG --log-prefix "IPTables-dropped: " --log-level 4 --log-tcp-options --log-ip-options
then, in another console, I do
tail -f /var/log/messages
and in the first one I start the mount/showmount/rpcinfo commands and check the tail log to see what packets are being dropped.
Then I make rules for those packets.
Now, in my personal case, I set up my NFS server to have static/dedicated ports (there are how-tos out there on how to do it, I won’t go over them here).
So, on a tight firewalled linux machine, the iptables rules for NFS client would look like this
# nfs client
-A services -s 192.168.1.4 -p tcp --sport 111 -j ACCEPT
-A services -s 192.168.1.4 -p tcp --sport 892 -j ACCEPT
-A services -s 192.168.1.4 -p tcp --sport 2049 -j ACCEPT
-A services -s 127.0.0.1 -d 127.0.0.1 -p udp --dport 111 -j ACCEPT
-A services -s 127.0.0.1 -d 127.0.0.1 -p udp --sport 111 -j ACCEPT
“services” in this context is a dedicated target for my used services (usually server/daemon stuff, but also client stuff when needed, like this scenario).
Note: 192.168.1.4 is my NFS server.
Then, on server side I have this
# nfs server
-A services -s 192.168.1.0/24 -m state --state NEW -p udp --dport 111 -j ACCEPT
-A services -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 111 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 32803 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 32769 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 892 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 892 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 875 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 875 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 662 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 662 -j ACCEPT
the rules with INPUT I have copied from another blog/site, which I can’t recall now. At the time I get these, I didn’t think about the logging idea I just wrote about, and I don’t want to kill all my machines to test it so I can figure out exactly what rules to put there.
Anyway, I hope this logging idea will help someone save some hours.
Related posts
