Configuring an NFS Server

Configuring an NFS Server

If you installed the NFS server during installation, a startup script will have been created in /etc/init.d, called nfs.server. Thus, the NFS server can be started manually by typing the following command:

# /etc/init.d/nfs.server start

This command will start at least two daemons: the NFS server (/usr/lib/nfs/nfsd) and the mount daemon (/usr/lib/nfs/mountd). nfsd is responsible for answering access requests from clients for shared volumes on the server, while mountd is responsible for providing information about mounted file systems.

To check whether or not the NFS server has started correctly, it is possible to examine the process list for nfsd and mountd by using the following commands:

# ps -eaf | grep nfsd
    root 19961     1  0   Aug 31 ?        0:09 /usr/lib/nfs/nfsd -a 16
#  ps -eaf | grep mountd
    root   370     1  0   May 16 ?        2:49 /usr/lib/nfs/mountd

Or, to save space:

      # ps -aef | egrep 'mountd|nfsd'

In this case, both nfsd and mountd are operating correctly. In order to stop the NFS server, the following command may be used:

# /etc/init.d/nfs.server stop

There are some optional services started by the NFS server startup script, including daemons that support diskless booting (the Reverse Address Resolution Protocol daemon, /usr/sbin/in.rarpd, and the boot parameter server, /usr/sbin/rpc.bootparamd). In addition, a separate daemon for x86 boot support (/usr/sbin/rpld), using the Network Booting RPL (Remote Program Load) protocol, may also be started.


You only need to configure these services if you wish to provide diskless booting for local clients; otherwise, they can be safely commented from the /etc/init.d/nfs.server script.

Sharing File Systems

To actually share file systems and directories, you can use the share command. For example, if you want to share the /var/mail directory from carolina to georgia, you could use the following command:

# share -F nfs -o rw=georgia /var/mail

In this example, '-F nfs' stands for 'a file system of type NFS.' Of course, we really want to share to virginia and fairfax as well, so we would probably use this command:

# share -F nfs -o rw=georgia,virginia,fairfax /var/mail

The /var/mail volume is shared to these clients because users on these systems need to read and write their e-mail. However, if we need to share a CD-ROM volume, we obviously need to share it read-only:

# share -F nfs -o ro /cdrom

Normally, the volumes to be shared are identified in the /etc/dfs/dfstab file. One of the really innovative features of NFS is that a system that shares volumes to other systems can actually remotely mount shared volumes from its own clients. For example, while carolina might share the volume /cdrom to georgia, fairfax, and virginia, virginia might share the /staff directory, which contains home directories, to carolina, georgia, and fairfax using the following command:

# share -F nfs -o rw=georgia,carolina,fairfax /staff

File systems can be unshared using the unshare command. For example, if we are going to change a CD-ROM on carolina that is shared to clients using NFS, it might be wise to unmount it first:

# unshare -F nfs /cdrom

To unshare all volumes that are currently being shared from a NFS server, the following command can be used:

# unshareall

The command dfmounts shows the local resources shared through the networked file system that are currently mounted by specific clients:

# dfmounts
  -          carolina /cdrom                  virginia,Georgia
  -          carolina /var/mail               fairfax,virginia,Georgia
  -       carolina /opt/answerbook         fairfax

However, dfmounts does not provide information about the permissions by which directories and file systems are shared, nor does it show those shared resources that have no clients currently using them. To display this information, we need to use the share command with no arguments. On virginia, this looks like this:

# share
/staff rw=georgia,fairfax,carolina  "staff"

while on carolina, the volumes are different:

# share
-                  /cdrom  ro=georgia,fairfax,carolina "cdrom"
-                 /var/mail  rw=georgia,fairfax,carolina "mail"

Conversely, as a client, you want to determine which volumes are available for you to mount from NFS servers. This can be achieved by using the dfshares command. For example, to view the mounts available from the server virginia, executed on carolina, the dfshares would be entered as shown, and the following output would be displayed:

# dfshares -F nfs virginia
RESOURCE                  SERVER           ACCESS         TRANSPORT
virginia:/staff           virginia         -              -

Table 23-1 shows the most common options for the share command.

Table 23-1: NFS Server Options




Sets the username of unknown users to username.


Starts NFS logging.


