Red hat linux nfs

Red Hat Customer Portal

Log in to Your Red Hat Account

Your Red Hat account gives you access to your profile, preferences, and services, depending on your status.

If you are a new customer, register now for access to product evaluations and purchasing capabilities.

Need access to an account?

If your company has an existing Red Hat account, your organization administrator can grant you access.

Red Hat Account

Customer Portal

For your security, if you’re on a public computer and have finished using your Red Hat services, please be sure to log out.

Select Your Language

Red Hat Training

A Red Hat training course is available for RHEL 8

Chapter 3. Mounting NFS shares

As a system administrator, you can mount remote NFS shares on your system to access shared data.

3.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.

3.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 rpcbind service, 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:

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.

3.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:

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 idmapd to function with NFSv4, the /etc/idmapd.conf file must be configured. At a minimum, the Domain parameter 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-idmapd service. The NFSv4 client uses the keyring-based nfsidmap utility, 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 rpc.idmapd .

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 rpcbind , lockd , and 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.

Additional resources

3.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:

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.

Either of the following formats is valid:

• a.b.c.d/z , where a.b.c.d is the network and z is the number of bits in the netmask; for example 192.168.0.0/24 .
• a.b.c.d/netmask , where a.b.c.d is the network and netmask is the netmask; for example, 192.168.100.8/255.255.255.0 .

3.5. Installing NFS

This procedure installs all packages necessary to mount or export NFS shares.

Procedure

Install the nfs-utils package:

3.6. Discovering NFS exports

This procedure discovers which file systems a given NFSv3 or NFSv4 server exports.

Procedure

With any server that supports NFSv3, use the showmount utility:

With any server that supports NFSv4, mount the root directory and look around:

On servers that support both NFSv4 and NFSv3, both methods work and give the same results.

Additional resources

3.7. Mounting an NFS share with mount

This procedure mounts an NFS share exported from a server using the mount utility.

Procedure

To mount an NFS share, use the following command:

This command uses the following variables:

Additional resources

3.8. Common NFS mount options

This section lists options commonly used when mounting NFS shares. These options can be used with manual mount commands, /etc/fstab settings, and autofs .

Specifies which version of the NFS protocol to use, where version is 3 , 4 , 4.0 , 4.1 , or 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 mount utility.

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, because the most recent ACL technology is not compatible with older systems. nolock Disables file locking. This setting is sometimes required when connecting to very old 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 the set-user-identifier and 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 value), then mount queries the rpcbind service on the remote host for the port number to use. If the NFS service on the remote host is not registered with its rpcbind service, the standard NFS port number of TCP 2049 is used instead. rsize= num and wsize= num

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 rsize and 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.

Источник

Red Hat Customer Portal

Log in to Your Red Hat Account

Your Red Hat account gives you access to your profile, preferences, and services, depending on your status.

If you are a new customer, register now for access to product evaluations and purchasing capabilities.

Need access to an account?

If your company has an existing Red Hat account, your organization administrator can grant you access.

Red Hat Account

Customer Portal

For your security, if you’re on a public computer and have finished using your Red Hat services, please be sure to log out.

Select Your Language

Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

21.6. NFS Server Configuration

Figure 21.1. NFS Server Configuration Tool

Figure 21.2. NFS Server Settings

21.6.1. Exporting or Sharing NFS File Systems

Figure 21.3. Add Share

Figure 21.4. NFS General Options

Figure 21.5. NFS User Access

Источник

Red Hat Customer Portal

Log in to Your Red Hat Account

Your Red Hat account gives you access to your profile, preferences, and services, depending on your status.

If you are a new customer, register now for access to product evaluations and purchasing capabilities.

Need access to an account?

If your company has an existing Red Hat account, your organization administrator can grant you access.

Red Hat Account

Customer Portal

For your security, if you’re on a public computer and have finished using your Red Hat services, please be sure to log out.

Select Your Language

Red Hat Training

A Red Hat training course is available for RHEL 8

Chapter 5. Exporting NFS shares

