ServerBuddies Support Blog

Using NFS over TCP

To mount a shared directory using NFS over TCP, use the “proto=tcp” mount option:

Make sure the target directory, in this example /usr/local/pub, exists on the client.

You can verify the NFS over TCP mount using the mount command:

If you need NFS, it is recommended to use NFS over TCP since NFS over UDP is not very secure. All 2.4 and 2.6 kernels support NFS over TCP on the client side. Server support for TCP appears in later 2.4 kernels, and in all 2.6 kernels.

To verify whether your server supports NFS over TCP, use the wire-test command (/usr/sbin/wire-test is part of the am-utils package). If your server supports NFS over TCP, the output looks like this:

Securing NFS

NFS (Network File System) allows servers to share files over a network. But like all network services using NFS involves risks.

If you don’t have shared directories to export, ensure that the NFS service is NOT enabled and running:

And then check using chkconfig

You probably don’t need the portmap service as well which is used by NFS (the portmap daemon registers rpc-based services for services like NFS, NIS, etc.):

Then check status using chkconfig

NFS should not be enabled if not needed.
If you must use NFS, use TCP wrapper to restrict remote access.
Make sure you export to only those machines that you really need to.
Use fully qualified domain names to diminish spoofing attempts.
Export only directories you need to export.
Export read-only wherever possible.
Use NFS over TCP.

Exporting NFS File Systems

To allow a client access to a filesystem or directory, the /etc/exports serves as the access control list.

To give the network “lan.serverbuddies.com” read-only access to /public_docs, the entries in /etc/exports would look like as follows:

Security : It is very important NOT to give write access to NFS clients if not absolutely needed! Entries in /etc/exports are exported read-only (”ro” option) by default.

To allow servers lan1, lan2 and lan3 read-write access to the /backup/setup directory, the entries in /etc/exports would look like as follows:

Note that options MUST NOT be separated from hostnames or networks with whitespace(s). And use fully qualified domain names to diminish spoofing attempts.

All entries in /etc/exports are exported with the root_squash option (’root squashing’) by default. This means that a root user on a client machine does not have root privileges (root access) to root-owned files on exported NFS filesystems/directories. It is not recommended to turn ‘root squashing” off using the no_root_squash option!

After you’ve made all your entries in /etc/exports, you can export all filesystems/directories using the following command:

To unexport all shared filesystems/directories, run:

To see all shared filesystems/directories, run:

Export list for localhost:

Why we should not use the no_root_squash Option

By default, NFS shares change the root user to the nfsnobody user, an unprivileged user account.

In this way, all root-created files are owned by nfsnobody, which prevents uploading of programs with the setuid bit set.

If no_root_squash is used, remote root users are able to change any file on the shared file system and leave trojaned applications for other users to inadvertently execute.

Common NFS Syntax Errors

The NFS server determines which file systems to export and which hosts to export these direct-
ories to via the /etc/exports file.

Be careful not to add extraneous spaces when editing this file.

For instance, the following line in the /etc/exports file shares the directory /tmp/nfs/ to the host serverbuddies.example.com with read/write permissions.

This line in the /etc/exports file, on the other hand, shares the same directory to the host serverbuddies.example.com with read-only permissions and shares it to the world with read/write permis-sions due to a single space character after the hostname.

It is good practice to check any configured NFS shares by using the showmount command to verify what is being shared: