NFS client can't mount exported drive

Latest response

Running on RHEL7.
Common problem when mounting from client:

-bash-4.2# mount -a
mount.nfs4: Connection timed out

Server shows this:

-A INPUT -p udp -m state --state NEW -m udp --dport 20048 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 20048 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 2049 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2049 -j ACCEPT

Plus a number of other NFS-related ports. If I stop the firewall the mount completes. A tcpdump on the client shows '172.19.93.15.890 > 172.19.93.16.nfs', which I am guessing = port 2049. Suggestions?

Responses

Add the following rule to IPTables and check /var/log/messages for any drops, this will quickly tell you what you are missing in your firewall without installing any additional tools (make sure you don't have any rules such as a default drop before this rule, change IP ad required). iptables -A INPUT -s 172.19.93.15.890 -j LOG --log-prefix "DROPPED:"

The 'nfs' in tcpdump is resolved from the file /etc/services

To show numeric values rather than resolving port/service names, you can pass '-n' to your tcpdump command.

That seemed easy enough, but: iptables v1.4.21: unknown option "--log-prefix"

And sure enough, the man page does not list that as an option. So I tried this sequence: -bash-4.2# iptables -N LOGGING -bash-4.2# iptables -A INPUT -j LOGGING -bash-4.2# iptables -A INPUT -s 172.19.93.0/24 -j LOG -bash-4.2# iptables -A LOGGING -j DROP ...

Updated the order and restarted to see:

... ACCEPT icmp -- anywhere anywhere icmp echo-request state NEW,RELATED,ESTABLISHED LOGGING all -- anywhere anywhere LOG all -- 172.19.93.0/24 anywhere LOG level warning DROP all -- anywhere anywhere Chain FORWARD (policy DROP)

... The mount still hung, of course, but no messages were generated in /var/log/messages.

That seemed easy enough, but: iptables v1.4.21: unknown option "--log-prefix"

The reason for this error was that I wrote the command from memory, the '-j log' should have been '-j LOG'. The man page does list --log-prefix as an option if 'LOG' is the target (I have updated my post to fix this).

--log-prefix prefix Prefix log messages with the specified prefix; up to 29 letters long, and useful for distinguishing messages in the logs.

The rules should look like:
-A INPUT -p udp -m state --state NEW -m udp --dport 20048 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 20048 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 2049 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2049 -j ACCEPT
-A INPUT -j LOG --log-prefix "DROPPED:"

If you are doing this on the server and not seeing any drops, it may be the client that is dropping packets. I would configure the logging rule on the INPUT of both ends (client and server). It may also be a device between the client/server (depending on network configuration) that is dropping the traffic.

I also recommend reading the following
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/nfs-serverconfig

Especially "8.7.3. Running NFS Behind a Firewall".

Note: if running NFSv4.1, you should only need 2049/tcp and 111/tcp to mount remote shares. If using NFSv4.0, you'll still have some other ports to account for

Got dinged on a TrustedAdvisor scan (AWS), earlier this week, because my security group rules were too broad. Pared it down (from my prior point-to-point "any" configuration) to those two ports/protocols and NFS mounts still worked.

NFS has gotten so much easier to run within port-restricted deployment-contexts.

Also, since you're using RHEL7, firewalld has several pre-defined services for setting up the requisite port-exceptions. Generally recommended to use those named services (nfs and rpc-bind) than bare port/proto config-options or direct rules.

Resolved by adding this to the server: -A OUTPUT -m tcp -p tcp --sport 2049 -j ACCEPT

I found in the tcpdump traffic going back to the client from this port. I've not seen this specific rule noted by anyone, so does that imply some other subtle configuration problem that now requires this non-standard solution?

Weird. Firewalld doesn't typically block the OUTPUT chain (so as to require OUTPUT exceptions).

I'm no expert, but it seemed odd to me too. No matter, I have a solution, I've stopped diving down the rabbit hole.

Thanks for everyone's suggestions.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.