About the NFS Environment

The NFS environment is a service that enables computers of different architectures running different operating systems to share file systems across a network. NFS has been implemented on many operating systems ranging from MS-DOS^(R) to VMS^(R).

The NFS environment makes it possible for a computer to share local files and directories, and permits remote users to access those files and directories as though they were local to the user's computer.

The NFS environment provides file sharing in a heterogeneous environment, potentially containing many different operating systems. It can be implemented on different operating systems because it defines an abstract model of a file system, rather than an architectural specification. Each operating system applies the NFS model to its file system semantics. This means that file system operations like reading and writing function as though they are accessing a local file.

The benefits of NFS software are as follows:

• Allows multiple computers to use the same files, so the same data can be accessed by everyone on the network
• Reduces storage costs by having computers share applications
• provides data consistency and reliability as all users can read the same set of files
• Mounting of file systems transparent to users
• Accessing remote files is transparent to users
• Supports heterogeneous environments
• Reduces system administration overhead

NFS File Systems

The objects that can be shared through the NFS software include any whole or partial directory tree or file hierarchy--including a single file. A computer cannot share a file hierarchy that overlaps one that is already shared. Peripheral devices such as modems and printers cannot be shared.

In most UNIX system environments, a file hierarchy that can be shared corresponds to a file system or to a portion of a file system; however, NFS software works across operating systems, and the concept of a file system may be meaningless in other, non-UNIX environments. Therefore, the term file system is used throughout this guide to refer to a file or file hierarchy that can be shared and mounted over the NFS environment.

NFS Servers and Clients

A computer that makes a local file system available for mounting by remote computers is called a server. A computer that mounts a file system shared by a remote computer is a client of that computer. Any computer with a disk can be server, a client, or both at the same time.

A server can provide files to a diskless client, a computer that has no local disk. A diskless client relies completely on the server for all its file storage. A diskless client can act only as a client--never as a server.

Servers provide access to their file systems by sharing them over the NFS environment. You specify which file systems are to be shared with the share command and/or the /etc/dfs/dfstab file.

Entries in the /etc/dfs/dfstab file are shared automatically whenever you start NFS operation. You should set up automatic sharing if you need to share the same set of file systems on a regular basis. For example, if your computer is a server that supports diskless clients, you need to make your clients' root directories available at all times.

The dfstab file lists all the file systems that your server shares with its clients and controls which clients may mount a file system. If you want to modify dfstab to add or delete a file system, or to modify the way sharing is done, simply edit the file with any supported text editor (such as vi). The next time the computer enters run level 3, the system reads the updated dfstab to determine which file systems should be shared automatically.

Each line in the file consists of a share command--the same command you enter at the share(1M), in the dfstab file command line to share a file system explicitly. The share command is located in /usr/sbin.

Clients access files on the server by mounting the server's shared file systems. When a client mounts a remote file system, it does not make a copy of the file system; rather, the mounting process uses a series of remote procedure calls that enable the client to access the file system transparently on the server's disk. The mount looks like a local mount, and users type commands as if the file systems were local.

Once a file system has been shared on a server through NFS operation, it can be accessed from a client. NFS file systems are mounted automatically with autofs and name service maps (NIS and NIS+).

NFS Administration Tasks

Your responsibilities as an NFS administrator depend on your site's requirements and the role of your computer on the network. You may be responsible for all the computers on your local network, in which case you may be responsible for the major tasks involved in NFS administration:

• Determining which computers, if any, should be dedicated servers
• Which should act as both servers and clients
• Which should be clients only

Maintaining a server once it has been set up involves the following tasks:

• Sharing and unsharing file systems as necessary
• Modifying administrative files to update the lists of file systems your computer shares and/or mounts automatically
• Checking the status of the network. (Refer to Chapter 5, "NFS Troubleshooting")
• Diagnosing and fixing NFS related problems as they arise
• Setting up maps to use the automatic mounting facility called autofs (See Chapter 6, "Using Autofs")

Remember, a computer can be both a server and a client--both sharing local file systems with remote computers and mounting remote file systems.

Setting Up Automatic Sharing

1. Edit the /etc/dfs/dfstab file.

   Add one entry to the file for each file system that you want to have shared automatically. Each entry must be on a line by itself in the file and has the following syntax:

share [-F nfs] [-o specific-options] [-d description] pathname

where -F nfs indicates that the file system is to be shared through NFS software (this is also the default); specific-options is a comma-separated list of options that regulates how the file system is shared; description is a comment that describes the file system to be shared; and pathname is the full name of the file system to be shared, starting at root (/).

