NFS – Is Rpcbind Needed for an NFS Client?

The root issue turned out to be a port mismatch for portmap/rpcbind. On CentOS 6 my rpcbind was listening on port 3421 instead of the expected 111 like portmap does in CentOS 5. This caused both the issue with starting nfs and the mounting of shares between the two machines.

The solution was to use itpables to redirect port 111 on CentOS 6 to port 3421:

iptables -t nat -I PREROUTING -p tcp --dport 111 -j REDIRECT --to-ports 3421
iptables -t nat -I PREROUTING -p udp --dport 111 -j REDIRECT --to-ports 3421
iptables -t nat -I OUTPUT -p tcp -o lo --dport 111 -j REDIRECT --to-ports 3421
iptables -t nat -I OUTPUT -p udb -o lo --dport 111 -j REDIRECT --to-ports 3421

The same thing was done on the CentOS 5 server except in reverse, redirecting port 3421 to 111. After this I was able to successfully mount the NFS share from the CentOS 5 server on the CentOS 6 client.

In order to get nfs completely working on the CentOS 6 server I also had to uncomment all the port related lines in /etc/sysconfig/nfs to use fixed port addresses. Before doing this I had intermittent issues with the lockd service not responding.

Based on the scenario described it is possible that there are multiple contributing factors. sync and async options can have a significant impact on performance, as can the nolock option when mounting the NFS.

Performance could also potentially be impacted by file-ownership and permissions issues related to ACLs for the files and/or use of the root_squash and no_root_squash options when mounting. Though if this were the case there would likely be evidence of it in logs somewhere.

There could also be issues moving files in and out of memory. Depending on the sequence of operations and amount of physical and virtual memory there could be a lot of thrash occurring as well.

If the traffic is ongoing and file operations are not cleaned up properly/hanging/taking excessive time to complete write-ops, the number of files currently open could start to push the limit supported by the kernel, this can be checked by running:

cat /proc/sys/fs/file-max

If that value is low on the NFS server or client it might be worth increasing it to see if performance improves. Depending on the network environment implementing certain QoS policies could potentially have an impact on performance(though probably not very likely).