Last modified: July 19, 2020

This article is written in: 🇺🇸

NFS

NFS, or Network File System, is a protocol that allows different computers to share files over a network as if they were on the local machine. This means you can access files on another computer just like you would access files on your own, making collaboration and resource sharing much easier. NFS is compatible with various operating systems, including Linux, macOS, and Windows.

Client                       Network                      Server
+--------+                                            +--------+
|        |    <-- NFS Protocol Communication -->      |        |
|  User  |                                            |  NFS   |
| Space  |                                            | Server |
+--------+                                            +--------+
     |                                                      |
+--------+                                            +--------+
|  NFS   |                                            |  NFS   |
| Client |                                            | Daemon |
+--------+                                            +--------+
     |                                                      |
+--------+                                            +--------+
| File   |                                            | File   |
| System |                                            | System |
+--------+                                            +--------+
     |                                                      |
+--------+                                            +--------+
| Disk   |                                            | Disk   |
| Storage|                                            | Storage|
+--------+                                            +--------+

In this diagram, the client interacts with the NFS server over the network. The NFS client software translates local file operations into NFS protocol requests, which are sent to the server. The server processes these requests and accesses its local file system accordingly, providing the requested data back to the client.

Reasons for Using NFS

• NFS allows centralized storage, enabling multiple clients to access files on a single server, simplifying data management and backup processes.
• By facilitating file sharing across networks, NFS enables seamless access to shared files among different systems, improving collaboration and accessibility.
• NFS is platform-independent, meaning it can be used on various operating systems (such as Linux, UNIX, and Windows) without compatibility issues.
• It provides reduced storage duplication, as files are stored on a central server, eliminating the need for multiple copies across different devices.
• With consistent access permissions, NFS allows administrators to control file permissions centrally, ensuring consistent access rights across all clients.
• NFS supports automatic mounting using configuration files, making it easier for clients to access shared directories without manual intervention.
• The protocol is scalable, allowing additional clients or servers to be added to the network without significant changes to the existing infrastructure.
• NFS can improve performance in certain use cases by reducing local storage requirements and centralizing storage access, optimizing resource usage.
• NFS facilitates remote work and distributed computing by allowing users to access files on a central server from different physical locations.
• With cost efficiency, NFS can reduce hardware costs by centralizing storage and minimizing the need for local storage on client machines.
• NFS integrates well with authentication and encryption methods, such as Kerberos, to provide secure file access over networks.

Setting Up an NFS Server on CentOS 7

If you're looking to share directories from a CentOS 7 machine so that other computers on the network can access them, you'll need to set up that machine as an NFS server. Here's how you can do it step by step.

Installing Necessary Packages

First, you'll need to install the NFS utilities, which include essential services and tools for NFS functionality. Open your terminal and run:

yum install nfs-utils nfs-utils-lib

This command downloads and installs the nfs-utils and nfs-utils-lib packages. After running it, you should see output indicating that the packages have been successfully installed, along with any dependencies.

Enabling and Starting Required Services

NFS relies on several background services to operate correctly. These services include rpcbind, nfs-server, nfs-lock, and nfs-idmap. Each service plays a role in handling network communication, file locking, and user ID mapping.

To enable these services to start at boot time and to start them immediately, execute the following commands:

systemctl enable rpcbind
systemctl start rpcbind

systemctl enable nfs-server
systemctl start nfs-server

systemctl enable nfs-lock
systemctl start nfs-lock

systemctl enable nfs-idmap
systemctl start nfs-idmap

For example, after starting the nfs-server service, you can check its status by running:

systemctl status nfs-server

You should see output similar to:

● nfs-server.service - NFS server and services
   Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; vendor preset: disabled)
   Active: active (exited) since Wed 2024-10-10 12:34:56 EDT; 10s ago

This output confirms that the NFS server service is active and running.

Configuring NFS Exports

Now it's time to specify which directories you want to share with clients and define the access permissions. This is done by editing the /etc/exports file.

Open the exports file with your favorite text editor:

vi /etc/exports

Add the following line to share the /opt/shared directory with clients on the 192.168.1.0/24 network:

/opt/shared 192.168.1.0/24(rw,sync,no_root_squash,no_all_squash)

Here's what each part means:

• /opt/shared is the directory on the server that you want to share.
• 192.168.1.0/24 is the range of IP addresses that are allowed to access the share.
• (rw,sync,no_root_squash,no_all_squash) is the options that control access permissions and behavior.

To explain the options in more detail, let's look at them in a table:

By setting these options, you're controlling how clients interact with the shared directory, including who can read or write files and how user permissions are handled.

Applying Configuration Changes