Prevents applications from executing as setuid.


Prevents client access to subdirectories of exported server volumes.


Prevents writing to an exported file system.


Allows remote access by remote root users as the local root user.


Permits reading and writing to an exported file system.


Specifies the authentication level (sys, dh, or krb4).

Installing an NFS Client

In order to access file systems being shared from an NFS server, a separate NFS client must be operating on the client system. There are two main daemon processes that must be running in order to use the mount command to access shared volumes: the NFS lock daemon (/usr/lib/nfs/lockd), and the NFS stat daemon (/usr/lib/nfs/statd). lockd manages file sharing and locking at the user level, while the statd is used for file recovery after connection outage.

If NFS was installed during the initial system setup, a file called nfs.client should have been created in /etc/init.d. In order to run the NFS client, the following command needs to be executed:

# /etc/init.d/nfs.client start

Just like the NFS server, you can verify that the NFS daemons have started correctly by using the following commands:

# ps -eaf | grep statd
  daemon   211     1  0   May 16 ?        0:04 /usr/lib/nfs/statd
# ps -eaf | grep lockd
    root   213     1  0   May 16 ?        0:03 /usr/lib/nfs/lockd

These commands can be combined as follows:

# ps -aef | egrep 'statd|lockd'

If these two daemons are not active, the NFS client will not run. The next step is for the client to consult the /etc/vfstab file, which lists both the UFS and NFS file systems that need to be mounted, and attempts to mount the latter if they are available by using the mountall command.

To stop the NFS client once it is operating, the following command may be used:

# /etc/init.d/nfs.client stop

The NFS server is usually started automatically during run level 3.

Checking portmapper Status

If you're having trouble starting the NFS daemon, it's often an rpc problem. In order to determine whether an rpc portmapper is running, you may use the rpcinfo command:

# rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  rpcbind
    100000    3   tcp    111  rpcbind
    100000    2   tcp    111  rpcbind
    100000    4   udp    111  rpcbind
    100000    3   udp    111  rpcbind
    100000    2   udp    111  rpcbind
    100007    3   udp  32774  ypbind
    100007    2   udp  32774  ypbind
    100007    1   udp  32774  ypbind
    100007    3   tcp  32771  ypbind
    100007    2   tcp  32771  ypbind
    100007    1   tcp  32771  ypbind
    100011    1   udp  32785  rquotad
    100024    1   udp  32789  status
    100024    1   tcp  32775  status
    100021    1   udp   4045  nlockmgr
    100021    2   udp   4045  nlockmgr
    100021    3   udp   4045  nlockmgr
    100021    4   udp   4045  nlockmgr
    100068    2   udp  32809
    100068    3   udp  32809
    100068    4   udp  32809
    100068    5   udp  32809
    100083    1   tcp  32795
    100021    1   tcp   4045  nlockmgr
    100021    2   tcp   4045  nlockmgr
    100021    3   tcp   4045  nlockmgr
    100021    4   tcp   4045  nlockmgr
    100005    1   udp  32859  mountd
    100005    2   udp  32859  mountd
    100005    3   udp  32859  mountd
    100005    1   tcp  32813  mountd
    100005    2   tcp  32813  mountd
    100005    3   tcp  32813  mountd
    100026    1   udp  32866  bootparam
    100026    1   tcp  32815  bootparam

In this example, both mountd and nfsd are running, along with several other services, so the NFS daemon should have no problems executing. However, the RPL service is not active, so x86 clients would not be able to use the local server as a boot server.

Mounting Remote File Systems

On the client side, if we want to mount a volume that has been shared from an NFS server, we use the mount command. For example, if we want to mount the exported CD-ROM from carolina on the NFS client virginia, we would use this command:

# mount -F nfs -o ro carolina:/cdrom /cdrom

Like the /etc/dfs/dfstab files, which record a list of volumes to be exported, the /etc/vfstab file can contain entries for NFS volumes to be mounted from remote servers. For example, on the machine fairfax, if we wanted the /var/mail volume on carolina to be mounted locally as /var/mail, we would enter the following line in /etc/vfstab:

 carolina:/var/mail     -     /var/mail     nfs     -     yes     rw

