NFS (Network File System) Administration

NFS allows you to share files across networks. This capability eliminates the need to duplicate commonly used files on each machine in your network. NFS is used by all of the major UNIX variants. It can be used to share files between two, or among multiple, operating system types. For instance, NFS allows you to share files between a Solaris system and a Linux system. NFS is discussed in more detail in Chapter 15.

Before you can use NFS, you need to make sure that a network provider is configured, that the Remote Procedure Call (RPC) package has been installed, and that the RPC database has been configured for your machine. Configuring a network provider has already been discussed. What follows is a discussion of the RPC package and its databases.

Checking RPC

NFS relies on RPC, which allows machines to access services on a remote machine via a network RPC handles remote requests and then hands them over to the operating system on the local machine. The local system has daemons running that attempt to process the remote request. These daemons issue the system calls needed to do the operations.

Because NFS relies on RPC, you need to check that RPC is running before starting NFS. You can check to see if it is running by typing this:

 # ps −ef | grep rpc

If you see “rpc.bind” in the output of this command, then RPC is running. Otherwise, use the script /etc/init.d/rpc to start RPC. This startup script, also known as the portmapper in some variants, is in portmap/rpc.portmap/rpc.portmapper.

You should also check to make sure that the data files for RPC are set up in files with names of the form /etc/net/*/hosts and /etc/net/*/services. You replace the * with the name of your transport. You may see many transports in /etc/net, because you will have one per transport protocol, such as the transport protocols associated with TCP/IP, ticlts, ticots, and ticotsord.

Setting Up NFS

To set up NFS on clients and servers, the daemons used by NFS need to be started. For example, on Solaris machines, the daemons used by NFS clients and NFS servers are started by running the boot scripts /etc/init.d/nfs.client and /etc/init.d/nfs.server, respectively. Because this happens automatically at run level 3, you generally will not have to manually run these scripts. However, you start the NFS server daemons using the command

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

You can start the NFS client daemons using the command

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

On Linux, you can start both the NFS client and server daemons using the command

 # /etc/init.d/nfs start

Note that NFS requires little in the way of configuration, as there is no notion of domains or name servers. With NFS, more of the configuration takes place as you actually make use of its facilities such as sharing and mounting resources.

Sharing   NFS relies on the administrator who is sharing the resource to keep security in mind. So when you share a resource, you also must determine how secure you want that resource to be.

NFS resources do not have a name used to identify them, other than the actual path to the resource that is being shared. Machines on the network refer to the resource as machinename:resource when they attempt an operation on an NFS resource.

Mounting   Mounting resources with NFS requires that resources are identified with the notation machine-name:resource. NFS resources can also be mounted via the automounter, discussed in the following section, which mounts the resource only when a user actually attempts to access it.

The Automounter

NFS includes a feature called the automounter that allows resources to be mounted on an as-needed basis, without requiring the administrator to configure anything specifically for these resources.

When a user requires a resource, it is automatically mounted for the user by the automounter. After the task using this resource has been completed, it will eventually be unmounted.

All resources are mounted under /tmp_mnt, and symbolic links are set up to place the resource on the requested mount point. The automounter uses three type of maps: master maps, direct maps, and indirect maps. A brief description of these three maps follows for the Solaris system. For more information on the particular automounter available for your system, see the documentation for your system. Note that there are two widely used automounters for Linux systems, autofs and amd (the Berkeley Automounter). For more information on autofs, go to http://www.faqs.org/docs/Linux-mini/Automount.html, and for more information on amd, go to http://www.am-utils.org/. For more information on NFS administration and automounters on AIX and HP-UX systems, go to http://www.freelab.net/uni x/hp- u x/chap1 2_nfs. html.

The Master Map   The master map is used by the automounter to find a remote resource and determine what needs to be done to make it available. The master map invokes direct or indirect maps that contain detailed information. Direct maps include all information needed by automount to mount a resource. Indirect maps, on the other hand, can be used to specify alternate servers for resources. They can also be used to specify resources to be mounted as a hierarchy under a mount point.

A line in the master map has the form

 mountpoint map [mount-options]

An example of a line in the master map is

 /usr/add-on   /etc/libmap   −rw

This line tells the automounter to look at the map /etc/libmap and to mount what is listed in this map on the mount point /usr/add-on on the local system. It also tells the automounter to mount these resources with read/write permission.

Direct Map   A direct map can be invoked through the master map or when you invoke the automount command.

An entry in a direct map has the form

 key [mount-options] location 

where “key” is the full pathname to the mount point, “mount-options” are the options to be used when mounting (such as –ro for read-only), and “location” is the location of the resource specified in the form server.path-name. The following line is an example of an entry in a direct map:

 /usr/memos   −ro   jersey:/usr/reports

This entry is used to tell the automounter to mount the remote resources in /usr/reports on the server jersey with read-only permission on the local mount point /usr/memos. When a user on the local system attempts to access a file in /usr/reports, the automounter reads the direct map, mounts the resource from jersey onto /tmp_mnt/usr/memos, and creates a symbolic link between /tmp_mnt/usr/memos and /usr/memos.

A direct map may have many lines specifying many resources, like this:

 /usr/src \                     /cmd-rw,softcmdsrc:/usr/src/cmd \                     /uts-ro, softutssrc:/usr/src/uts \                     /lib-ro,securelibsrc:/usr/lib/src 