share -F nfs -o ro,rw=homedog:chester /usr/src

In the previous example, read-only access is assigned to any client except homedog and chester, who have read/write access.

share -F nfs -o rw=engineering,ro=homedog /usr/src

In the previous example, read/write is assigned to any client in the engineering netgroup. The client homedog has read-only access. For more information about netgroups, see User Accounts, Printers, and Mail Administration.

Specific options that can follow the -o flag include:

rw	which shares pathname read/write to all clients (by default) except those that are specified under ro=.
ro	which shares pathname read-only to all clients, except those that
b	are specified under rw=.

---

Note - You cannot specify both rw and ro without arguments, and you cannot specify the same client in the rw= list and the ro= list. If no read/write option is specified, the default is read/write for all clients.

---

ro=client[:client] which shares pathname read-only to the listed client computers or netgroup names (overriding rw).

rw=client[:client] which shares pathname read/write to the listed client computers (overriding ro).

anon=uid which allows you to specify a different uid for "anonymous" users--users whose uid is 0--when accessing pathname. By default, anonymous users are mapped to username nobody, which has the UID 60001. User nobody has ordinary user privileges, not superuser privileges.

root=host[:host] which allows a user from host host whose uid is 0 to access pathname as root; root users from all other hosts become anon. If this option is not specified, no user from any host is granted access to pathname as root.

In the NFS environment, a server shares file systems it owns so clients can mount them using autofs. However, a user who becomes the superuser at a client is denied access as the superuser to NFS file systems. When a user logged in as root on one host requests access to a remote file shared through NFS software, the user's ID is changed from 0 to the user ID of the username nobody. The access rights of user nobody are the same as those given to the public for a particular file. For example, if the public has only execute permission for a file, then user nobody can execute only that file.

secure Allows you to share a file system with additional user authentication required

kerberos Allows you to share a file system with kerberos authentication

(see Security, Performance, and Accounting Administration).

Examples of Automatic Sharing Entries in /etc/dfs/dfstab

You want to permit the root user on samba to always have root access to the /usr/src on the server computer. Make the following entry to the server's dfstab file.

share -F nfs -o root=samba /usr/src

You want to permit the root users on samba, homedog, and chester to always have root access to the /usr/src on the server computer. Make the following entry to the server's dfstab file.

share -F nfs -o root=samba:homedog:chester /usr/src

You want all client processes with UID 0 to have superuser access to /usr/src. You should make the following entry in the server's dfstab file.

share -F nfs -o anon=0 /usr/src

anon is short for "anonymous." Anonymous requests, by default, get their user ID changed from its previous value (whatever it may be) to the user ID of username nobody. NFS servers label as anonymous any request from a root user (someone whose current effective user ID is 0) who is not in the list

following the root= option in the share command. The previous command tells the kernel to use the value 0 for anonymous requests. The result is that all root users retain their user ID of 0.

You need to make sure that NFS software is running on the server, if this is the first share command or set of share commands that you have initiated.

1. Run the server script /etc/init.d/nfs.server stop.

2. Run the server script /etc/init.d/nfs.server start. This runs the necessary daemons mountd and nfsd.

This ensures that NFS software is now running on the servers, and will restart automatically when the server is at run level 3 during boot.

At this point, set up your autofs maps so clients can access the file systems you've shared on the server.

Sharing Objects

If you need to share an object multiple times each share command replaces all previous shares of the specified file system(s). If you try to share the root file system to more than one machine using

share -F nfs -o rw=<client>,root=<client>,anon=0 /

and then, wishing to add an additional client, you enter

share -F nfs -o rw=<anotherclient>,root=<anotherclient>,anon=0 /

The second share will overrule the first share. Therefore you must include all the file systems you wish to share each time you add a file system

share -F nfs -o rw=<client>:<anotherclient>,root=<client>:<anotherclient> ,anon=0 /

Setting Up at Boot Time

If you want to mount file systems at boot time instead of using autofs maps, follow this procedure. This method is not recommended because it is very time consuming for a system administrator.

1. Edit the /etc/vfstab file.

Entries in the /etc/vfstab file have the following syntax:

special  fsckdev  mountp  fstype  fsckpass  mount-at-boot  mntopts

Example of a vfstab entry

You want a client computer to mount the /var/mail directory on the server milano. You would like it mounted as /var/mail on the client. You want the client to have read-write access. Make the following entry to the client's vfstab file.

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