As a system administrator, you can use the NFS server to share a directory on your system over network.

5.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.

5.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 rpcbind service, 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:

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.

5.3. The TCP and UDP protocols in NFSv3 and NFSv4

NFSv4 requires the Transmission Control Protocol (TCP) running over an IP network.

NFSv3 could also use the User Datagram Protocol (UDP) in earlier Red Hat Enterprise Linux versions. In Red Hat Enterprise Linux 8, NFS over UDP is no longer supported. By default, UDP is disabled in the NFS server.

5.4. 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:

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 idmapd to function with NFSv4, the /etc/idmapd.conf file must be configured. At a minimum, the Domain parameter 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-idmapd service. The NFSv4 client uses the keyring-based nfsidmap utility, 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 rpc.idmapd .

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 rpcbind , lockd , and 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.

Additional resources

5.5. 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:

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.

Either of the following formats is valid:

• a.b.c.d/z , where a.b.c.d is the network and z is the number of bits in the netmask; for example 192.168.0.0/24 .
• a.b.c.d/netmask , where a.b.c.d is the network and netmask is the netmask; for example, 192.168.100.8/255.255.255.0 .

5.6. NFS server configuration

This section describes the syntax and options of two ways to configure exports on an NFS server:

• Manually editing the /etc/exports configuration file
• Using the exportfs utility on the command line

5.6.1. The /etc/exports configuration file

The /etc/exports file controls which file systems are exported to remote hosts and specifies options. It follows the following syntax rules:

• Blank lines are ignored.
• To add a comment, start a line with the hash mark ( # ).
• You can wrap long lines with a backslash ( \ ).
• Each exported file system should be on its own individual line.
• Any lists of authorized hosts placed after an exported file system must be separated by space characters.
• Options for each of the hosts must be placed in parentheses directly after the host identifier, without any spaces separating the host and the first parenthesis.

Export entry

Each entry for an exported file system has the following structure:

It is also possible to specify multiple hosts, along with specific options for each host. To do so, list them on the same line as a space-delimited list, with each host name followed by its respective options (in parentheses), as in:

In this structure:

Example 5.1. A simple /etc/exports file

In its simplest form, the /etc/exports file only specifies the exported directory and the hosts permitted to access it:

Here, bob.example.com can mount /exported/directory/ from the NFS server. Because no options are specified in this example, NFS uses default options.

The format of the /etc/exports file is very precise, particularly in regards to use of the space character. Remember to always separate exported file systems from hosts and hosts from one another with a space character. However, there should be no other space characters in the file except on comment lines.

For example, the following two lines do not mean the same thing:

The first line allows only users from bob.example.com read and write access to the /home directory. The second line allows users from bob.example.com to mount the directory as read-only (the default), while the rest of the world can mount it read/write.

Default options

The default options for an export entry are:

This prevents root users connected remotely (as opposed to locally) from having root privileges; instead, the NFS server assigns them the user ID nobody . This effectively «squashes» the power of the remote root user to the lowest local user, preventing possible unauthorized writes on the remote server. To disable root squashing, specify the no_root_squash option.

To squash every remote user (including root), use the all_squash option. To specify the user and group IDs that the NFS server should assign to remote users from a particular host, use the anonuid and anongid options, respectively, as in:

Here, uid and gid are user ID number and group ID number, respectively. The anonuid and anongid options enable you to create a special user and group account for remote NFS users to share.

By default, access control lists (ACLs) are supported by NFS under Red Hat Enterprise Linux. To disable this feature, specify the no_acl option when exporting the file system.

Default and overridden options

Each default for every exported file system must be explicitly overridden. For example, if the rw option is not specified, then the exported file system is shared as read-only. The following is a sample line from /etc/exports which overrides two default options:

In this example, 192.168.0.3 can mount /another/exported/directory/ read and write, and all writes to disk are asynchronous.

5.6.2. The exportfs utility

The exportfs utility enables the root user to selectively export or unexport directories without restarting the NFS service. When given the proper options, the exportfs utility writes the exported file systems to /var/lib/nfs/xtab . Because the nfs-mountd service refers to the xtab file when deciding access privileges to a file system, changes to the list of exported file systems take effect immediately.

Common exportfs options

The following is a list of commonly-used options available for exportfs :

If no options are passed to the exportfs utility, it displays a list of currently exported file systems.

Additional resources

• For information on different methods for specifying host names, see Section 5.5, “NFS host name formats”.
• For a complete list of export options, see the exports(5) man page.
• For more information about the exportfs utility, see the exportfs(8) man page.

5.7. NFS and rpcbind

This section explains the purpose of the rpcbind service, which is required by NFSv3.

The rpcbind service maps Remote Procedure Call (RPC) services to the ports on which they listen. RPC processes notify rpcbind when they start, registering the ports they are listening on and the RPC program numbers they expect to serve. The client system then contacts rpcbind on the server with a particular RPC program number. The rpcbind service redirects the client to the proper port number so it can communicate with the requested service.

Because RPC-based services rely on rpcbind to make all connections with incoming client requests, rpcbind must be available before any of these services start.

Access control rules for rpcbind affect all RPC-based services. Alternatively, it is possible to specify access control rules for each of the NFS RPC daemons.

Additional resources

• For the precise syntax of access control rules, see the rpc.mountd(8) and rpc.statd(8) man pages.

5.8. Installing NFS

This procedure installs all packages necessary to mount or export NFS shares.

Procedure

Install the nfs-utils package:

5.9. Starting the NFS server

This procedure describes how to start the NFS server, which is required to export NFS shares.

Prerequisites

For servers that support NFSv2 or NFSv3 connections, the rpcbind service must be running. To verify that rpcbind is active, use the following command:

If the service is stopped, start and enable it:

Procedure

To start the NFS server and enable it to start automatically at boot, use the following command:

Additional resources

• To configure an NFSv4-only server, which does not require rpcbind , see Section 5.14, “Configuring an NFSv4-only server”.

5.10. Troubleshooting NFS and rpcbind

Because the rpcbind service provides coordination between RPC services and the port numbers used to communicate with them, it is useful to view the status of current RPC services using rpcbind when troubleshooting. The rpcinfo utility shows each RPC-based service with port numbers, an RPC program number, a version number, and an IP protocol type (TCP or UDP).

Procedure

To make sure the proper NFS RPC-based services are enabled for rpcbind , use the following command:

Example 5.2. rpcinfo -p command output

The following is sample output from this command:

If one of the NFS services does not start up correctly, rpcbind will be unable to map RPC requests from clients for that service to the correct port.

In many cases, if NFS is not present in rpcinfo output, restarting NFS causes the service to correctly register with rpcbind and begin working:

Additional resources

• For more information and a list of rpcinfo options, see the rpcinfo(8) man page.
• To configure an NFSv4-only server, which does not require rpcbind , see Section 5.14, “Configuring an NFSv4-only server”.

5.11. Configuring the NFS server to run behind a firewall

NFS requires the rpcbind service, which dynamically assigns ports for RPC services and can cause issues for configuring firewall rules. This procedure describes how to configure the NFS server to work behind a firewall.

Procedure

To allow clients to access NFS shares behind a firewall, set which ports the RPC services run on in the [mountd] section of the /etc/nfs.conf file:

This adds the -p port-number option to the rpc.mount command line: rpc.mount -p port-number .

To allow clients to access NFS shares behind a firewall, configure the firewall by running the following commands on the NFS server:

In the commands, replace with the intended port or a port range. When specifying a port range, use the —add-port= — /udp syntax.

To allow NFSv4.0 callbacks to pass through firewalls, set /proc/sys/fs/nfs/nfs_callback_tcpport and allow the server to connect to that port on the client.

This step is not needed for NFSv4.1 or higher, and the other ports for mountd , statd , and lockd are not required in a pure NFSv4 environment.

Restart the NFS server:

If NFS fails to start, check /var/log/messages . Commonly, NFS fails to start if you specify a port number that is already in use.

Confirm the changes have taken effect:

Additional resources

• To configure an NFSv4-only server, which does not require rpcbind , see Section 5.14, “Configuring an NFSv4-only server”.

5.12. Exporting RPC quota through a firewall

If you export a file system that uses disk quotas, you can use the quota Remote Procedure Call (RPC) service to provide disk quota data to NFS clients.

Procedure

Enable and start the rpc-rquotad service:

The rpc-rquotad service is, if enabled, started automatically after starting the nfs-server service.

To make the quota RPC service accessible behind a firewall, the TCP (or UDP, if UDP is enabled) port 875 need to be open. The default port number is defined in the /etc/services file.

You can override the default port number by appending -p port-number to the RPCRQUOTADOPTS variable in the /etc/sysconfig/rpc-rquotad file.

Restart rpc-rquotad for the changes in the /etc/sysconfig/rpc-rquotad file to take effect:

5.13. Enabling NFS over RDMA (NFSoRDMA)

The remote direct memory access (RDMA) service works automatically in Red Hat Enterprise Linux 8 if there is RDMA-capable hardware present.

Procedure

Install the rdma-core package:

To enable automatic loading of NFSoRDMA server modules, add the SVCRDMA_LOAD=yes option on a new line in the /etc/rdma/rdma.conf configuration file.

The rdma=20049 option in the [nfsd] section of the /etc/nfs.conf file specifies the port number on which the NFSoRDMA service listens for clients. The RFC 5667 standard specifies that servers must listen on port 20049 when providing NFSv4 services over RDMA.

The /etc/rdma/rdma.conf file contains a line that sets the XPRTRDMA_LOAD=yes option by default, which requests the rdma service to load the NFSoRDMA client module.

Restart the nfs-server service:

Additional resources

5.14. Configuring an NFSv4-only server

As an NFS server administrator, you can configure the NFS server to support only NFSv4, which minimizes the number of open ports and running services on the system.

5.14.1. Benefits and drawbacks of an NFSv4-only server

This section explains the benefits and drawbacks of configuring the NFS server to only support NFSv4.

By default, the NFS server supports NFSv3 and NFSv4 connections in Red Hat Enterprise Linux 8. However, you can also configure NFS to support only NFS version 4.0 and later. This minimizes the number of open ports and running services on the system, because NFSv4 does not require the rpcbind service to listen on the network.

When your NFS server is configured as NFSv4-only, clients attempting to mount shares using NFSv3 fail with an error like the following:

Optionally, you can also disable listening for the RPCBIND , MOUNT , and NSM protocol calls, which are not necessary in the NFSv4-only case.

The effects of disabling these additional options are:

• Clients that attempt to mount shares from your server using NFSv3 become unresponsive.
• The NFS server itself is unable to mount NFSv3 file systems.

5.14.2. Configuring the NFS server to support only NFSv4

This procedure describes how to configure your NFS server to support only NFS version 4.0 and later.

Procedure

Disable NFSv3 by adding the following lines to the [nfsd] section of the /etc/nfs.conf configuration file:

Optionally, disable listening for the RPCBIND , MOUNT , and NSM protocol calls, which are not necessary in the NFSv4-only case. Disable related services:

Restart the NFS server:

The changes take effect as soon as you start or restart the NFS server.

5.14.3. Verifying the NFSv4-only configuration

This procedure describes how to verify that your NFS server is configured in the NFSv4-only mode by using the netstat utility.

Procedure

Use the netstat utility to list services listening on the TCP and UDP protocols:

Example 5.3. Output on an NFSv4-only server

The following is an example netstat output on an NFSv4-only server; listening for RPCBIND , MOUNT , and NSM is also disabled. Here, nfs is the only listening NFS service:

Example 5.4. Output before configuring an NFSv4-only server

In comparison, the netstat output before configuring an NFSv4-only server includes the sunrpc and mountd services:

Источник