After editing the exports file, you need to inform the NFS server of the changes. This is done using the exportfs command:

exportfs -r

This command re-reads the /etc/exports file and updates the NFS server's table of exported file systems without requiring a restart.

Verifying Shared Directories

To confirm that your directory is being shared correctly, you can use:

exportfs -v

The output will display the shared directories along with their options, something like:

/opt/shared  192.168.1.0/24(rw,wdelay,root_squash,no_subtree_check,secure)

This confirms that /opt/shared is exported and accessible to clients in the specified IP range with the defined options.

Adjusting Firewall Settings

For clients to access the NFS share, the server's firewall must allow NFS-related traffic. You can adjust the firewall settings using the firewall-cmd utility:

firewall-cmd --permanent --add-service=nfs
firewall-cmd --permanent --add-service=mountd
firewall-cmd --permanent --add-service=rpc-bind
firewall-cmd --reload

These commands open the necessary ports for NFS services and reload the firewall configuration to apply the changes immediately.

Restarting NFS Services

To ensure that all changes are properly applied, it's a good idea to restart the NFS server:

systemctl restart nfs-server

This restarts the NFS server service, ensuring that it recognizes the new configuration and that any pending changes are implemented.

Setting Up an NFS Client on CentOS 7

Once the NFS server is set up, the next step is to configure a client machine so it can access the shared directory. Here are the steps to set up an NFS client on CentOS 7.

Installing NFS Utilities on the Client

Just like on the server, the client needs the NFS utilities installed to communicate with the NFS server:

yum install nfs-utils nfs-utils-lib

This installs the necessary packages for NFS client functionality.

Enabling and Starting the rpcbind Service

The rpcbind service is essential for NFS communication on the client side as well. Enable and start it by running:

systemctl enable rpcbind
systemctl start rpcbind

You can verify that it's running with:

systemctl status rpcbind

Creating a Mount Point

Decide where you want the NFS share to be mounted on your client system. For example, you might create a directory under /mnt:

mkdir /mnt/nfs_shared

This directory will serve as the access point for the shared files from the server.

Mounting the NFS Share

Now you can mount the NFS share using the mount command:

mount -t nfs 192.168.1.100:/opt/shared /mnt/nfs_shared

Breaking down this command:

• -t nfs specifies the file system type as NFS.
• 192.168.1.100:/opt/shared indicates the NFS server's IP address and the shared directory.
• /mnt/nfs_shared is the local directory where the NFS share will be mounted.

After running this command, the contents of /opt/shared on the server will be accessible under /mnt/nfs_shared on the client.

Verifying the Mount

To ensure that the NFS share is mounted correctly, you can use:

mount | grep nfs

This should display something like:

192.168.1.100:/opt/shared on /mnt/nfs_shared type nfs (rw,addr=192.168.1.100)

Alternatively, you can list the contents of the mounted directory:

ls /mnt/nfs_shared

This should show the files and directories that are present on the server's shared directory.

Automating the Mount at Boot

If you want the NFS share to be mounted automatically every time the client machine boots up, you can add an entry to the /etc/fstab file.

Open the /etc/fstab file:

vi /etc/fstab

Add the following line at the end:

192.168.1.100:/opt/shared /mnt/nfs_shared nfs defaults 0 0

This tells the system to mount the NFS share at /mnt/nfs_shared using default options during the boot process.

Permissions and UID/GID Mapping in NFS

When using NFS to share files across different systems, managing permissions becomes a critical aspect to ensure that users have appropriate access to shared resources. One of the main challenges arises from the way NFS handles user and group identities, specifically through User IDs (UIDs) and Group IDs (GIDs). Understanding how these identifiers work and the potential caveats can help prevent permission issues and security risks.

How UID and GID Affect NFS Permissions

In Unix-like systems, every file and directory is associated with a UID and GID, which determine the ownership and group association. Permissions are then applied based on these IDs, controlling read, write, and execute access for the owner, group, and others.

When an NFS client accesses files on an NFS server, the client uses its local UID and GID to determine permissions. The NFS server, however, relies on its own UID and GID mappings to enforce access controls. If the UIDs and GIDs do not match between the client and server, users might experience unexpected permissions—either being denied access to files they should have rights to or gaining access to files they shouldn't.

For example, suppose a user named "alice" has a UID of 1000 on the NFS client but a different UID on the NFS server. When "alice" tries to access a file she owns on the client, the server might not recognize her as the owner, leading to permission issues.

The Caveats of Mismatched UIDs and GIDs

One of the main caveats with NFS permissions is that UIDs and GIDs are numerical and local to each system. There's no inherent mapping of usernames to UIDs across different machines unless explicitly managed. This can lead to several issues:

