Setting up an NFS Client
1. Mounting Remote Directories
Before beginning, you should double-check to make
sure your mount program is new enough (version 2.10m if you want to
use Version 3 NFS), and that the client machine supports NFS
mounting, though most standard distributions do. If you are using a
2.2 or later kernel with the
/proc
filesystem you can check the latter by reading the file
/proc/filesystems
and making sure there is a line containing nfs. If not, typing insmod
nfs may make it magically appear if
NFS has been compiled as a module; otherwise, you will need to build
(or download) a kernel that has NFS support built in. In general,
kernels that do not have NFS compiled in will give a very specific
error when the mount
command below is run.
To begin using machine as an NFS client, you will
need the portmapper running on that machine, and to use NFS file
locking, you will also need rpc.statd
and rpc.lockd
running on both the client and the server.
With portmap, lockd, and statd running, you should
now be able to mount the remote directory from your server just the
way you mount a local hard drive, with the mount command. Continuing
our example from the previous section, suppose our server above is
called master.foo.com,and
we want to mount the
/home
directory on slave1.foo.com.
Then, all we have to do, from the root prompt on slave1.foo.com,
is type:
# mount master.foo.com:/home /mnt/home
and the directory
/home
on master will
appear as the directory /mnt/home
on slave1.
(Note that this assumes we have created the directory /mnt/home
as an empty mount point beforehand.)
You can get unmount the file system by typing:
# umount /mnt/home
Just like you would for a local file system.
2. Getting NFS File Systems to be Mounted at Boot Time
NFS file systems can be added to your
/etc/fstab
file the same way local file systems can, so that they mount when
your system starts up. The only difference is that the file system
type will be set to nfs
and the dump and fsck order (the last two entries) will have to be
set to zero. So for our example above, the entry in /etc/fstab would
look like:
# device mountpoint fs-type options dump fsckorder
...
master.foo.com:/home /mnt nfs rw 0 0
...
See the man pages for fstab
if you are unfamiliar with the syntax of this file. If you are using
an automounter such as amd
or autofs, the
options in the corresponding fields of your mount listings should
look very similar if not identical.
At this point you should have NFS working, though
a few tweaks may still be necessary to get it to work well.
3. Mount Options
3.1. Soft versus Hard Mounting
There are some options you should consider adding at
once. They govern the way the NFS client handles a server crash or
network outage. One of the cool things about NFS is that it can
handle this gracefully. If you set up the clients right. There are
two distinct failure modes:
- soft
- If a file request fails, the NFS client will report an error to the process on the client machine requesting the file access. Some programs can handle this with composure, most won't. We do not recommend using this setting; it is a recipe for corrupted files and lost data. You should especially not use this for mail disks --- if you value your mail, that is.
- hard
- The program accessing a file on a NFS mounted file system will hang when the server crashes. The process cannot be interrupted or killed (except by a "sure kill") unless you also specify intr. When the NFS server is back online the program will continue undisturbed from where it was. We recommend using hard,intr on all NFS mounted file systems.
Picking up from the previous example, the
fstab
would now look like:
# device mountpoint fs-type options dump fsckord
...
master.foo.com:/home /mnt/home nfs rw,hard,intr 0 0
...
The
rsize
and wsize
mount options specify the size of the chunks of data that the client
and server pass back and forth to each other.
The defaults may be too big or to small; there is no
size that works well on all or most setups. On the one hand, some
combinations of Linux kernels and network cards (largely on older
machines) cannot handle blocks that large. On the other hand, if they
can handle larger blocks, a bigger size might be faster.
Getting the block size right is an important
factor in performance and is a must if you are planning to use the
NFS server in a production environment.
Back to NFS SERVER Setup...
