The /etc/fstab file is referenced by
the netfs service at boot time, so lines
referencing NFS shares have the same effect as manually typing the
mount command during the boot process.
A sample /etc/fstab line to mount an
NFS export looks like the following example:
<server>:</remote/export> </local/directory> <nfs-type> <options> 0 0
|
Replace <server> with the hostname, IP
address, or fully qualified domain name of the server exporting the
file system.
Replace </remote/export> with the path to
the exported directory.
Replace </local/directory> with the local
file system on which the exported directory is mounted. This mount
point must exist before /etc/fstab is
read or the mount fails.
Replace <nfs-type> with either nfs for NFSv2 or NFSv3 servers, or nfs4 for NFSv4 servers.
Replace <options> with a
comma separated list of options for the NFS file system (refer to
Section
9.4.3 Common NFS Mount Options for details). Refer to
the fstab man page for additional
information.
One drawback to using /etc/fstab is
that, regardless of how infrequently a user accesses the NFS
mounted file system, the system must dedicate resources to keep the
mounted file system in place. This is not a problem with one or two
mounts, but when the system is maintaining mounts to a dozen
systems at one time, overall system performance can suffer. An
alternative to /etc/fstab is to use the
kernel-based automount utility, which can
mount and unmount NFS file systems automatically, saving
resources.
The autofs service is used to control
the automount command through the
/etc/auto.master primary configuration
file. While automount can be specified on
the command line, it is more convenient to specify the mount
points, hostname, exported directory, and options in a set of files
rather than typing them manually.
The autofs configuration files are
arranged in a parent-child relationship. The main configuration
file (/etc/auto.master) lists mount
points on the system that are linked to a particular map type, which takes the form of other
configuration files, programs, NIS maps, and other less common
mount methods. The auto.master file
contains lines referring to each of these mount points, organized
in the following manner:
The <mount-point> element specifies the
location of the mount on the local file system. The <map-type>
specifies how the mount point is mounted. The most common method
for auto mounting NFS exports is to use a file as the map type for
the particular mount point. The map file is usually named
auto.<mount-point>, where <mount-point>
is the mount point designated in auto.master. A line within map files to mount an
NFS export looks like the following example:
</local/directory> -<options> <server>:</remote/export>
|
Replace </local/directory;> with the local
file system on which the exported directory is mounted. This mount
point must exist before the map file is read, else the mount
fails.
Replace <options> with a
comma separated list of options for the NFS file system (refer to
Section
9.4.3 Common NFS Mount Options for details). Be sure to
include the hyphen character (-)
immediately before the options list.
Replace <server> with the hostname, IP
address, or fully qualified domain name of the server exporting the
file system.
Replace </remote/export> with the path to
the exported directory.
Replace <options> with a
comma separated list of options for the NFS file system (refer to
Section
9.4.3 Common NFS Mount Options for details).
While autofs configuration files can be
used for a variety of mounts to many types of devices and file
systems, they are particularly useful in creating NFS mounts. For
example, some organizations store a user's /home/ directory on a central server via an NFS
share, then configure the auto.master
file on each of the workstations to point to an auto.home file containing the specifics for how to
mount the /home/ directory via NFS. This
allows the user to access personal data and configuration files in
their /home/ directory by logging in
anywhere on the network. The auto.master
file in this situation would look similar to this:
This sets up the /home/ mount point on
the local system to be configured by the /etc/auto.home file, which looks similar to the
example below:
* -fstype=nfs4,soft,intr,rsize=32768,wsize=32768,nosuid server.example.com:/home
|
This line states that any directory a user tries to access under
the local /home/ directory (due to the
asterisk character) should result in an NFS mount on the
server.example.com system on
the mount point /home/. The mount options
specify that each /home/ directory NFS
mounts should use a particular collection of settings. For more
information on mount options, including the ones used in this
example, refer to Section
9.4.3 Common NFS Mount Options.
For more information about the autofs
configuration files, refer to the auto.master man page.
Beyond mounting a file system via NFS on a remote host, other
options can be specified at the time of the mount to make it easier
to use. These options can be used with manual mount commands, /etc/fstab
settings, and autofs.
The following are options commonly used for NFS mounts:
-
fsid=num — Forces the file handle
and file attributes settings on the wire to be num, instead of a
number derived from the major and minor number of the block device
on the mounted file system. The value 0
has special meaning when used with NFSv4. NFSv4 has a concept of a
root of the overall exported file system. The export point exported
with fsid=0 is used as this root.
-
hard or soft
— Specifies whether the program using a file via an NFS
connection should stop and wait (hard) for
the server to come back online, if the host serving the exported
file system is unavailable, or if it should report an error
(soft).
If hard is specified, the user cannot
terminate the process waiting for the NFS communication to resume
unless the intr option is also
specified.
If soft is specified, the user can set
an additional timeo=<value> option, where <value>
specifies the number of seconds to pass before the error is
reported.
-
intr — Allows NFS requests to be
interrupted if the server goes down or cannot be reached.
-
nfsvers=2 or nfsvers=3 — Specifies which version of the NFS
protocol to use. This is useful for hosts that run multiple NFS
servers. If no version is specified, NFS uses the highest supported
version by the kernel and mount command.
This option is not supported with NFSv4 and should not be used.
-
noacl — Turns off all ACL
processing. This may be needed when interfacing with older versions
of Red Hat Enterprise Linux, Red Hat Linux, or Solaris, since the
most recent ACL technology is not compatible with older
systems.
-
nolock — Disables file locking.
This setting is occasionally required when connecting to older NFS
servers.
-
noexec — Prevents execution of
binaries on mounted file systems. This is useful if the system is
mounting a non-Linux file system via NFS containing incompatible
binaries.
-
nosuid — Disables
set-user-identifier or set-group-identifier bits. This prevents
remote users from gaining higher privileges by running a setuid
program.
-
port=num — Specifies the numeric
value of the NFS server port. If num is 0 (the
default), then mount queries the remote
host's portmapper for the port number to use. If the remote host's
NFS daemon is not registered with its portmapper, the standard NFS
port number of TCP 2049 is used instead.
-
rsize=num and wsize=num — These settings speed up NFS
communication for reads (rsize) and writes
(wsize) by setting a larger data block
size, in bytes, to be transferred at one time. Be careful when
changing these values; some older Linux kernels and network cards
do not work well with larger block sizes. For NFSv2 or NFSv3, the
default values for both parameters is set to 8192. For NFSv4, the
default values for both parameters is set to 32768.
-
sec=mode — Specifies the type of
security to utilize when authenticating an NFS connection.
sec=sys is the default setting, which
uses local UNIX UIDs and GIDs by means of AUTH_SYS to authenticate
NFS operations.
sec=krb5 uses Kerberos V5 instead of
local UNIX UIDs and GIDs to authenticate users.
sec=krb5i uses Kerberos V5 for user
authentication and performs integrity checking of NFS operations
using secure checksums to prevent data tampering.
sec=krb5p uses Kerberos V5 for user
authentication, integrity checking, and encrypts NFS traffic to
prevent traffic sniffing. This is the most secure setting, but it
also has the most performance overhead involved.
-
tcp — Specifies for the NFS mount
to use the TCP protocol.
-
udp — Specifies for the NFS mount
to use the UDP protocol.
Many more options are listed on the mount and nfs man
pages.
