exporting NFS shares from Linux to OS X with iptables

This seems to be a very popular subject to write about for those of us with the fix-it-and-forget-it mentality. But everything I dug up either contained outdated information or set up too unnecessary hoops (like this Redhat KB article for instance). So as my attempt to better the world today (and make a record for my own reference), here is a simple and robust way to export NFS shares from a Redhat/Fedora system with iptables enabled.

First thing to note is that by default, NFS uses a set of random ports to listen on when it starts up. Then the portmapper daemon is started so that any client who wishes to connect can ask the portmapper where the RPC and lockd and other components of the system are listening.

Of course, this is bad news if you are behind a firewall, as you undeniably should be (this system was designed, I think, in the salad days of the proto-internet on academic networks when one could open a service to the world and reasonably expect only kindness and benevolence in return). So first step is to get the RPC components to choose a port and stick to it.

RH made this simple enough – in /etc/sysconfig/nfs you will find lines already there binding these services to the standard IANA ports – but they are commented out. Simply un-comment all the following lines:

RQUOTAD_PORT=875
MOUNTD_PORT=892
STATD_PORT=662

(near the top of the file you may also choose to enable only the versions of NFS you need, in case you don’t have any ancient clients you can limit to the much faster v3 only)

Then make your additions to /etc/exports as you see fit. Here is mine, to share my favorite work directory to the local network:

/home/sbeam/public_html     192.168.1.0/16(rw,sync,no_subtree_check)

Then to punch the corresponding holes through the local firewall on the NFS server, simply edit /etc/sysconfig/iptables and add the following directly above the REJECT lines:

-A INPUT -m state --state NEW -m multiport -p tcp --dports 111,2049,662,892,875 -s 192.168.0.0/16 -j ACCEPT
-A INPUT -m state --state NEW -m multiport -p udp --dports 111,2049,662,892,875 -s 192.168.0.0/16 -j ACCEPT

This will still allow UDP connections, although again any modern client should be able to use the TCP version anyway.

And note the -s option which restricts clients to a certain IP range; edit this to suit your network.

Start or Restart both nfs, nfslock and iptables:

/etc/rc.d/init.d/nfs restart
/etc/rc.d/init.d/nfslock restart
/etc/rc.d/init.d/iptables restart

and then go to your client OS X machine, and mount the share from the command line, being sure to use mount_nfs’s -P option,

sudo mount -o -P server:/exported/path /local/path

Some NFS servers want to see NFS mounts from reserved ports, and -P does this (see man mount_nfs for more). (If you’re mounting through NetInfo, add an opts property with the value being -P)

Then…. it should work. Enjoy read-only access to your Linux-based files from your MacBook or whatever, and possibly read+write access if you can find a way (see “Sad Note” below)

So, despite what you may read elsewhere:

• No changes to /etc/services are needed because you are already using the ports defined there.
• No changes to /etc/modprobe.conf are needed, because the kernel already knows where to find the necessary modules, thanks anyway.

Sad note:
It is unfortunate that since we are connecting from an OS X client, which of course does not and can not share uid’s and gid’s with the Linux server system, there seems to be NO WAY to map the two together without using NIS, which is overkill for a SOHO environment. In fact, there used to be an option for /etc/exports called map_static, but that has not been supported since Redhat 6.2 or so (those were the days!) – but this is supported on SuSe and some other distros, so look at the exports(5) man page on your system.

So if you are not syncing /etc/passwd somehow between the systems then you will have to allow for simply having different users access different parts of the NFS share, or manually tweak UID’s and permissions as needed.

[credit to this posting that led down the correct road]