Chapter 23. Mounting NFS shares
As a system administrator, you can mount remote NFS shares on your system to access shared data.
23.1. Introduction to NFS
This section explains the basic concepts of the NFS service.
A Network File System (NFS) allows remote hosts to mount file systems over a network and interact with those file systems as though they are mounted locally. This enables you to consolidate resources onto centralized servers on the network.
The NFS server refers to the
/etc/exports configuration file to determine whether the client is allowed to access any exported file systems. Once verified, all file and directory operations are available to the user.
23.2. Supported NFS versions
This section lists versions of NFS supported in Red Hat Enterprise Linux and their features.
Currently, Red Hat Enterprise Linux 8 supports the following major versions of NFS:
- NFS version 3 (NFSv3) supports safe asynchronous writes and is more robust at error handling than the previous NFSv2; it also supports 64-bit file sizes and offsets, allowing clients to access more than 2 GB of file data.
NFS version 4 (NFSv4) works through firewalls and on the Internet, no longer requires an
rpcbindservice, supports Access Control Lists (ACLs), and utilizes stateful operations.
NFS version 2 (NFSv2) is no longer supported by Red Hat.
Default NFS version
The default NFS version in Red Hat Enterprise Linux 8 is 4.2. NFS clients attempt to mount using NFSv4.2 by default, and fall back to NFSv4.1 when the server does not support NFSv4.2. The mount later falls back to NFSv4.0 and then to NFSv3.
Features of minor NFS versions
Following are the features of NFSv4.2 in Red Hat Enterprise Linux 8:
- Server-side copy
Enables the NFS client to efficiently copy data without wasting network resources using the
- Sparse files
Enables files to have one or more holes, which are unallocated or uninitialized data blocks consisting only of zeroes. The
lseek()operation in NFSv4.2 supports
seek_data(), which enables applications to map out the location of holes in the sparse file.
- Space reservation
Permits storage servers to reserve free space, which prohibits servers to run out of space. NFSv4.2 supports the
allocate()operation to reserve space, the
deallocate()operation to unreserve space, and the
fallocate()operation to preallocate or deallocate space in a file.
- Labeled NFS
- Enforces data access rights and enables SELinux labels between a client and a server for individual files on an NFS file system.
- Layout enhancements
layoutstats()operation, which enables some Parallel NFS (pNFS) servers to collect better performance statistics.
Following are the features of NFSv4.1:
- Enhances performance and security of network, and also includes client-side support for pNFS.
- No longer requires a separate TCP connection for callbacks, which allows an NFS server to grant delegations even when it cannot contact the client: for example, when NAT or a firewall interferes.
- Provides exactly once semantics (except for reboot operations), preventing a previous issue whereby certain operations sometimes returned an inaccurate result if a reply was lost and the operation was sent twice.
23.3. Services required by NFS
This section lists system services that are required for running an NFS server or mounting NFS shares. Red Hat Enterprise Linux starts these services automatically.
Red Hat Enterprise Linux uses a combination of kernel-level support and service processes to provide NFS file sharing. All NFS versions rely on Remote Procedure Calls (RPC) between clients and servers. To share or mount NFS file systems, the following services work together depending on which version of NFS is implemented:
- The NFS server kernel module that services requests for shared NFS file systems.
Accepts port reservations from local RPC services. These ports are then made available (or advertised) so the corresponding remote RPC services can access them. The
rpcbindservice responds to requests for RPC services and sets up connections to the requested RPC service. This is not used with NFSv4.
This process is used by an NFS server to process
MOUNTrequests from NFSv3 clients. It checks that the requested NFS share is currently exported by the NFS server, and that the client is allowed to access it. If the mount request is allowed, the
nfs-mountdservice replies with a Success status and provides the File-Handle for this NFS share back to the NFS client.
This process enables explicit NFS versions and protocols the server advertises to be defined. It works with the Linux kernel to meet the dynamic demands of NFS clients, such as providing server threads each time an NFS client connects. This process corresponds to the
- This is a kernel thread that runs on both clients and servers. It implements the Network Lock Manager (NLM) protocol, which enables NFSv3 clients to lock files on the server. It is started automatically whenever the NFS server is run and whenever an NFS file system is mounted.
This process implements the Network Status Monitor (NSM) RPC protocol, which notifies NFS clients when an NFS server is restarted without being gracefully brought down. The
rpc-statdservice is started automatically by the
nfs-serverservice, and does not require user configuration. This is not used with NFSv4.
This process provides user quota information for remote users. The
rpc-rquotadservice, which is provided by the
quota-rpcpackage, has to be started by user when the
This process provides NFSv4 client and server upcalls, which map between on-the-wire NFSv4 names (strings in the form of
user@domain) and local UIDs and GIDs. For
idmapdto function with NFSv4, the
/etc/idmapd.conffile must be configured. At a minimum, the
Domainparameter should be specified, which defines the NFSv4 mapping domain. If the NFSv4 mapping domain is the same as the DNS domain name, this parameter can be skipped. The client and server must agree on the NFSv4 mapping domain for ID mapping to function properly.
Only the NFSv4 server uses
rpc.idmapd, which is started by the
nfs-idmapdservice. The NFSv4 client uses the keyring-based
nfsidmaputility, which is called by the kernel on-demand to perform ID mapping. If there is a problem with
nfsidmap, the client falls back to using
The RPC services with NFSv4
The mounting and locking protocols have been incorporated into the NFSv4 protocol. The server also listens on the well-known TCP port 2049. As such, NFSv4 does not need to interact with
rpc-statd services. The
nfs-mountd service is still required on the NFS server to set up the exports, but is not involved in any over-the-wire operations.
23.4. NFS host name formats
This section describes different formats that you can use to specify a host when mounting or exporting an NFS share.
You can specify the host in the following formats:
- Single machine
Either of the following:
- A fully-qualified domain name (that can be resolved by the server)
- Host name (that can be resolved by the server)
- An IP address.
- IP networks
Either of the following formats is valid:
a.b.c.dis the network and
zis the number of bits in the netmask; for example
a.b.c.dis the network and
netmaskis the netmask; for example,
@group-nameformat , where
group-nameis the NIS netgroup name.
23.5. Installing NFS
This procedure installs all packages necessary to mount or export NFS shares.
# yum install nfs-utils
23.6. Discovering NFS exports
This procedure discovers which file systems a given NFSv3 or NFSv4 server exports.
With any server that supports NFSv3, use the
$ showmount --exports my-server Export list for my-server /exports/foo /exports/bar
With any server that supports NFSv4, mount the root directory and look around:
# mount my-server:/ /mnt/ # ls /mnt/ exports # ls /mnt/exports/ foo bar
On servers that support both NFSv4 and NFSv3, both methods work and give the same results.
23.7. Mounting an NFS share with mount
Mount an NFS share exported from a server by using the
You can experience conflicts in your NFSv4
clientid and their sudden expiration if your NFS clients have the same short hostname. To avoid any possible sudden expiration of your NFSv4
clientid, you must use either unique hostnames for NFS clients or configure identifier on each container, depending on what system you are using. For more information, see the NFSv4 clientid was expired suddenly due to use same hostname on several NFS clients Knowledgebase article.
To mount an NFS share, use the following command:
# mount -t nfs -o options host:/remote/export /local/directory
This command uses the following variables:
- A comma-delimited list of mount options.
- The host name, IP address, or fully qualified domain name of the server exporting the file system you want to mount.
- The file system or directory being exported from the server, that is, the directory you want to mount.
- The client location where /remote/export is mounted.
23.8. Common NFS mount options
The following are the commonly used options when mounting NFS shares. You can use these options wth manual
mount commands, the
/etc/fstab settings, and
Specifies how the kernel should manage its cache of directory entries for a given mount point. Valid arguments for mode are
Specifies which version of the NFS protocol to use, where version is
4.2. This is useful for hosts that run multiple NFS servers, or to disable retrying a mount with lower versions. If no version is specified, NFS uses the highest version supported by the kernel and the
versis identical to
nfsvers, and is included in this release for compatibility reasons.
- Turns off all ACL processing. This may be needed when interfacing with older versions of Red Hat Enterprise Linux, Red Hat Linux, or Solaris, because the most recent ACL technology is not compatible with older systems.
- Disables file locking. This setting is sometimes required when connecting to very old NFS servers.
- Prevents execution of binaries on mounted file systems. This is useful if the system is mounting a non-Linux file system containing incompatible binaries.
set-group-identifierbits. This prevents remote users from gaining higher privileges by running a
Specifies the numeric value of the NFS server port. If num is
0(the default value), then
rpcbindservice on the remote host for the port number to use. If the NFS service on the remote host is not registered with its
rpcbindservice, the standard NFS port number of TCP 2049 is used instead.
These options set the maximum number of bytes to be transferred in a single NFS read or write operation.
There is no fixed default value for
wsize. By default, NFS uses the largest possible value that both the server and the client support. In Red Hat Enterprise Linux 8, the client and server maximum is 1,048,576 bytes. For more details, see the What are the default and maximum values for rsize and wsize with NFS mounts? KBase article.
Security flavors to use for accessing files on the mounted export. The flavors value is a colon-separated list of one or more security flavors.
By default, the client attempts to find a security flavor that both the client and the server support. If the server does not support any of the selected flavors, the mount operation fails.
sec=sysuses local UNIX UIDs and GIDs. These use
AUTH_SYSto authenticate NFS operations.
sec=krb5uses Kerberos V5 instead of local UNIX UIDs and GIDs to authenticate users.
sec=krb5iuses Kerberos V5 for user authentication and performs integrity checking of NFS operations using secure checksums to prevent data tampering.
sec=krb5puses 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.
- Instructs the NFS mount to use the TCP protocol.