Setting Up a Network Share – Part I: NFS

Article summary

Recently, Mike English and I needed to set up a rather simple network share which could be used for storing and sharing documents, image artifacts, and large binary files. This was to replace our previous network share solution which I inadvertently rendered unusable after a system software upgrade. We intended the network share to be fully accessible to everyone on our internal LAN, without the need to authenticate.

Our operating system of choice was Ubuntu 10.04 LTS. The plan was to use NFS to allow clients to retrieve and place files. After some progress, however, it became clear that NFS alone wouldn’t fulfill our needs. Most clients to the network share were Mac boxes (which historically haven’t played nice with NFS), and a few Windows boxes (which do not come with a built-in NFS client).

It became clear that three major protocols would be needed: NFS, AFP, and Samba. In addition, we decided to add FTP to allow read-only file transfers, and avahi to publish the availability of these services. The necessary setup and configuration of the software packages to create a network share with these protocols was somewhat complex, and fraught with pitfalls thanks to our client platforms, the host operating system which we chose, and the intricacies of the protocols themselves (NFS particularly so).

I plan to describe the setup and configuration of our network share with NFS, AFP, Samba, and FTP over the next few blog posts.

Part I: NFS

NFS is a particularly complex thing to get running properly. Most of the complexity comes from the various software packages (portmap, statd, lockd, rpc, etc.) which must be running and properly configured in order for NFS to operate.

Getting NFS installed on Ubuntu isn’t difficult:

apt-get install nfs-kernel-server

Initial setup and configuration also isn’t so difficult:

sudo mkdir -p /nfs

/nfs *(rw,async,no_subtree_check)

However, this setup presumes that a client has an existing Unix user account on the system with appropriate privileges (NFS utilizes Unix style user and file permissions).

In order to allow other clients without appropriate user accounts to use the share, we need to add “all_squash” so that all requests from clients are mapped to the anonymous user and group (nobody and nogroup on Ubuntu systems). Mac clients initiate connections from high numbered ports (greater than 1024), so we need to add the “insecure” option:

/nfs *(rw,async,no_subtree_check,all_squash,insecure)

Since all requests will now be using the anonymous user and group, it doesn’t hurt to set permissions on the directory appropriately:

sudo chown nobody:nogroup /nfs

For most systems, this should be enough. However, there are a multitude of snags which can prevent the NFS share from operating as expected. Most are related to the RPC daemons which NFS relies on to operate.

For example, in our case, we encountered a problem with statd, the NSM (Network Status Monitor) RPC protocol daemon. It was not started automatically with the system, and NFS requires it to operate properly. While our Mac clients would connect successfully, the connection would soon hang, with errors such as “server connections interrupted”. Error logs showed messages such as:


kernel: lockd: cannot monitor
kernel: statd: server rpc.statd not responding, timed out

Interestingly, NFS will not complain that statd is not running if it is not specified in the NFS configuration files (the default is unspecified).

Our solution was to explicitly specify that statd should be running in the NFS configuration files. This ensures that when NFS is started (or restarted) statd will also be:



Another common pitfall with NFS setups are firewall rules which block the ports used by portmap to open RPC connections for NFS.

The number of possible issues with NFS are many. However, log files and a good reference source, go a long way in solving those problems when they arise.

In the next blog post, I intend to cover our solution for AFP and Samba.