In the preceding example, the first line specifies the top level of the next three mount points. Here, /usr/src/cmd, /usr/src/uts, and /usr/src/lib all reside under /usr/src. A backslash (\) denotes that the following line is a continuation of this line. The last line does not end with a \, which means that this is the end of the line. Each entry specifies the server that provides the resource; that is, the server cmdsrc is providing the resource to be mounted on /usr/src/cmd. You can see that it is possible to have different servers for all of the mount points, with different options.

You can also specify multiple locations for a single mount point, so that more than one server provides a resource. You do this by including multiple locations in the location field. For example, the following line,

 /usr/src   −rw,soft cmdsrc:/usr/src utssrc:/usr/src libsrc:/usr/src

can be used in a direct map. To mount /usr/src, the automounter first queries the servers on the local network. The automounter mounts the resource from the first server that responds, if possible.

Indirect Maps   Unlike a direct map, an indirect map can only be accessed through the master map. Entries in an indirect map look like entries in a direct map, in that they have the form

 key [mount-options] location 

Here, the key is the name of the directory (and not its full pathname) used for the mount point, mount-options is a list of options to mount (separated by commas), and location is the server.path-name to the resource.

NFS Security

As mentioned earlier, you can use the share command to provide some security for resources shared using NFS. (For more serious security needs, you can use the Secure NFS facility if it is available for your UNIX variant, which is described later in this chapter.)

When you share a resource, you can set the permissions you want to grant for access to this resource. You specify these permissions using the –o option to share. For instance, –o rw will allow read/write access.

You may also choose to map user IDs across the network. For example, say you want to give root on a remote machine root permissions on your local machine. (By default, remote root has no permissions on the local machine.) To map IDs, use a command such as this:

 # share −o root=remotemachine

When deciding the accesses to assign to a resource, first decide who needs to be able to use this resource.

Secure NFS

Secure NFS provides a method to authenticate users across the network and allows only those users who have been authorized to make use of the resources. Secure NFS is built around the Secure RPC facility (Note that Secure NFS is not available for all UNIX variants. For some variants, a different secure version of NFS is available.) Secure RPC will be discussed first.

Secure RPC

Secure RPC is used for authentication of users via credentials and verifiers. An example of a credential is a driver’s license that has information confirming that you are licensed to drive. An example of a verifier is the picture on the license that shows what you look like. You display your credential to show you are licensed to drive, and the police officer verifies this when you show your license. In Secure RPC, a client sends both credentials and a verifier to the server, and the server sends back a verifier to the client. The client does not need to receive credentials from the server because it already knows who the server is.

Secure RPC uses the Data Encryption Standard (DES) and public-key cryptography to authenticate both users and machines. Each user has a public key, stored in encrypted form in a public database, and a private key, stored in encrypted form in a private directory The user runs the keylogin program, which prompts the user for an RPC password and uses this password to decrypt the secret key keylogin passes the decrypted secret key to the keyserver, an RPC service that stores the decrypted secret key until the user begins a transaction with a secure server. The keyserver is used to create a credential and a verifier used to set up a secure session between a client and a server. The server authenticates the client, and the client, the server, using this procedure.

You can find details about how Secure RPC works in your network administrator’s guide for your variant.

Administering Secure NFS

To administer Secure NFS, you must make sure that public keys and secret keys have been established for users. This can be done either by the administrator via the newkey command or by the user via the chkey command.

Public keys are kept in the file /etc/publickey, whereas secret keys for users, other than root, are kept in the file /etc/keystore. The secret key for root is kept in the file /etc/.rootkey/.

After this, each user must run /usr/sbin/keylogin. (As the administrator, you may want to put this command in users’ /etc/profile, to ensure that all users run it.) You then need to make sure that /usr/sbin/keyserve (the keyserve daemon) is running.

Once Secure NFS is running, you can use the share command with the –o secure option to require authentication of a client requesting a resource. For example, the command

 # share −F nfs −o secure /user/games

shares the directory /usr/games so that clients must be authenticated via Secure NFS to mount it.

As with many security features, be aware that Secure NFS does not offer foolproof user security. Methods are available for breaking this security, so that unauthorized users are authenticated. However, this requires sophisticated techniques that can only be carried out by experts. Consequently, you should only use Secure NFS to provide a limited degree of user authentication capabilities.

Troubleshooting NFS Problems

As mentioned in the preceding section, NFS relies on the RPC mechanism. NFS will fail if any of the RPC daemons have stopped or were not started. You can start RPC by typing this:

 # /etc/init.d/rpc start

If you wish to restart RPC, first stop RPC by executing this script, replacing the start option with stop. Then run this command again to start RPC. If you see any error messages when you start RPC, there is most probably a configuration problem in one or more of the files in /etc/net.

If NFS had been running but now no longer works, run ps –ef to check that /usr/lib/nfs/ mountd and /usr/lib/nfs/nfsd are running. If mountd is not running, you will not be able to mount remote resources; if nfsd is not running, remotes will not be able to mount your resources. You should also see at least four /usr/lib/nfs/nfsd processes running in the output. One other daemon should be running on the client machine, /usr/lib/nfs/biod, which is a client-side daemon that enables clients to use NFS.

Other problems may be related to the network itself, so be sure that the transport mechanism NFS is using is running. Consult your network administrator’s guide for information about other possible failures.