Massive update to the NFS chapter.
This update has been bounced around, revised, rewritten, and audited by darn near every member of the -doc team. Submitted by: Tom Rhodes PR: docs/35098
This commit is contained in:
Michael Lucas
parent
4215ca5392
commit
e4e67f3452
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=12384
1 changed files with 143 additions and 147 deletions
|
|
@ -376,6 +376,10 @@ host2.example.com link#1 UC 0 0
|
|||
between the two subnets, is often used when we need to implement
|
||||
packet filtering or firewall security in either or both
|
||||
directions.</para>
|
||||
|
||||
<para>If you want this machine to actually forward packets
|
||||
between the two interfaces, you need to tell FreeBSD to enable
|
||||
this ability.
|
||||
</sect2>
|
||||
|
||||
<sect2 id="dedicated-router">
|
||||
|
|
@ -646,6 +650,13 @@ host2.example.com link#1 UC 0 0
|
|||
|
||||
<sect1 id="nfs">
|
||||
<sect1info>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Tom</firstname>
|
||||
<surname>Rhodes</surname>
|
||||
<contrib>Reorganized and enhanced by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Bill</firstname>
|
||||
|
|
@ -658,44 +669,41 @@ host2.example.com link#1 UC 0 0
|
|||
|
||||
<indexterm><primary>NFS</primary></indexterm>
|
||||
<para>Among the many different file systems that FreeBSD supports is
|
||||
the Network File System or NFS. NFS allows you
|
||||
to share directories and files on one machine with others
|
||||
via the network they are attached to. Using NFS, users and
|
||||
programs can access files on remote systems as if they were local
|
||||
the Network File System, also known as <acronym>NFS</acronym>.
|
||||
<acronym>NFS</acronym> allows a system to share directories and files
|
||||
with others over a network. By using <acronym>NFS</acronym>, users and
|
||||
programs can access files on remote systems almost as if they were local
|
||||
files.</para>
|
||||
|
||||
<para>NFS has several benefits:</para>
|
||||
<para>Some of the most notable benefits that <acronym>NFS</acronym> can provide are:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Local workstations do not need as much disk space because
|
||||
<para>Local workstations use less disk space because
|
||||
commonly used data can be stored on a single machine and still
|
||||
remain accessible to everyone on the network.</para>
|
||||
remain accessible to others over the network.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>There is no need for users to have unique home directories
|
||||
on every machine on your network. Once they have an established
|
||||
directory that is available via NFS it can be accessed from
|
||||
anywhere.</para>
|
||||
<para>There is no need for users to have separate home directories
|
||||
on every network machine. Home directories could be setup on the
|
||||
<acronym>NFS</acronym> server and made available throughout the network.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Storage devices such as floppies and CDROM drives can be
|
||||
used by other machines on the network eliminating the need for
|
||||
extra hardware.</para>
|
||||
<para>Storage devices such as floppy disks, CDROM drives, and ZIP drives
|
||||
can be used by other machines on the network. This may reduce the number
|
||||
of removable media drives throughout the network.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<sect2>
|
||||
<title>How It Works</title>
|
||||
<title>How <acronym>NFS</acronym> Works</title>
|
||||
|
||||
<para>NFS is composed of two sides – a client side and a
|
||||
server side. Think of it as a want/have relationship. The client
|
||||
<emphasis>wants</emphasis> the data that the server side
|
||||
<emphasis>has</emphasis>. The server shares its data with the
|
||||
client. In order for this system to function properly a few
|
||||
processes have to be configured and running.</para>
|
||||
<para><acronym>NFS</acronym> consists of at least two main parts: a server
|
||||
and one or more clients. The client remotely accesses the data that is stored
|
||||
on the server machine. In order for this to function properly a few
|
||||
processes have to be configured and running:</para>
|
||||
|
||||
<para>The server has to be running the following daemons:</para>
|
||||
<indexterm>
|
||||
|
|
@ -723,141 +731,129 @@ host2.example.com link#1 UC 0 0
|
|||
<tbody>
|
||||
<row>
|
||||
<entry>nfsd</entry>
|
||||
<entry>The NFS Daemon which services requests from NFS
|
||||
clients.</entry>
|
||||
<entry>The <acronym>NFS</acronym> daemon which services requests from
|
||||
the <acronym>NFS</acronym> clients.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>mountd</entry>
|
||||
<entry>The NFS Mount Daemon which actually carries out
|
||||
requests that &man.nfsd.8; passes on to it.</entry>
|
||||
<entry>The <acronym>NFS</acronym> mount daemon which carries out
|
||||
the requests that &man.nfsd.8; passes on to it.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>portmap</entry>
|
||||
<entry> The <command>portmapper</command> daemon which
|
||||
allows NFS clients to find out which port the NFS server
|
||||
is using.</entry>
|
||||
<entry> The portmapper daemon
|
||||
allows <acronym>NFS</acronym> clients to discover which port the <acronym>NFS</acronym> server
|
||||
is using.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>The client side only needs to run a single daemon:</para>
|
||||
<indexterm>
|
||||
<primary>NFS</primary>
|
||||
<secondary>client</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary><application>nfsiod</application></primary>
|
||||
</indexterm>
|
||||
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="2">
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>nfsiod</entry>
|
||||
<entry>The NFS async I/O Daemon which services requests
|
||||
from its NFS server.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
<para>The client can also run a daemon, known as
|
||||
<application>nfsiod</application>. The <application>nfsiod</application>
|
||||
daemon services the requests from the <acronym>NFS</acronym> server. This
|
||||
is optional, and improves performance, but is not required for normal
|
||||
and correct operation. See the &man.nfsiod.8; manual page for more information.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="configuring-nfs">
|
||||
<title>Configuring NFS</title>
|
||||
<title>Configuring <acronym>NFS</acronym></title>
|
||||
<indexterm>
|
||||
<primary>NFS</primary>
|
||||
<secondary>configuration</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>Luckily for us, on a FreeBSD system this setup is a snap. The
|
||||
processes that need to be running can all be run at boot time with
|
||||
<para><acronym>NFS</acronym> configuration is a relatively straightforward
|
||||
process. The processes that need to be running can all start at boot time with
|
||||
a few modifications to your <filename>/etc/rc.conf</filename>
|
||||
file.</para>
|
||||
file.</para>
|
||||
|
||||
<para>On the NFS server make sure you have:</para>
|
||||
<para>On the <acronym>NFS</acronym> server, make sure that the following options
|
||||
are configured in the <filename>/etc/rc.conf</filename> file:</para>
|
||||
|
||||
<programlisting>portmap_enable="YES"
|
||||
nfs_server_enable="YES"
|
||||
nfs_server_flags="-u -t -n 4"
|
||||
mountd_flags="-r"</programlisting>
|
||||
|
||||
<para><command>mountd</command> is automatically run whenever the
|
||||
NFS server is enabled. The <option>-u</option> and
|
||||
<option>-t</option> flags to <command>nfsd</command> tell it to
|
||||
serve UDP and TCP clients. The <option>-n 4</option> flag tells
|
||||
<command>nfsd</command> to start 4 copies of itself.</para>
|
||||
<para><command>mountd</command> runs automatically whenever the
|
||||
<acronym>NFS</acronym> server is enabled.</para>
|
||||
|
||||
<para>On the client, make sure you have:</para>
|
||||
<para>On the client, make sure this option is present in
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<programlisting>nfs_client_enable="YES"
|
||||
nfs_client_flags="-n 4"</programlisting>
|
||||
<programlisting>nfs_client_enable="YES"</programlisting>
|
||||
|
||||
<para>Like <command>nfsd</command>, the <option>-n 4</option> tells
|
||||
<command>nfsiod</command> to start 4 copies of itself.</para>
|
||||
|
||||
<para>The last configuration step requires that you create a file
|
||||
called <filename>/etc/exports</filename>. The exports file
|
||||
specifies which file systems on your server will be shared
|
||||
(a.k.a., <quote>exported</quote>) and with what clients they will
|
||||
be shared. Each line in the file specifies a file system to be
|
||||
shared. There are a handful of options that can be used in this
|
||||
file but only a few will be mentioned here. You can find out
|
||||
about the rest in the &man.exports.5; manual page.</para>
|
||||
<para>
|
||||
The <filename>/etc/exports</filename>
|
||||
file specifies which filesystems <acronym>NFS</acronym> should export (sometimes
|
||||
referred to as <quote>share</quote>).
|
||||
Each line in <filename>/etc/exports</filename> specifies a filesystem to be exported and
|
||||
which machines have access to that filesystem. Along with what machines have access
|
||||
to that filesystem, access options may also be specified. There are many such options
|
||||
that can be used in this file but only a few will be mentioned here. You can easily discover
|
||||
other options by reading over the &man.exports.5; manual page.</para>
|
||||
|
||||
<para>Here are a few example <filename>/etc/exports</filename>
|
||||
entries:</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>NFS</primary>
|
||||
<secondary>exporting filesystems</secondary>
|
||||
<secondary>Examples of exporting filesystems</secondary>
|
||||
</indexterm>
|
||||
<para>The following line exports <filename>/cdrom</filename> to
|
||||
three silly machines that have the same domain name as the server
|
||||
|
||||
<para>The following examples give an idea of how to export filesystems,
|
||||
although the settings may be different depending on
|
||||
your environment and network configuration.
|
||||
For instance, to export the <filename>/cdrom</filename> directory to
|
||||
three example machines that have the same domain name as the server
|
||||
(hence the lack of a domain name for each) or have entries in your
|
||||
<filename>/etc/hosts</filename> file. The <option>-ro</option>
|
||||
flag makes the shared file system read-only. With this flag, the
|
||||
remote system will not be able to make any changes to the
|
||||
shared file system.</para>
|
||||
flag makes the exported file system read-only. With this flag, the
|
||||
remote system will not be able to write any changes to the
|
||||
exported file system.</para>
|
||||
|
||||
<programlisting>/cdrom -ro moe larry curly</programlisting>
|
||||
<programlisting>/cdrom -ro host1 host2 host3</programlisting>
|
||||
|
||||
<para>The following line exports <filename>/home</filename> to three
|
||||
hosts by IP address. This is a useful setup if you have a
|
||||
private network but do not have DNS running. The
|
||||
<option>-alldirs</option> flag allows all the directories below
|
||||
the specified file system to be exported as well.</para>
|
||||
private network without a <acronym>DNS</acronym> server configured.
|
||||
Optionally the <filename>/etc/hosts</filename> file could be configured
|
||||
for internal hostnames; please review &man.hosts.5; for more
|
||||
information. The <option>-alldirs</option> flag allows the subdirectories
|
||||
to be mount points. In other words, it will not mount the subdirectories
|
||||
but permit the client to mount only the directories that are required or
|
||||
needed.</para>
|
||||
|
||||
<programlisting>/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4</programlisting>
|
||||
|
||||
<para>The following line exports <filename>/a</filename> to two
|
||||
machines that have different domain names than the server. The
|
||||
<option>-maproot=0</option> flag allows
|
||||
the root user on the remote system to write to the shared
|
||||
file system as root. Without the -maproot=0 flag even if
|
||||
someone has root access on the remote system they will not
|
||||
be able to modify files on the shared file system.</para>
|
||||
<para>The following line exports <filename>/a</filename> so that two
|
||||
clients from different domains may access the filesystem. The
|
||||
<option>-maproot=root</option> flag allows the <username>root</username>
|
||||
user on the remote system to write data on the exported filesystem as
|
||||
<username>root</username>. If the -maproot=root flag is not specified, then even if
|
||||
a user has <username>root</username> access on the remote system, they will not
|
||||
be able to modify files on the exported filesystem.</para>
|
||||
|
||||
<programlisting>/a -maproot=0 host.domain.com box.example.com</programlisting>
|
||||
<programlisting>/a -maproot=root host.example.com box.example.org</programlisting>
|
||||
|
||||
<para>In order for a client to access- an exported file system it must
|
||||
have permission to do so. Make sure your client is listed in your
|
||||
<para>In order for a client to access an exported filesystem, the client must
|
||||
have permission to do so. Make sure the client is listed in your
|
||||
<filename>/etc/exports</filename> file.</para>
|
||||
|
||||
<para>In <filename>/etc/exports</filename>, each line represents
|
||||
the export information for one filesystem to one host. A
|
||||
remote host can only be specified once for each local
|
||||
filesystem, and you can only have one default entry per local
|
||||
filesystem. For example, let's assume that
|
||||
<filename>/usr</filename> is a single filesystem. The
|
||||
following <filename>/etc/exports</filename> is invalid:</para>
|
||||
remote host can only be specified once per filesystem, and may only
|
||||
have one default entry. For example, assume that <filename>/usr</filename>
|
||||
is a single filesystem. The following <filename>/etc/exports</filename>
|
||||
would be valid:</para>
|
||||
|
||||
<programlisting>/usr/src client
|
||||
/usr/ports client</programlisting>
|
||||
|
||||
<para>One filesystem, <filename>/usr</filename>, has two lines
|
||||
specifying its exports to the same host,
|
||||
<hostid>client</hostid>. The correct format is:</para>
|
||||
specifying exports to the same host, <hostid>client</hostid>.
|
||||
The correct format for this situation is:</para>
|
||||
|
||||
<programlisting>/usr/src /usr/ports client</programlisting>
|
||||
|
||||
|
|
@ -872,42 +868,43 @@ nfs_client_flags="-n 4"</programlisting>
|
|||
|
||||
<programlisting># Export src and ports to client01 and client02, but only
|
||||
# client01 has root privileges on it
|
||||
/usr/src /usr/ports -maproot=0 client01
|
||||
/usr/src /usr/ports -maproot=root client01
|
||||
/usr/src /usr/ports client02
|
||||
# The "client" machines have root and can mount anywhere
|
||||
# up /exports. Anyone inhe world can mount /exports/obj read-only
|
||||
/exports -alldirs -maproot=0 client01 client02
|
||||
# The client machines have root and can mount anywhere
|
||||
# on /exports. Anyone in the world can mount /exports/obj read-only
|
||||
/exports -alldirs -maproot=root client01 client02
|
||||
/exports/obj -ro</programlisting>
|
||||
|
||||
<para>You must restart
|
||||
<command>mountd</command> whenever you modify
|
||||
<filename>/etc/exports</filename> to make changes take
|
||||
effect. This can be accomplished by sending the hangup signal
|
||||
<filename>/etc/exports</filename> so the changes can take effect.
|
||||
This can be accomplished by sending the hangup signal
|
||||
to the <command>mountd</command> process:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>kill -HUP `cat /var/run/mountd.pid`</userinput></screen>
|
||||
|
||||
<para>Now that you have made all these changes you can just reboot
|
||||
and let FreeBSD start everything for you at boot time, or you can
|
||||
run the following commands as root:</para>
|
||||
<para>Alternatively, a reboot will make FreeBSD set everything
|
||||
up properly. A reboot is not necessary though.
|
||||
Executing the following commands as <username>root</username>
|
||||
should start everything up.</para>
|
||||
|
||||
<para>On the NFS server:</para>
|
||||
<para>On the <acronym>NFS</acronym> server:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>portmap</userinput>
|
||||
&prompt.root; <userinput>nfsd -u -t -n 4</userinput>
|
||||
&prompt.root; <userinput>mountd -r</userinput></screen>
|
||||
|
||||
<para>On the NFS client:</para>
|
||||
<para>On the <acronym>NFS</acronym> client:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>nfsiod -n 4</userinput></screen>
|
||||
|
||||
<para>Now you should be ready to actually mount a remote file
|
||||
system. This can be done one of two ways. In these examples the
|
||||
<para>Now everything should be ready to actually mount a remote file
|
||||
system. In these examples the
|
||||
server's name will be <literal>server</literal> and the client's
|
||||
name will be <literal>client</literal>. If you just want to
|
||||
temporarily mount a remote file system or just want to test out
|
||||
your configuration you can run a command like this as root on the
|
||||
client:</para>
|
||||
name will be <literal>client</literal>. If you only want to
|
||||
temporarily mount a remote file system or would rather test the
|
||||
configuration, just execute a command like this as <username>root</username> on the
|
||||
client:</para>
|
||||
<indexterm>
|
||||
<primary>NFS</primary>
|
||||
<secondary>mounting filesystems</secondary>
|
||||
|
|
@ -916,56 +913,54 @@ nfs_client_flags="-n 4"</programlisting>
|
|||
|
||||
<para>This will mount the <filename>/home</filename> directory
|
||||
on the server at <filename>/mnt</filename> on the client. If
|
||||
everything is setup correctly you should be able to go into
|
||||
/mnt on the client and see all the files that are on the
|
||||
server.</para>
|
||||
everything is set up correctly you should be able to enter
|
||||
<filename>/mnt</filename> on the client and see all the files
|
||||
that are on the server.</para>
|
||||
|
||||
<para>If you want to automatically mount a remote file system
|
||||
each time the computer boots, add the filesystem to
|
||||
<filename>/etc/fstab</filename>. Here is an example:</para>
|
||||
<para>If you want to automatically mount a remote filesystem
|
||||
each time the computer boots, add the filesystem to the
|
||||
<filename>/etc/fstab</filename> file. Here is an example:</para>
|
||||
|
||||
<programlisting>server:/home /mnt nfs rw 0 0</programlisting>
|
||||
|
||||
<para>Read the &man.fstab.5; manual page for more options.</para>
|
||||
<para>The &man.fstab.5; manual page lists all the available options.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Practical Uses</title>
|
||||
|
||||
<para>There are many very cool uses for NFS. Some of the more common
|
||||
ones are listed below.</para>
|
||||
<para><acronym>NFS</acronym> has many practical uses. Some of the more common
|
||||
ones are listed below:</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>NFS</primary>
|
||||
<secondary>uses</secondary>
|
||||
</indexterm>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Have several machines on a network and share a CDROM or
|
||||
floppy drive among them. This is cheaper and often more
|
||||
convenient.</para>
|
||||
<para>Set several machines to share a CDROM or
|
||||
other media among them. This is cheaper and often
|
||||
a more convenient method to install software on multiple machines.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>With so many machines on a network, it gets old having your
|
||||
personal files strewn all over the place. You can have a
|
||||
central NFS server that houses all user home directories and
|
||||
shares them with the rest of the machines on the LAN, so no
|
||||
matter where you log in you will have the same home
|
||||
directory.</para>
|
||||
<para>On large networks, it might be more convenient to configure a
|
||||
central <acronym>NFS</acronym> server in which to store all the user
|
||||
home directories. These home directories can then be exported to
|
||||
the network so that users would always have the same home directory,
|
||||
regardless of which workstation they log in to.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>When you get to reinstalling FreeBSD on one of your
|
||||
machines, NFS is the way to go! Just pop your distribution
|
||||
CDROM into your file server and away you go!</para>
|
||||
<para>You can use an exported CDROM to install
|
||||
software on multiple machines.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Have a common <filename>/usr/ports/distfiles</filename>
|
||||
directory that all your machines share. That way, when you go
|
||||
to install a port that you have already installed on a different
|
||||
machine, you do not have to download the source all over
|
||||
again!</para>
|
||||
<para>Several machines could have a common
|
||||
<filename>/usr/ports/distfiles</filename> directory.
|
||||
That way, when you need to install a port on several machines, you can
|
||||
quickly access the source without downloading it on each machine.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
|
@ -992,14 +987,15 @@ nfs_client_flags="-n 4"</programlisting>
|
|||
<indexterm><primary>amd</primary></indexterm>
|
||||
<indexterm><primary>automatic mounter daemon</primary></indexterm>
|
||||
|
||||
<para>&man.amd.8;, which is also known as the automatic mounter
|
||||
daemon, is a useful utility used for automatically mounting a
|
||||
<para>&man.amd.8; (the automatic mounter daemon)
|
||||
is a useful daemon that automatically mounts a
|
||||
remote filesystem whenever a file or directory within that
|
||||
filesystem is accessed. Filesystems that are inactive for a
|
||||
period of time will also be automatically unmounted by
|
||||
<application>amd</application>. Using
|
||||
<application>amd</application> provides a simplistic alternative
|
||||
to static mounts.</para>
|
||||
<application>amd</application> provides a simple alternative
|
||||
to permanent mounts, as permanent mounts should be listed in the
|
||||
<filename>/etc/fstab</filename>.</para>
|
||||
|
||||
<para><application>amd</application> operates by attaching
|
||||
itself as an NFS server to the <filename>/host</filename> and
|
||||
|
|
|
|||
Loading…
Reference in a new issue