The mount
command mounts NFS shares on the client side. Its format is as follows:
# mount -t nfs -o options host:/remote/export /local/directory
This command uses the following variables:
options
A comma-delimited list of mount options;
The hostname, IP address, or fully
qualified domain name of the server exporting the file system you wish to mount
/remote/export
The file system or directory being
exported from the server,
that is, the directory you wish to mount
/local/directory
The client location where /remote/export is mounted
The NFS protocol version used in Red Hat Enterprise Linux 6
is identified by the mount
options nfsvers or vers. By default, mount will use NFSv4 with mount -t nfs. If the server does not
support NFSv4, the client will automatically step down to a version supported
by the server. If the nfsvers/vers option is used to pass a particular
version not supported by the server, the mount will fail. The file system type
nfs4 is also available for legacy reasons; this is equivalent to running mount -t nfs -o nfsvers=4 host:/remote/export
/local/directory.
Refer to man mount
for more details.
If an NFS share was mounted manually, the share will not be
automatically mounted upon reboot. Red Hat Enterprise Linux offers two methods
for mounting remote file systems automatically at boot time: the /etc/fstab file and the autofs service.
Mounting NFS File Systems using /etc/fstab
An alternate way to mount an NFS share from another machine
is to add a line to the /etc/fstab
file. The line must state the hostname of the NFS server, the directory on the
server being exported, and the directory on the local machine where the NFS
share is to be mounted. You must be root to modify the /etc/fstab file.
Example Syntax example
The general syntax for the line in /etc/fstab is as follows:
server:/usr/local/pub /pub nfs defaults 0 0
The mount point /pub
must exist on the client machine before this command can be executed. After
adding this line to /etc/fstab
on the client system, use the command mount
/pub, and the mount point /pub
is mounted from the server.
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 valid /etc/fstab
entry to mount an NFS export should contain the following information:
server:/remote/export /local/directory nfs options 0 0
The variables server,
/remote/export, /local/directory, and options are the same ones used when
manually mounting an NFS share
autofs
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 many systems at one time, overall system performance can
be affected. An alternative to /etc/fstab
is to use the kernel-based automount
utility. An automounter consists of two components:
- a kernel module that
implements a file system, and
- a user-space daemon that
performs all of the other functions.
The automount
utility can mount and unmount NFS file systems automatically (on-demand
mounting), therefore saving system resources. It can be used to mount other
file systems including AFS, SMBFS, CIFS, and local file systems.
Important
The nfs-utils package is now a part of both the 'NFS file
server' and the 'Network File System Client' groups. As such, it is no longer
installed by default with the Base group. Ensure that nfs-utils is installed on
the system first before attempting to automount an NFS share.
autofs is also part of the 'Network File System Client'
group.
autofs
uses /etc/auto.master
(master map) as its default primary configuration file. This can be changed to
use another supported network source and name using the autofs configuration (in /etc/sysconfig/autofs) in conjunction
with the Name Service Switch (NSS) mechanism. An instance of the autofs version 4 daemon was run for each
mount point configured in the master map and so it could be run manually from
the command line for any given mount point. This is not possible with autofs version 5, because it uses a
single daemon to manage all configured mount points; as such, all automounts
must be configured in the master map. This is in line with the usual
requirements of other industry standard automounters. Mount point, hostname,
exported directory, and options can all be specified in a set of files (or
other supported network sources) rather than configuring them manually for each
host.
Improvements in autofs Version 5 over Version 4
autofs
version 5 features the following enhancements over version 4:
Direct map support
Direct maps in autofs provide a mechanism to
automatically mount file systems at arbitrary points in the file system
hierarchy. A direct map is denoted by a mount point of /- in the master map. Entries in a
direct map contain an absolute path name as a key (instead of the relative path
names used in indirect maps).
Lazy mount and unmount support
Multi-mount map entries describe a
hierarchy of mount points under a single key. A good example of this is the -hosts map, commonly used for
automounting all exports from a host under /net/host
as a multi-mount map entry. When using the -hosts
map, an ls of /net/host will mount autofs
trigger mounts for each export from host.
These will then mount and expire them as they are accessed. This can greatly
reduce the number of active mounts needed when accessing a server with a large
number of exports.
Enhanced LDAP support
The autofs configuration file (/etc/sysconfig/autofs) provides a mechanism to specify
the autofs schema that a
site implements, thus precluding the need to determine this via trial and error
in the application itself. In addition, authenticated binds to the LDAP server
are now supported, using most mechanisms supported by the common LDAP server
implementations. A new configuration file has been added for this support: /etc/autofs_ldap_auth.conf. The default
configuration file is self-documenting, and uses an XML format.
Proper use of the Name Service Switch (nsswitch)
configuration.
The Name Service Switch
configuration file exists to provide a means of determining from where specific
configuration data comes. The reason for this configuration is to allow
administrators the flexibility of using the back-end database of choice, while
maintaining a uniform software interface to access the data. While the version
4 automounter is becoming increasingly better at handling the NSS
configuration, it is still not complete. Autofs version 5, on the other hand,
is a complete implementation.
Refer to man nsswitch.conf for more information
on the supported syntax of this file. Not all NSS databases are valid map
sources and the parser will reject ones that are invalid. Valid sources are
files, yp, nis,
nisplus, ldap, and hesiod.
Multiple master map entries per autofs
mount point
One thing that is frequently used
but not yet mentioned is the handling of multiple master map entries for the
direct mount point /-. The
map keys for each entry are merged and behave as one map.
Example Multiple master
map entries per autofs mount point
An example is seen in the
connectathon test maps for the direct mounts below:
/- /tmp/auto_dcthon
/- /tmp/auto_test3_direct
/- /tmp/auto_test4_direct
autofs Configuration
The primary configuration file for the automounter is /etc/auto.master, The master map lists autofs-controlled mount points on the
system, and their corresponding configuration files or network sources known as
automount maps. The format of the master map is as follows:
mount-point map-name options
The variables used in this format are:
mount-point
The autofs mount point, /home,
for example.
map-name
The name of a map source which
contains a list of mount points, and the file system location from which those
mount points should be mounted. The syntax for a map entry is described below.
options
If supplied, these will apply to
all entries in the given map provided they don't themselves have options
specified. This behavior is different from autofs
version 4 where options were cumulative. This has been changed to implement
mixed environment compatibility.
Example /etc/auto.master file
The following is a sample line from /etc/auto.master file (displayed with cat /etc/auto.master):
/home /etc/auto.misc
The general format of maps is similar to the master map,
however the "options" appear between the mount point and the location
instead of at the end of the entry as in the master map:
mount-point [options] location
The variables used in this format are:
mount-point
This refers to the autofs mount point. This can be a single
directory name for an indirect mount or the full path of the mount point for
direct mounts. Each direct and indirect map entry key (mount-point above) may be followed
by a space separated list of offset directories (sub directory names each
beginning with a "/") making them what is known as a multi-mount
entry.
options
Whenever supplied, these are the
mount options for the map entries that do not specify their own options.
location
This refers to the file system
location such as a local file system path (preceded with the Sun map format
escape character ":" for map names beginning with "/"), an
NFS file system or other valid file system location.
The following is a sample of contents from a map file (for
example, /etc/auto.misc):
payroll -fstype=nfs personnel:/dev/hda3
sales -fstype=ext3 :/dev/hda4
The first column in a map file indicates the autofs mount point (sales and payroll from the server called personnel). The second column indicates
the options for the autofs
mount while the third column indicates the source of the mount. Following the
above configuration, the autofs mount points will be /home/payroll and /home/sales. The -fstype= option is often omitted and is
generally not needed for correct operation.
The automounter will create the directories if they do not
exist. If the directories exist before the automounter was started, the
automounter will not remove them when it exits. You can start or restart the
automount daemon by issuing either of the following two commands:
service autofs start (if the automount daemon has
stopped) service autofs restart
Using the above configuration, if a process requires access
to an autofs unmounted
directory such as /home/payroll/2006/July.sxc,
the automount daemon automatically mounts the directory. If a timeout is
specified, the directory will automatically be unmounted if the directory is
not accessed for the timeout period.
You can view the status of the automount daemon by issuing
the following command:
# service autofs status
Overriding or Augmenting Site Configuration Files
It can be useful to override site defaults for a specific
mount point on a client system. For example, consider the following conditions:
- Automounter maps are stored
in NIS and
the
/etc/nsswitch.conf
file has the following directive:
automount: files nis
- The
auto.master file contains the
following
+auto.master
- The NIS
auto.master
map file contains the following:
/home auto.home
- The NIS
auto.home
map contains the following:
· beth fileserver.example.com:/export/home/beth
· joe fileserver.example.com:/export/home/joe
* fileserver.example.com:/export/home/&
- The file map
/etc/auto.home does not exist.
Given these conditions, let's assume that the client system
needs to override the NIS
map auto.home and mount home
directories from a different server. In this case, the client will need to use
the following /etc/auto.master
map:
/home /etc/auto.home
+auto.master
The /etc/auto.home
map contains the entry:
* labserver.example.com:/export/home/&
Because the automounter only processes the first occurrence
of a mount point, /home will
contain the contents of /etc/auto.home
instead of the NIS
auto.home map.
Alternatively, to augment the site-wide auto.home map with just a few entries,
create an /etc/auto.home
file map, and in it put the new entries. At the end, include the NIS auto.home map. Then the /etc/auto.home file map will look
similar to:
mydir someserver:/export/mydir
+auto.home
Given the NIS
auto.home map listed above, ls /home would now output:
beth joe mydir
This last example works as expected because autofs does not include the contents of
a file map of the same name as the one it is reading. As such, autofs moves on to the next map source
in the nsswitch
configuration.
Using LDAP to Store Automounter Maps
LDAP client libraries must be installed on all systems
configured to retrieve automounter maps from LDAP. On Red Hat Enterprise Linux,
the openldap package should
be installed automatically as a dependency of the automounter. To configure LDAP access, modify /etc/openldap/ldap.conf. Ensure that
BASE, URI, and schema are set appropriately for your site.
The most recently established schema for storing automount
maps in LDAP is described by rfc2307bis.
To use this schema it is necessary to set it in the autofs configuration (/etc/sysconfig/autofs) by removing the
comment characters from the schema definition. For example:
Example Setting autofs configuration
DEFAULT_MAP_OBJECT_CLASS="automountMap"
DEFAULT_ENTRY_OBJECT_CLASS="automount"
DEFAULT_MAP_ATTRIBUTE="automountMapName"
DEFAULT_ENTRY_ATTRIBUTE="automountKey"
DEFAULT_VALUE_ATTRIBUTE="automountInformation"
Ensure that these are the only schema entries not commented
in the configuration. The automountKey
replaces the cn attribute in
the rfc2307bis schema. An LDIF of a sample configuration is
described below:
Example LDF configuration
# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (&(objectclass=automountMap)(automountMapName=auto.master))
# requesting: ALL
#
# auto.master, example.com
dn: automountMapName=auto.master,dc=example,dc=com
objectClass: top
objectClass: automountMap
automountMapName: auto.master
# extended LDIF
#
# LDAPv3
# base <automountMapName=auto.master,dc=example,dc=com> with scope subtree
# filter: (objectclass=automount)
# requesting: ALL
#
# /home, auto.master, example.com
dn: automountMapName=auto.master,dc=example,dc=com
objectClass: automount
cn: /home
automountKey: /home
automountInformation: auto.home
# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (&(objectclass=automountMap)(automountMapName=auto.home))
# requesting: ALL
#
# auto.home, example.com
dn: automountMapName=auto.home,dc=example,dc=com
objectClass: automountMap
automountMapName: auto.home
# extended LDIF
#
# LDAPv3
# base <automountMapName=auto.home,dc=example,dc=com> with scope subtree
# filter: (objectclass=automount)
# requesting: ALL
#
# foo, auto.home, example.com
dn: automountKey=foo,automountMapName=auto.home,dc=example,dc=com
objectClass: automount
automountKey: foo
automountInformation: filer.example.com:/export/foo
# /, auto.home, example.com
dn: automountKey=/,automountMapName=auto.home,dc=example,dc=com
objectClass: automount
automountKey: /
automountInformation: filer.example.com:/export/&
Common NFS Mount
Options
Beyond mounting a file system with NFS on a remote host, it
is also possible to specify other options at mount time to make the mounted
share 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:
intr
Allows NFS requests to be
interrupted if the server goes down or cannot be reached.
lookupcache=mode
Specifies how the kernel should
manage its cache of directory entries for a given mount point. Valid arguments
for mode are all, none,
or pos/positive.
nfsvers=version
Specifies which version of the NFS
protocol to use, where version
is 2, 3, or 4. This is useful for hosts that run multiple NFS servers. If no
version is specified, NFS uses the highest version supported by the kernel and mount command.
The option vers is identical to nfsvers, and is included in this release
for compatibility reasons.
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 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
port=num
— Specifies the numeric value of the NFS server port. If num is 0 (the default), then mount
queries the remote host's rpcbind
service for the port number to use. If the remote host's NFS daemon is not
registered with its rpcbind
service, 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 (num,
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. Its default setting is sec=sys, which uses local UNIX UIDs and
GIDs by using 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 involves the most performance overhead.
tcp
Instructs the NFS mount to use the
TCP protocol.
udp
Instructs the NFS mount to use the
UDP protocol.
For a complete list of options and more detailed information
on each one, refer to man mount
and man nfs.
Starting and Stopping NFS
To run an NFS server, the rpcbind
service must be running. To verify that rpcbind is active, use the following command:
# service rpcbind status
If the rpcbind
service is running, then the nfs
service can be started. To start an NFS server, use the following command:
# service nfs start
nfslock
must also be started for both the NFS client and server to function properly.
To start NFS locking, use the following command:
# service nfslock start
If NFS is set to start at boot, ensure that nfslock also starts by running chkconfig --list nfslock. If nfslock is not set to on, this implies that you will need to
manually run the service nfslock start
each time the computer starts. To set nfslock
to automatically start on boot, use chkconfig
nfslock on.
nfslock
is only needed for NFSv2 and NFSv3.
To stop the server, use:
# service nfs stop
The restart
option is a shorthand way of stopping and then starting NFS. This is the most
efficient way to make configuration changes take effect after editing the
configuration file for NFS. To restart the server type:
# service nfs restart
The condrestart
(conditional restart) option only starts nfs if it is currently running. This option is useful for
scripts, because it does not start the daemon if it is not running. To
conditionally restart the server type:
# service nfs condrestart
To reload the NFS server configuration file without
restarting the service type:
# service nfs reload
