mirror of https://github.com/tLDP/LDP
162 lines
6.5 KiB
Plaintext
162 lines
6.5 KiB
Plaintext
<sect1 id="client">
|
|
<title>Setting up an NFS Client</title>
|
|
<sect2 id="remotemount">
|
|
<title>Mounting remote directories</title>
|
|
<para>
|
|
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 <filename>/proc</filename> filesystem you can check the latter by reading the
|
|
file <filename>/proc/filesystems</filename> and making sure there is a line containing
|
|
nfs. If not, typing <userinput>insmod nfs</userinput> 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
|
|
<command>mount</command> command below is run.
|
|
</para>
|
|
<para>
|
|
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 <command>rpc.statd</command> and <command>rpc.lockd</command>
|
|
running on both the client and the server. Most recent distributions
|
|
start those services by default at boot time; if yours doesn't, see
|
|
<xref linkend="config"> for information on how to start them up.
|
|
</para>
|
|
<para>
|
|
With <command>portmap</command>, <command>lockd</command>,
|
|
and <command>statd</command> 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
|
|
<emphasis>master.foo.com</emphasis>,and we want to mount the <filename>/home</filename> directory on
|
|
<emphasis>slave1.foo.com</emphasis>. Then, all we have to do, from the root prompt on
|
|
<emphasis>slave1.foo.com</emphasis>, is type:
|
|
<screen>
|
|
# mount master.foo.com:/home /mnt/home
|
|
</screen>
|
|
and the directory <filename>/home</filename> on master will appear as the directory
|
|
<filename>/mnt/home</filename> on <emphasis>slave1</emphasis>. (Note that
|
|
this assumes we have created the directory <filename>/mnt/home</filename>
|
|
as an empty mount point beforehand.)
|
|
</para>
|
|
<para>
|
|
If this does not work, see the Troubleshooting section (<xref linkend="troubleshooting">).
|
|
</para>
|
|
<para>
|
|
You can get rid of the file system by typing
|
|
<screen>
|
|
# umount /mnt/home
|
|
</screen>
|
|
just like you would for a local file system.
|
|
</para>
|
|
</sect2>
|
|
<sect2 id="boot-time-nfs">
|
|
<title>Getting NFS File Systems to Be Mounted at Boot Time</title>
|
|
<para>
|
|
NFS file systems can be added to your <filename>/etc/fstab</filename> 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 <userinput>nfs</userinput> 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
|
|
<filename>/etc/fstab</filename> would look like:
|
|
<programlisting>
|
|
# device mountpoint fs-type options dump fsckorder
|
|
...
|
|
master.foo.com:/home /mnt nfs rw 0 0
|
|
...
|
|
</programlisting>
|
|
</para>
|
|
<para>
|
|
See the man pages for <filename>fstab</filename> 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.
|
|
</para>
|
|
<para>
|
|
At this point you should have NFS working, though a few tweaks
|
|
may still be necessary to get it to work well. You should also
|
|
read <xref linkend="security"> to be sure your setup is reasonably secure.
|
|
</para>
|
|
</sect2>
|
|
<sect2 id="Mountoptions">
|
|
<title>Mount options</title>
|
|
<sect3 id="soft-vs-hard">
|
|
<title>Soft vs. Hard Mounting</title>
|
|
<para>
|
|
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:
|
|
</para>
|
|
<para>
|
|
<glosslist>
|
|
<glossentry>
|
|
<glossterm>soft</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
<glossentry>
|
|
<glossterm>hard</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
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 <userinput>intr</userinput>. When the
|
|
NFS server is back online the program will
|
|
continue undisturbed from where it was. We recommend using
|
|
<userinput>hard,intr</userinput> on all NFS mounted file systems.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
</glosslist>
|
|
</para>
|
|
<para>
|
|
Picking up the from previous example, the fstab entry would now
|
|
look like:
|
|
<programlisting>
|
|
# device mountpoint fs-type options dump fsckord
|
|
...
|
|
master.foo.com:/home /mnt/home nfs rw,hard,intr 0 0
|
|
...
|
|
</programlisting>
|
|
</para>
|
|
</sect3>
|
|
<sect3 id="blocksize">
|
|
<title>Setting Block Size to Optimize Transfer Speeds</title>
|
|
<para>
|
|
The <userinput>rsize</userinput> and <userinput>wsize</userinput> mount
|
|
options specify the size of the chunks of data that the client and
|
|
server pass back and forth to each other.
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
<para>
|
|
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. See <xref linkend="performance"> for details.
|
|
</para>
|
|
</sect3>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
|
|
|
|
|