Cover V10, I12



NFS Part II, Usage

Ron McCarty

In Part I (Sys Admin, October 2001,, I covered NFS at a high level. This month I will cover the NFS protocol and daemons in more detail, including examples using Linux Red Hat 6.2 and Solaris 2.6.

NFS Penguin Style

Although the Linux coverage here is based upon Red Hat 6.2, the kernel version is 2.4.9. Red Hat 6.2 shipped with version 0.1.6 of the nfs-utils package, but the system was also upgraded to nfs-utils version 0.3.1, the latest available at the time the column was written. Version 0.3.1 is available at:
The nfs-utils contains the NFS executables exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount, and statd.

Unfortunately for Linux administrators, the NFS support has at times been downright confusing as support for particular features and versions have been added with different kernel and nfs-utils packages. Thankfully, things are getting better for Linux administrators. Current distributions include the latest kernel support and nfs-utils. For older production systems, the NFS-HOWTO section 2.4 documents exactly what is available with each combination, and the nfs-utils authors are keeping the package backward compatible with earlier versions but providing "...lots of security and bug fixes."

NFS support must be activated when the kernel is compiled. Additionally, NFS version 3 support must also be added to the kernel if it's needed.

For distributions supporting linuxconf, NFS services for both servers and clients are easily configured. Although linuxconf gives a quick way to set up NFS, what files are being created or edited are much more important for the administrator to understand when trouble arises and the NFS configuration needs to be analyzed. Linux NFS' architecture is loosely based upon the BSD version, so the support files and programs are easy to find for administrators that have used the BSD or Sun OS 2.5 or earlier NFS versions.

The /etc/exports file, like BSD's earlier version of /etc/exports/, defines what file systems are allowed to be accessed by NFS clients. Additionally, it provides extra management and security features that give necessary granular control for the administrator. The file is a text file made up on entries, blank lines, or comment lines that start with the pound (#) symbol.

Let's assume we would like to allow clients read-only access to the /home directory on Lefty. The following entry would be created in /etc/exports:

/home (ro)
At this point, we need to tell the system which directories can be exported and provided access by the mount daemon, rpc.mountd:

[root@lefty /root]# exportfs -r
exportfs: No host name given with /home (ro), suggest *(ro) to avoid warning
[root@lefty /root]#
When run, The exportfs command warns that the /etc/exports does not limit access to a particular host and creates the appropriate entry from the /etc/exports in the /var/lib/nfs/etab, which can be viewed with:

[root@lefty /root]# cat /var/lib/nfs/etab
/home   (ro,async,wdelay,hide,secure,root_squash,no_all_squash,subtree_check,sec
The other information listed in the etab includes the defaults used by NFS. The specifics will be covered shortly. To give access to the /home directory, the NFS-related daemons need to be started:

[root@lefty /root]# portmap
[root@lefty /root]# rpc.mountd
[root@lefty /root]# rpc.nfsd
[root@lefty /root]# rpc.statd
[root@lefty /root]# rpc.rquotad
At any point after starting the mount daemon (rpc.mountd), the specific files that are available for output can be viewed by looking at the /proc/fs/nfs/exports file:

[root@lefty nfs]# cat /proc/fs/nfs/exports
# Version 1.0
# Path Client(Flags) # IPs
/home,root_squash,async,wdelay) #
[root@lefty nfs]#
The showmount command with the -e parameter can be used to view the same information:

[root@lefty /root]# showmount -e
Export list for lefty:
/home (everyone)
[root@lefty /root]#
Although we are jumping ahead here, the showmount can also be used to determine which systems have mounted file systems, or stated otherwise, which hosts are NFS clients for the system where the showmount command is running. showmount -a will show all client mounts:

[root@lefty /root]# showmount -a
All mount points on lefty:
[root@lefty /root]#
As mentioned in Part I, most implementations of NFS support the various versions of NFS. The Linux implementation allows you to limit which versions of NFS to run by excluding specific versions using the -N with the mount daemon. For example, to only run NFS version 3, use:

[root@lefty /root]# rpc.mountd -N 1 -N 2
Purists may point out that the Linux version of the NFS daemon (rpc.nfsd) is listening for version 1 and 2 packets; however, the same effect is gained as if the protocol was not supported by the NFS daemon, albeit not as elegant as it should be. This will hopefully be corrected in a future version, with tighter integration of protocol versions throughout the package.

Swimming with Penguins

Accessing the exported NFS file systems from the Linux system "Lefty" configured above will depend on the client operating systems. Most UNIX-like operating systems will either use similar settings as the original Sun OS and BSD or the newer Solaris style. Because I am covering both Linux and Solaris in this article, the client configuration of Solaris 2.6 will now be covered with the intent of connecting to the Linux NFS covered above.

Due largely to its inheritance, configuring Solaris 2.6 to act as an NFS client is straightforward and requires only one command as root:

# mount -F nfs /tmp/tmp2
Assuming a successful mount, the mount command will have an entry for the mount:

# mount
/ on /dev/dsk/c0t0d0s0 read/write/setuid/largefiles on Mon Sep  3 10:17:56 \
/tmp/tmp2 on read/write/remote on Mon Sep  3 23:19:25 \
Let's examine the tcpdump output on Lefty after the user runs ls /tmp/tmp2 on Sunny:

[root@lefty rc2.d]# tcpdump host lefty and host sunny -s512
06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr   \
   fh Unknown/1 (DF)
06:07:43.490678 lefty.mcwrite.n.nfs > sunny.2191983953: reply ok 112   \
   getattr DIR 40755 ids 0/0 sz 0x000001000  (DF)
06:07:43.491397 sunny.2191983954 > lefty.mcwrite.n.nfs: 132 access   \
   fh Unknown/10001 (DF)
06:07:43.491463 lefty.mcwrite.n.nfs > sunny.2191983954: reply ok 120   
   access c0001 (DF)
06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.nfs: 152 readdirplus   \
   fh 0,1/16777984 1048 bytes @ 0x000000000 (DF)
06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: reply ok 1000   \
   readdirplus (DF)
We see that Sunny asks for a file handle (fh) for the ls command and Lefty replies with an OK and returns a directory structure. Sunny then checks permissions within the directory (132 access fh), and Lefty replies with the permissions. Sunny then uses the readdirplus to read the complete directory. These remote procedure calls are covered in RFC 1813 and were summarized in Part I of this article:
Although the command sequence is very simple to access remote file systems, there are numerous things that can keep the mount from functioning correctly. Before mounting the directory, the mount point must exist or be created with a mkdir command. Lack of a local directory for the mount is typically the only thing that goes wrong on the client side. Most NFS integration problems are associated with a mismatch between the client and server or incomplete configuration on the server.

The easiest way to troubleshoot the server problems is from the server; however, sometimes this is not possible when someone else administers the server. A quick way to ensure the server has the appropriate services configured is to use the rpcinfo command with the -p parameter. From Sunny, the Solaris host, we can see that the Linux host has the following RPC processes registered:

# rpcinfo -p
   program vers proto   port  service
    100000    2   tcp    111  rpcbind
    100000    2   udp    111  rpcbind
    100024    1   udp    692  status
    100024    1   tcp    694  status
    100005    3   udp   1024  mountd
    100005    3   tcp   1024  mountd
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100021    1   udp   1026  nlockmgr
    100021    3   udp   1026  nlockmgr
    100021    4   udp   1026  nlockmgr
Note that versions are also listed, which comes in handy should you have an environment that requires support of multiple NFS protocols. If a particular daemon is not running, then it must be corrected on the server. After a mount fails, the rpcinfo -p below shows that the mountd is not running on the server:

# rpcinfo -p
   program vers proto   port  service
    100000    2   tcp    111  rpcbind
    100021    4   udp   1026  nlockmgr
The rpcinfo can be very useful in ensuring that remote processes are running. The -p parameter is the most useful, but check the man page for full coverage of rpcinfo.

Another useful tool is the nfsstat command. The nfsstat can determine whether clients are actually accessing an export, as well as reporting statistics by protocol version.

tcpdump can also be quite useful for troubleshooting problems:

[root@lefty /]# tcpdump host lefty and host sunny -s512
tcpdump: listening on eth0
06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 lookup   \
   fh Unknown/1"test.c" (DF)
06:29:51.773819 lefty.mcwrite.n.nfs > sunny.2191984020: reply ok 116   
   lookup ERROR: No such file or directory (DF)
06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs: 128 getattr   \
   fh Unknown/1 (DF)
06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: reply ok 112   \
   getattr DIR 40755 ids 0/0 sz 0x000001000  (DF)
06:29:51.775289 sunny.2191984022 > lefty.mcwrite.n.nfs: 140 lookup   \
   fh Unknown/1"test.c" (DF)
06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: reply ok 116   \
   lookup ERROR: No such file or directory (DF)
06:29:51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 create   \
   fh Unknown/1 "test.c" (DF)
06:29:51.776169 lefty.mcwrite.n.nfs > sunny.2191984023: reply ok 120   \
   create ERROR: Permission denied (DF)
In the above output from touch test.c, the touch command tried to access a file by the name of test.c, then it looked for a directory by the same name. After failing both tests, it then tried to create test.c, which also fails.

Once the file system is mounted, the most common errors relate to common UNIX access rights. The use of common uid or Sun's NIS+ can help ensure permissions are implemented globally across file systems. Some administrators are tempted to "open" directories through the use of giving world-read permissions; however, this should be avoided for security reasons. Even ignoring the security implications, this methodology is a management nightmare because processes or users seldom create data as world readable.

The root user is given special treatment within NFS mounts. To avoid the limitless possibilities afforded the super user, root user requests are treated as if they come from the user "nobody", which effectively restricts root access to world-readable and write-enabled files. To add additional security to your NFS implementation, refer to the "Security Measures and Resources" sidebar.

Solaris NFS Server

Configuring Solaris to run as an NFS server is as straightforward as the Linux version; however, the commands and file locations are a bit different. Solaris automatically starts the NFS services and exports all file systems when run level 3 is reached at boot up. To manually start the processes, use:

To start the mount daemon, and to start the NFS server, use:

With Solaris 2.6, Solaris no longer uses an export file to identify the file systems to be exported. Rather, the files are exported using the share command. Assuming we want to allow remote hosts to mount /export/home, use the following command run as root:

share -F nfs /export/home
(See the sidebar for the -o parameter to create limitations with the share command.)

Once the share command is executed to export the file system, a list of exported shares can be seen with the share command with no parameters:

# share
-               /export/home   rw   ""
An exported file system can also be removed from export status with the unshare command:

# unshare -F nfs /export/home 
Solaris stores the information concerning NFS in the /etc/dfs directory. The /etc/dfs/sharetab contains the exported file systems and is where the share command without parameters gets its information.

The /etc/dfs/dfstab contains a list of share commands that are executed during bootup. To have /export/home automatically exported, the aforementioned share command share -F nfs /export/home would be added to /etc/dfs/dfstab.

An additional useful command for exporting file systems is the shareall command. shareall proves most useful when executed without any parameters, which causes it to execute all the share commands in the /etc/dfs/dfstab. unshareall can be used to remove all exported file systems from their export status.

We Return to Penguin Broadcasting Corporation

Using Linux client NFS capabilities was not presented earlier in the Linux section to follow the normal flow of exporting a file system and then mounting it from the client. But to complete the circle, here is the procedure to mount the exported Solaris file system.

Mounting an exported system on Linux is straightforward and similar to the Solaris version with the noticeable exception that -t as opposed to -F is used to identify the file system type:

[root@lefty /root]# mount -t nfs sunny:/export/home /tmp/tmp2
The status of the mounted file system can then be viewed with the mount command:

[root@lefty /root]# mount
/dev/hda1 on / type ext2 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
sunny:/export/home on /tmp/tmp2 type nfs (rw,addr=
Just the Beginning

The Network File System can be used for diskless workstations, applications, or simple user storage. Whatever the use, I've covered the basics to get you pointed in the right direction. Enjoy.

Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. He works for Sonus Networks as a senior systems engineer on a customer team responsible for a major telecommunications carrier. Ronald is co-author New Rider's Linux Routing ( He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia. He can be reached at: