Red Hat Linux 7 Unleashed

Red Hat Linux 7 Unleashed

By William Ball

Configuring NFS Servers and Clients

The two key files to NFS are /etc/exports and /etc/fstab. The exports file is configured on the server side and specifies which directories are to be shared with which clients and each client's access rights. The fstab file is configured on the client side and specifies which servers to contact for certain directories, as well as where to place them in the directory tree.

Setting Up the /etc/exports File

The /etc/exports file specifies which directories to share with which hosts on the network. You only need to set up this file on your NFS servers.

The /etc/exports file follows this format:


   /directory/to/export    host1(permissions) host2(permissions) host3(permissions) host4(permissions)
#
# Comments begin with the pound sign and must be at the start of
# the line
#
/another/dir/to/export    host2(permissions) host5(permissions)

NOTE

There is a sample /etc/exports at the end of the chapter.

In this example, /directory/to/export is the directory you want to make available to other machines on the network. You must supply the absolute pathname for this entry. On the same line, you list the hosts and which permissions they have to access. If the list is longer than the line size permits, you can use the standard backslash (\) continuation character to continue on the next line.

You specify the names of the hosts in four ways:

Each host is given a set of access permissions. The most significant ones are

If you are familiar with the export file configurations of other flavors of UNIX, you know that this process is not similar. Whether one is better than the other is a holy war discussion best left to Usenet newsgroups.

After you set up your /etc/exports file, run the exportfs command with the -r option:


   exportfs -r

This sends the appropriate signals to the rpc.nfsd and rpc.mountd daemons to reread the /etc/exports file and update their internal tables.

TIP

It is considered a good convention to place all the directories you want to export in the /export hierarchy. This makes the intent clear and self-documenting. If you need the directory to also exist elsewhere in the directory tree, use symbolic links. For example, if your server is exporting its /usr/local hierarchy, you should place the directory in /export, thereby creating /export/usr/local. Because the server itself will need access to the /export/usr/local directory, you should create a symbolic link from /usr/local that points to the real location, /export/usr/local.

TIP

If you have an error in your /etc/exports file, it is reported when NFS starts up in syslog. Syslog is explained in Chapter 21, "Linux System Administration."

Using mount to Mount an Exported Filesystem

To mount a filesystem, use the mount command:


   mount servername:/exported/dir /dir/to/mount

servername is the name of the server from which you want to mount a filesystem, /exported/dir is the directory listed in its /etc/exports file, and /dir/to/mount is the location on your local machine where you want to mount the filesystem. For example, to mount /export/home from the NFS server denon to the directory /home, use


   mount denon:/export/home /home

Remember that the directory must exist in your local filesystem before anything can be mounted there.

You can pass options to the mount command. The most important characteristics are specified in the -o options. These characteristics are listed in Table 16.1.

Table 16.1. Arguments to mount

Characteristic Description
rw Read/write.
ro Read-only.
bg Background mount. Should the mount initially fail (the server is down, for instance), the mount process will place itself in the background and continue trying until it is successful. This is useful for filesystems mounted at boot time because it keeps the system from hanging at that mount if the server is down.
intr Interruptible mount. If a process is pending I/O on a mounted partition, it will allow the process to be interrupted and the I/O call to be dropped.
soft By default, NFS operations are hard, meaning that they require the server to acknowledge completion before returning to the calling process. The soft option allows the NFS client to return a failure to the calling process after retrans number of retries.
retrans Specifies the maximum number of retried transmissions to a soft-mounted filesystem.
wsize Specifies the number of bytes to be written across the network at once. The default is 8192 (for example, wsize=2048). You shouldn't change this value unless you are sure of what you are doing. Setting this value too low or too high can have a negative impact on your system's performance.
rsize Specifies the number of bytes to be read across the network at once. Like wsize, the default is 8,192 bytes. The same warning applies as well: Changing the value without understanding its effect can have a negative impact on your system's performance.

Here's an example of these parameters in use:


   mount -o rw,bg,intr,soft,retrans=6 denon:/export/home /home

NOTE

There are many more options to the mount command, but you will rarely see them. See the man page for mount for additional details.

CAUTION

Solaris NFS clients talking to Linux NFS servers seems to bring out a bug in the Linux NFS implementation. If you suddenly notice normal files being treated as directories or other such unusual behavior, change the wsize and rsize to 2048 when mounting the directory. This appears to fix the problem without hurting performance too drastically.

Unmounting a Filesystem

To unmount the filesystem, use the umount command:


   umount /home

This will unmount the /home filesystem.

There is a caveat, of course. If users are using files on a mounted filesystem, you cannot unmount it. All files must be closed before the unmount can happen, which can be tricky on a large system, to say the least. There are three ways to handle this:

Configuring the /etc/fstab File to Mount Filesystems Automatically

At boot time, the system will automatically mount the root filesystem with read-only privileges. This allows it to load the kernel and read critical startup files. However, after the system has bootstrapped itself, it will need guidance. Although it is possible for you to jump in and mount all the filesystems, it isn't realistic because you then have to finish bootstrapping the machine yourself. Even worse, the system might not come back online by itself.

To get around this, Linux uses a special file called /etc/fstab. This file lists all the partitions that need to be mounted at boot time and the directory where they need to be mounted. Along with that information, you can pass parameters to the mount command.

NOTE

NFS servers can also be NFS clients. For example, a Web server that exports part of its archive to, say, an FTP server, can NFS mount from the server containing home directories at the same time.

Each filesystem to be mounted is listed in the fstab file in the following format:


   /dev/device        /dir/to/mount      ftype parameters fs_freq fs_passno

An example would look like this:


   server:/usr/local/pub    /pub    nfs    rsize=8192,wsize=8192,timeo=14,intr

NOTE

There is a sample /etc/fstab at the end of the chapter.

The following items make up this line:

Any lines in the fstab file that start with the pound symbol (#) are considered comments and are ignored.

If you need to mount a new filesystem while the machine is live, you must perform the mount by hand. If you want this mount to be active automatically the next time the system is rebooted, you should add it to the fstab file.

There are two notable partitions that don't follow the same set of rules as normal partitions. They are the swap partition and /proc, which use filesystem types swap and proc, respectively.

You do not mount the swap partition using the mount command. It is instead managed by the swapon command. For a swap partition to be mounted, you must list it in the fstab file. Once it is there, use swapon with the -a parameter. The /proc filesystem is even stranger because it really isn't a filesystem. It is an interface to the kernel abstracted into a filesystem format. Take a peek into it for a large amount of useful information regarding the inner workings of the kernel.

TIP

If you need to remount a filesystem that already has an entry in the fstab file, you don't need to type the mount command with all the parameters. Instead, simply pass the directory to mount as the parameter, as in


        mount /dir/to/mount

where /dir/to/mount is the directory that needs to be mounted. mount will automatically look to the fstab file for all the details, such as which partition to mount and which options to use.

If you need to remount a large number of filesystems that are already listed in the fstab file, you can use the -a option in mount to remount all the entries in fstab:


        mount -a

If it finds that a filesystem is already mounted, no action on that filesystem is performed. If it finds that an entry is not mounted, on the other hand, it will automatically mount it with the appropriate parameters.

CAUTION

When you are setting up servers that mount filesystems from other servers, be wary of cross mounting. Cross mounting happens when two servers mount each other's filesystems. This can be dangerous if you do not configure the /etc/fstab file to mount these systems in the background (via the bg option), because it is possible for these two machines to deadlock during their boot sequence as each host waits for the other to respond.

For example, let's say you want host1 to mount /export/usr/local from host2 and host2 to mount /export/home/admin from host1. If both machines are restarted after a power outage, host1 will try to mount the directory from host2 before turning on its own NFS services. At the same time, host2 is trying to mount the directory from host1 before it turns on its NFS services. The result is that each machine waits forever for the other machine to start.

If you use the bg option in the /etc/fstab entry for both hosts, they would fail on the initial mount, place the mount in the background, and continue booting. Eventually, both machines would start their NFS daemons and allow each other to mount their respective directories.

Share ThisShare This

Informit Network