This line can be interpreted as a request to mount /var/mail from carolina read/write on the local mount point /var/mail as an NFS volume that should be mounted at boot time. If you made the appropriate changes to the /etc/vfstab file on virginia, and you want to mount the /var/mail partition, you can use the following command:

# mount /var/mail

This will attempt to mount the remote /var/mail directory from the server carolina. Alternatively, you can use the command,

# mountall

which will mount all partitions that are listed in /etc/vfstab, but which have not yet been mounted.

File systems can be unmounted by using the umount command. For example, if the /cdrom file system on carolina is mounted on virginia as /cdrom, then the command,

# umount /cdrom

will unmount the mounted NFS volume. Alternatively, the unmountall command can be used, which unmounts all currently mounted NFS volumes. For example, the command,

# umountall -F nfs

unmounts all volumes that are currently mounted through NFS. The umount -f command forcibly unmounts a file system:

# umount -f /cdrom

When a remote volume is mounted on a local client, it should be visible to the system just like a normal disk, and so commands like df, which displays disk slice information, can be readily used:

# df -k
carolina:/cdrom      412456 341700  70756    83%    /cdrom
carolina:/var/mail     4194304 343234  3851070    8%    /var/mail
carolina:/opt/answerbook     2097152  1345634    750618  64%    /opt/answerbook

The main options available for mounting NFS file systems are shown in Table 23-2.

Table 23-2: NFS Client Options




Mounts a file system's read-only permissions.


Mounts a file system's read/write permissions.


No timeouts permitted-the client will repeatedly attempt to make a connection.


Timeouts permitted-the client will attempt a connection, and give an error message if connection fails.


Attempts to mount a remote file system in the background if connection fails.

Enhancing Security

So far, we've examined NFS without considering the security implications of sharing a file system to clients. In a local intranet environment, with protection from a firewall, some administrators implement open NFS sharing, where client lists are not supplied to share commands to limit access to server volumes. The problem with this approach is spoofing: an external system may be able to 'pretend' to be part of your local network, thereby gaining access to globally shared NFS volumes. Given that NFS authentication is usually based on mappings of usernames on the client to the server, if a spoofed system contains equivalent user accounts to those found on the server, unauthorized clients will be able to read and write data at will. This is why it's critical to only share volumes to specific client systems, using the appropriate 'read-write' or 'read-only' designation.

The other key parameter for the share command, sec, specifies the type of authentication required to access server volumes. By default, the sys level is used, whereby usernames and groups are mapped between client and server. Thus, the user lynda on the client will have the same access permissions as lynda on the server. However, other alternatives are available, depending on the relative risks involved in data loss. If sensitive data is being shared by a NFS server, it may be wise to implement a more sophisticated authentication method, including one based on DES public-key cryptography (the dh level, standing for Diffie-Hellman), or the Kerberos 4 authentication method (the krb4 level). If a volume is exported with the dh or krb4 authentication levels, then all clients must use the method specified to access data on the volume specified. To support the dh or krb4 authentication levels, secure RPC must be running.


User keys can be updated by using the chkey command.


NFS performance is determined by a number of factors, including:

  • Server CPU speed, and number of server CPUs

  • Server physical RAM and virtual RAM

  • Server disk speed

  • Server system load

  • Server CacheFS capacity

  • Server network interfaces

  • Number of clients

  • Speed of local network

  • Domain Name Lookup Cache (DNLC) speed

Many sites develop NFS services incrementally-as the number of users grows, so does the number of CPUs, memory, and network interfaces, along with faster disks allocated to improving NFS performance.


A number of software methods, including the CacheFS and DNLC settings, can be modified to improve data throughput.

One of the best methods for determining how NFS is performing, from both a client and server perspective, is to use the nfsstat command to gather performance statistics over a period of weeks or months. In particular, counting the number of calls and bad calls can show the proportion of successful to unsuccessful requests, respectively, to the server. To run nfsstat on the server, the following command is used:

# nfsstat -s
Server nfs:
calls badcalls
575637455 3433

Here, we can see that the proportion of bad calls to the total number of calls is 3433 ¸ 575637455, which is much less than 1 percent. After gathering statistics for each interval, the counters can be reset to zero by using the following command:

# nfsstat -z

Part I: Solaris 9 Operating Environment, Exam I