Accessing Network Storage with Network File System

There are a number of steps that need to be taken before Network File System (NFS) allows clients access to data. This article describes those steps and also guides the reader on some other aspects of NFS.

Network File System or NFS is an Internet standard protocol used by Linux, UNIX and similar operating systems as their native network file system. It is an open standard under active extension, which supports native Linux permissions and file system features. Red

Hat Enterprise Linux 7 supports NFSv4 (version 4 for the protocol) by default, and falls back automatically to NFSv3 and NFSv2 if that is not available. NFSv4 uses the TCP protocol to communicate with the server, while older versions of NFS may use either TCP or UDP.

NFS servers export share directories and NFS clients mount an exported share to a local mount point (directory). The local mount point must exist. NFS shares can be mounted in a number of ways:

Manual mounting using the mount command

Automatic mounting at boot time using /etc/fstab Mounting on demand through a process known as automounting

Securing file access on NFS shares

NFS servers secure access to files using a number of methods such as none, sys, krb5, krb5i and krb5p. The NFS server can choose to offer a single or multiple methods for each exported share. NFS clients must connect to the exported share using one of the methods mandated for that share, specified as a mount option sec= method.

Methods used to secure access to files

None: This gives anonymous access to the files, and writes to the server (if allowed) are allocated UID and GID of nfsnobody.

Sys: This gives file access based on standard Linux file permissions for UID and GID values. If not specified, this is the default.

Krb5: Clients must prove their identity using Kerberos, and then standard Linux file permissions apply.

Krb5i adds a cryptographically strong guarantee that the data in each request has not been tampered with.

Krb5p adds encryption to all requests between the client and the server, preventing data exposure on the network. This has a performance impact.

Important: Kerberos options will require, as a minimum, a /etc/krb5. keytab and additional authentication configuration. The /etc/krb5. keytab will normally be provided by the authentication or security administrator. Request a keytab that includes either a host principal, NFS principal, or (ideally) both.

NFS uses the nfs-secure service to help negotiate and manage communication with the server when connecting to Kerberossecured shares. It must be running to use the second NFS shares; start and enable it to ensure it is always available.

# systemctl enable nfs-secure # systemctl start nfs-secure

Note: The nfs-secure command is part of the nfs-utils package, which should be installed, by default. If it is not installed, use the following command:

# yum –y install nfs-utils

Exporting NFS

The Network File System (NFS) is commonly used by UNIX systems and network attached storage devices to allow multiple clients to share access to files over the network. It provides access to shared directories or files from client systems.

NFS exports

An NFS server installation requires the nfs-utils package to be installed. It provides all the necessary utilities to export a directory with NFS to clients. The configuration file for the NFS server exports the /etc/exports file. This file lists the directory to share to client hosts over the network, and indicates which hosts or networks have access to the export.

Note: Instead of adding the information required for exporting directories to the /etc/exports file, a newly created file named *.exports can be added to the /etc/exports.d/ directory holding the configuration of exports.

Warning: Exporting the same directory with NFS and Samba is not supported on Red Hat Enterprise Linux 7, because NFS and Samba use different file locking mechanisms, which can cause file corruption.

One or more clients can be listed, separated by a space, as any of the following:

1. DNS-resolvable host name, like server.example.com in the following example, where the /myshare directory is exported and can be mounted by serverX.example.com.

/myshare server.example.com

2. DNS resolvable host name with the wildcards ‘*’ for multiple character and ‘/’ or ‘?’ for a single character. The following example allows all sub-domains in the example. com domain to access the NFS export:

/myshare *.example.com

3. DNS resolvable host name with character class lists in square brackets. In this example, the hosts server1. example.com, server2.example.com,…and server20. example.com have access to the NFS export.

/myshare server[0-20].example.com

4. IPv4 address. The following example allows access to the /myshare NFS share from the 172.25.21.21 IP address.

/myshare 172.25.21.21

5. IPv4 network. This example shows a /etc/exports entry, which allows access to the NFS-exported directory /myshare from the 172.25.0.0/16 network.

/myshare 172.25.0.0/16

6. IPv6 address without square brackets. The following example allows the client with the IPv6 address 2000:472:18:b51:c32:a21 access to the NFS exported directory /myshare.

/myshare 2000:472:18:b51:c32:a21

7. IPv6 network without square brackets. This example allows the IPv6 network 2000:472:18:b51::/64 access to the NFS export.

/myshare 2000:472:18:b51::/64

8. A directory can be exported to multiple hosts simultaneously by specifying multiple targets with their options, separated by spaces following the directory to export.

/myshare *.example.com 172.25.0.0/16

Optionally, there can be one or more export options specified in round brackets as a comma-separated list, directly followed by each client definition. Three commonly used export options are given below.

ro, read-only: This is the default setting when nothing is specified. It is allowed to explicitly specify it with an entry. This restricts the NFS clients to read files on the NFS share. Any write operation is prohibited. The following example explicitly states the ro flag for the server.example.com host.

/myshare desktop.example.com(ro)

rw, read-write: This allows read and write access for the NFS clients. In the following example, the desktop.example.com is able to access the NFS export read-only, while server[0-20]. example.com has read-write access to the NFS share.

/myshare desktop.example.com(ro) server[0-20].example.com(rw)