• Users may have different UIDs on different systems, causing confusion in file ownership and access rights.
• A user on one system could unintentionally gain access to files owned by another user on the NFS server if their UIDs match.
• Manually synchronizing UIDs and GIDs across multiple systems can be error-prone and time-consuming.

Strategies for Managing UID and GID Consistency

To mitigate these issues, it's important to establish a consistent mapping of UIDs and GIDs across all systems involved in NFS sharing. Here are some approaches to achieve this:

1. Implement a network-wide user directory service like LDAP (Lightweight Directory Access Protocol) or NIS (Network Information Service). This ensures that all users and groups have the same UIDs and GIDs across all systems.
2. Carefully assign UIDs and GIDs when creating user accounts on each system to ensure they match. While feasible in small environments, this method doesn't scale well for larger networks.
3. NFS version 4 supports username-based authentication and can map usernames to UIDs and GIDs using the idmapd service. This allows for consistent permissions without relying on matching numerical IDs.

Configuring idmapd for NFSv4

Using idmapd can simplify UID and GID management by mapping usernames between client and server. Here's how to set it up:

I. Install and Configure idmapd

Ensure that nfs-utils is installed, which includes idmapd. Edit the /etc/idmapd.conf file on both the client and server to set the same domain:

[General]
Domain = example.com

II. Start the idmapd Service

Enable and start the idmapd service on both systems:

systemctl enable nfs-idmapd
systemctl start nfs-idmapd

III. Mount the NFS Share Using NFSv4

On the client, mount the NFS share specifying NFS version 4:

mount -t nfs4 server.example.com:/shared /mnt/shared

Root Squashing and Its Impact on Permissions

Root squashing is an NFS security feature that maps requests from the root user (UID 0) on the client to an anonymous or unprivileged user on the server, typically nfsnobody. This prevents a root user on a client machine from having root privileges on the NFS server, enhancing security.

While root squashing protects the server, it can also cause permission issues when administrative tasks require root access to shared files. If necessary, you can disable root squashing by modifying the export options in /etc/exports:

/shared 192.168.1.0/24(rw,sync,no_root_squash)

However, disabling root squashing should be done cautiously, as it can expose the server to security risks.

Using no_all_squash and all_squash Options

The no_all_squash option (default behavior) preserves the original UID and GID of users accessing the NFS share. Conversely, the all_squash option maps all user requests to the anonymous user, which can be useful in environments where you want to restrict all client access to a single user identity on the server.

For example, to map all client access to the nfsnobody user, you can use:

/shared 192.168.1.0/24(rw,sync,all_squash)

Understanding Permission Denied Errors

If users encounter "Permission Denied" errors when accessing NFS shares, it's often due to UID and GID mismatches or incorrect export configurations. To troubleshoot:

• Verify that the user's UID and GID are the same on both the client and server.
• Ensure that the export options in /etc/exports are correctly set and that the client IP is allowed.
• On the server, confirm that the shared files and directories have the appropriate ownership and permissions.

Example Scenario

Imagine a user named "bob" needs access to a shared directory over NFS. On the server, "bob" has a UID of 1001, but on the client, his UID is 1002. When "bob" tries to access files he owns on the server, the server doesn't recognize him as the owner because the UIDs don't match. As a result, he might be denied access or have limited permissions.

To resolve this, you could:

• Change "bob's" UID on the client to 1001 to match the server.
• Configure idmapd to map "bob's" username to the correct UID, allowing consistent permissions without changing UIDs.

Additional Considerations

Security Measures

While NFS simplifies file sharing across networks, it's important to implement security measures to protect your data.

• Only allow trusted IP addresses or networks to access your NFS shares.
• Configure firewalls on both the server and client to limit exposure.
• Unless necessary, avoid using no_root_squash as it can grant root access to clients, which is a potential security risk.
• If possible, use NFS version 4, which includes better security features like stronger authentication.

Managing Shared Folders

If you need to view the current shared directories and their options on the server, you can use:

exportfs -v

This will display detailed information about each exported directory.

If you decide to stop sharing a directory, you can unexport it with:

exportfs -u /opt/shared

This command stops the NFS server from sharing /opt/shared.

Troubleshooting Common Issues

If clients are having trouble accessing the NFS share, here are some steps you can take:

• Ensure that the client can reach the server using ping or other network tools.
• Make sure that the necessary ports are open on both the server and client.
• Double-check the /etc/exports file for any typos or incorrect options.
• Look at the server's system logs for any error messages related to NFS.

Performance Optimization

For better performance, especially in environments with heavy file access, consider the following:

• On the server, you can use the async option in /etc/exports to allow asynchronous writes. This can improve performance but may risk data integrity in the event of a crash.
• On the client, you can specify mount options like rsize and wsize to control the read and write buffer sizes.

For example, mounting with specific read and write sizes:

mount -t nfs -o rsize=8192,wsize=8192 192.168.1.100:/opt/shared /mnt/nfs_shared

This sets the read and write buffer sizes to 8KB, which can improve performance depending on your network conditions.

Cross-Platform Compatibility

NFS can be used in mixed operating system environments. For example, macOS and Windows systems can also act as NFS clients.

• On macOS you can mount an NFS share using the mount command in the terminal or through the Finder's "Connect to Server" option.
• On Windows you can enable the "Services for NFS" feature and mount NFS shares using the mount command in the command prompt.

Understanding NFS Versions

There are different versions of NFS, each with its own features:

• NFSv2 was the initial version of the Network File System, introduced in 1984, and offered basic functionality. It primarily uses UDP, which is lightweight but lacks reliability for data transfer, limiting its performance in certain network conditions.
• Due to the limitations of NFSv2, the protocol is largely considered outdated and is rarely used in modern environments. Its file size support was limited to 2GB, which is inadequate for today's large files, and it did not support asynchronous operations.
• NFSv3 introduced significant improvements over NFSv2, supporting file sizes up to 16 exabytes, which allows users to manage much larger datasets. It also includes asynchronous writes, enhancing the performance by allowing data to be written to disk without waiting for acknowledgment.
• With the addition of asynchronous operations in NFSv3, the protocol saw increased stability and was better suited to high-performance environments. This version also introduced better error reporting, allowing clients to understand the nature of failures more precisely.
• NFSv3 also supports both UDP and TCP protocols, with TCP providing greater reliability over large distances or unreliable networks. This version remains widely adopted and stable, making it a common choice for many organizations.
• NFSv4 is a stateful protocol, which marks a shift from the previous stateless versions. This improvement enhances security and performance by maintaining a session state between client and server, which helps streamline the handling of requests.
• A key feature of NFSv4 is its support for Kerberos authentication, providing a more secure access mechanism and making it ideal for sensitive or enterprise environments. This version also uses a single TCP port, 2049, simplifying firewall and network configurations.
• Unlike earlier versions, NFSv4 includes support for ACLs (Access Control Lists), offering more granular file permissions. This feature enables better integration with various OS security models and enhances user access control within shared file systems.
• NFSv4 also introduced compound operations, which allow multiple operations to be bundled into a single request. This bundling reduces the number of round trips needed between client and server, optimizing network efficiency and improving response times.
• For enhanced performance, NFSv4 supports client-side caching, reducing the need to constantly query the server and speeding up data access. This version also incorporates directory delegation, allowing clients to manage directory contents locally in certain situations, which is particularly useful in distributed systems.

Challenges

1. Describe the primary purpose of NFS and how it facilitates file sharing between different computers on a network. Explain the role of NFS in distributed systems and how it allows users to access files on remote systems as if they were local.
2. Outline the key components of an NFS server, such as the NFS daemon and rpcbind service. Describe how each component contributes to the operation of NFS and why they are necessary for the server to function correctly.
3. Investigate the role of the rpcbind service in NFS, including how it registers and maps network services to the correct ports. Explain why rpcbind is essential for NFS communication and the consequences of it not being active.
4. Configure an NFS server to share a specific directory by editing the /etc/exports file and setting appropriate access permissions. Explain the purpose of the /etc/exports file and why it is necessary for defining shared directories.
5. Review and experiment with different options available in the /etc/exports file, such as ro (read-only), rw (read-write), and sync (synchronized writes). Discuss how these options affect client access and the security of shared directories.
6. Compare the setup process of an NFS server and an NFS client. Document the similarities and differences, especially in terms of the services and configuration files required on each side for successful communication.
7. Mount an NFS-shared directory on a client system using the mount command, and verify the connection by accessing the files in the mounted directory. Explain how the client can confirm that the connection is stable and functioning as expected.
8. Identify potential security risks associated with NFS, such as unauthorized access and data interception. Explore measures to mitigate these risks, including using firewalls, limiting client access, and enabling NFS over VPN for added security.
9. Demonstrate how NFS can be used to share directories across different operating systems, such as Linux, macOS, and Windows (using an NFS client for Windows). Discuss the benefits and potential challenges of cross-platform file sharing with NFS.
10. Experiment with the exportfs command to view, refresh, and unexport shared directories on the NFS server. Describe how exportfs is used for real-time management of NFS shares and how it complements the configuration in the /etc/exports file.