- How to configure Network File System on Linux
- Install NFS
- Set a shared location
- Export the shared location
- Training & certification
- Set ownership
- Export the exports
- Configure your firewall
- Set up your client
- Chapter 3. Mounting NFS shares
- 3.1. Introduction to NFS
- 3.2. Supported NFS versions
- Default NFS version
- Features of minor NFS versions
- 3.3. Services required by NFS
- The RPC services with NFSv4
- 3.4. NFS host name formats
- 3.5. Installing NFS
- 3.6. Discovering NFS exports
- 3.7. Mounting an NFS share with mount
- 3.8. Common NFS mount options
- Getting started with NFS
- More Linux resources
- Getting NFS running
- Sharing over NFS
- Accessing NFS shares
- Making that access permanent
- Wrapping up
How to configure Network File System on Linux
Posted: June 16, 2022 |
The Network File System (NFS) is a protocol that allows you to set up storage locations on your network. When you have NFS set up, your users can treat a remote hard drive as if it were attached to their computer, just like they might a USB thumb drive. It’s one of the easiest and most transparent ways to handle shared storage within an organization.
NFS is a built-in function in Red Hat Enterprise Linux (RHEL) 9, but there’s a package of utilities that you can install on the computer serving as the NFS host and on the Linux workstations that will interface with NFS:
On your NFS host, enable and start the NFS service:
You must also start the rpcbind service, which NFS uses for port mapping:
Set a shared location
On your NFS host, create a location on the filesystem to share with client computers. This could be a separate drive, a separate partition, or just a place on your server. To ensure that your storage can scale as needed, I recommend using LVM. Create the location with:
Export the shared location
For the NFS service to know to broadcast the existence of your myshare shared location, you must add the location to the /etc/exports file, as well as the subnet you want to have access and the global access permissions. For example, assuming your network is 192.168.122.0/24 (with the first possible address being 192.168.122.1 and the final being 192.168.122.254), then you could do this:
Training & certification
Note that there is no space between the network and the directory’s access permissions.
Depending on where you created your shared location, its permissions may not be suitable for all users on your network. For example, I created /nfs/exports/myshare at the root partition of my server’s hard drive, so the directories are all owned by the user root , with group root having read and execute permissions. Unless your users are members of the root group, this export is of little use to them.
How you set directory permissions is up to you and depends on how you define users and groups on your systems. It’s common to manage directories by group permissions, adding users who require access to specific directories to the corresponding group. For instance, if a user is a member of the staff group, then you could set your export to staff with permissions 775:
This grants myshare read, write, and execute permissions for all members of the staff group.
Export the exports
The NFS server maintains a table of filesystems available to clients. To update the table, run the exportfs command along with the -r command to export all directories recursively:
Configure your firewall
For clients to reach your NFS server, you must add the NFS service to your firewall with the firewall-cmd command:
Your NFS server is now active and configured for traffic.
Set up your client
Now that you’ve established a shared storage location on your network, you must configure your client machines to use it.
First, create a mount point for the NFS share:
And then mount the NFS volume:
You can make this a permanent and automatic process by adding the NFS volume to the client’s /etc/fstab file:
You can verify that an NFS volume is mounted with the mount command:
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.
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.
Install the nfs-utils package:
3.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 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.
3.7. Mounting an NFS share with mount
This procedure mounts an NFS share exported from a server using the mount utility.
To mount an NFS share, use the following command:
This command uses the following variables:
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.
Getting started with NFS
Posted: December 4, 2019 |
The Network File System (NFS) has been around a long time. It was developed in 1984 at Sun Microsystems. Version 3 was released to the public in 1995 and is still widely used today, though with many improvements. Sun turned NFS over to the IETF, and they released version 4 in 2000 (which has also seen many improvements since it was first released). In this current age of such rapid development and advanced technology, you might ask yourself: «Of what use is such a well-heeled technology?»
More Linux resources
NFS was created to allow users on one computer to access files on another. This concept still sounds quaint in the age of the internet, but maybe you don’t need the internet. Maybe you just need a central repository for files that can be simply and easily shared. Unlike CIFS/SMB (Samba), NFS can be managed with *nix access control. Unlike FTP, NFS can be mounted locally and accessed without having to reconnect each time it’s needed. And NFS version 4 works with LDAP and Kerberos to allow centralized, secure authentication.
For this discussion, we’ll talk about the basics, meaning what you need to get started with NFS. First, you’ll need to make sure you have the right packages installed and enabled. One of the good things about having been around for so long, and being so widely used, is that NFS support has been «baked into» the Linux kernel for some time. The necessary packages usually come already installed.
Getting NFS running
To be sure that you have NFS installed on your Red Hat Enterprise Linux or CentOS (version 7 or later), run the following:
Note: These packages don’t always all need to be installed separately. It depends on the version of your OS.
Next, make sure it’s enabled and started:
Note: Again, you won’t always need to run both of these commands. It depends on your specific version.
Sharing over NFS
Next, let’s create a directory on the server and share it. I like to create a directory for NFS and make folders under that directory to keep things organized:
Then, in your favorite text editor, edit the file /etc/exports . Add this line:
Save the file and run this command:
The result should show that you are now exporting the /nfs/export/enable directory.
Let’s take a minute to look at that export line. On the left, we can see what we are exporting. On the right, we can see that we exported that to the whole world ( * ) and made it both readable and writable. It’s important to be aware of this issue because it won’t be that often that you’ll want to make things that easy for bad guys. You might, for example, want to limit that to just a certain subnet and make it read-only:
There are lots of ways you can set this feature up. I encourage you to look at the exports man page if you want to learn more about your options. And as I said before, with NFS version 4 you can use LDAP and Kerberos to secure and control access, but that’s for another article.
Accessing NFS shares
Now what? Well, let’s go to your client computer and make the directory that will contain the files on your server when we connect via NFS:
Now, mount the remote filesystem locally using this command:
Note: Here, we specify nfs3 . The reason for this choice is that for nfs4 , we need to have some other things set up as well (which are, again, for another article).
Now you should be able to change to that directory and see the files on the remote machine.
Making that access permanent
To make this connection a «regular thing» and mount that remote filesystem automatically, open /etc/fstab in your favorite editor and add this line:
The _netdev is important. Otherwise, when your client machine boots, it will hang if there’s a problem reaching the network.
As I already mentioned, it’s important to note that this is a basic, simplified setup. But, this information should be enough to get you started testing different configurations and uses, and then putting this useful tool to work for you. For example, I use NFS at home to make a large, centralized storage server available on all of the machines in my house, including my wife’s Microsoft laptop (it used to be the case that Microsoft did not support NFS, and in fact made it difficult to use, but they’ve since made Windows more NFS-friendly).