How to Network Your Files With NFS
Last Updated: 09-01-2010 , Posted: 08-27-2008
The basic premise behind NFS is a simple client/server model. You share directories on the server, the client mounts them, and then it appears to the users on the client machine as just another file system.
Since Linux' NFS configuration options are quite similar to other Unix variants, we will be assuming a Linux client and server for this article.
First things first: We should begin by starting the necessary NFS services. On the server side, most distributions have a startup script designed to accomplish this. Running something like /etc/init.d/nfs start will fire up the NFS server properly on most distributions.
Using rpcinfo -p should return a bit of information about which RPC services are running. At a minimum, for NFS to function, you should see: portmap, status, mountd, nfs, and nlockmgr. Any missing items will require that you figure out why they are missing before proceeding. Note that these names are based on the most current nfs-utils package, currently nfs-utils-1.0.6-22. Your specific Linux distribution's documentation should provide more information about how to make sure everything is started at boot time.
Now on to the fun part: sharing directories. The file /etc/exports is used to specify which file systems should be exported to which clients. This is basically a listing of: "directory machine1(options) machine2(options)."
Examples should make it clear:
- To share /usr read-only to two IP addresses:
/usr 192.168.0.1(ro) 192.168.0.2(ro)
- To share /usr/local read-write to one machine, and read-only to everyone else:
/usr/local 192.168.0.5(rw) *(ro)
There are many ways to share directories, and many configurable options. Client lists can be netgroups, IP addresses, a single host, wildcards, or IP networks. Refer to "man exports" for more exhaustive details. The server also needs to be told to reread the configuration when it changes. This can be accomplished by sending -HUP to the nfs daemon, or by running exportfs -ra.
If everything was done properly, this server should be ready to serve NFS. The command showmount -e will list the exported file systems. If an RPC error was returned, that generally means a necessary service is not running.
Most current Linux distributions will support NFS mounting out of the box. To check for kernel support, run grep nfs /proc/filesystems. If enabled, a few lines mentioning NFS will be present. If not, you'll need to get a different kernel with built-in NFS support, or compile the module. Running insmod nfs should load the module if it happens to be present already. On the client side, NFS requires a few RPC services before you can successfully mount a remote file system. Portmap, lockd, and statd all need to be running, and should be visible in the output of rpcinfo -p.
You can manually mount an NFS file system as root in the same manner as you would mount a local file system or CDROM. For testing, I created a directory called /mnt/remote. Then ran mount 192.168.0.100:/usr /mnt/remote, where 192.168.0.100 is the NFS server's IP address. It should silently return to your prompt. ls /mnt/remote will now reflect the contents of the server's /usr directory.
It's really that simple. The most frequent cause of NFS (clients or servers) not working is because the appropriate services are not running. Knowing how to check for them (rpcinfo -p) makes troubleshooting NFS a breeze. Once the file system is mounted, the mount command will show you that /mnt/remote is mounted from the server, and it will also display the mount options.
Mounting many different directories manually is no fun, and you can't do it as a normal user. On the bright side, NFS file systems can be added to /etc/fstab just like any other file system. An example of our above mount in /etc/fstab looks like: 192.168.0.100:/usr /mnt/remote nfs ro 0 0
A few options worth mentioning here are hard, soft and intr. Mounting "hard" or "soft" has to do with how NFS will deal with the server disappearing suddenly because of a crash or network outage. Soft mounting is dangerous. If a read or write operation fails, the NFS client will report and error to the process that was executing the read or write. Most programs won't handle this properly, so it is best to simply use the hard mount option.
Hard mounting means that (just like when a disk fails) the process will hang waiting on i/o if a read or write doesn't process immediately. When the server comes back up, the process will continue normally. This method guarantees data integrity, but can be a bit annoying. Processes will become hung and non-killable unless you also specify the "intr" option, meaning interruptible. Using these recommended options, the fstab entry above will now have "ro,hard,intr" in the options field.
That about covers the basics of NFS. There are many uses for NFS aside from the occasional mounting of directories to copy files.
In an organization with multiple UNIX computers where users login to them all, it may be beneficial to move the user's home directories onto one file server. You can simply export /home, and then tell all the clients to get /home from the server, and the home directories will be the same no matter which machine users are logged in to. There are other ways to accomplish this as well, such as using autofs.
Article courtesy of EnterpriseNetworkingPlanet.com.
|Key Terms To Understanding NFS
Related Articles on EnterpriseNetworkingPlanet: