How NFS and RPC Enable Seamless File Sharing in Linux Environments

NFS — Shared Storage System

#network file system (NFS)

NFS is primarily used in local area networks to allow different hosts to share files or directories. It is a Linux‑based file‑sharing protocol whose clients are usually Linux machines. It has no built‑in user authentication and transmits data in clear text, so it is generally limited to LAN environments. No username/password is required; the configuration file simply lists the IP addresses of machines allowed to access the NFS server. Additional authentication plugins can be combined with NFS to improve security. NFS supports multi‑node mounting and concurrent writes.

RPC

#Remote Procedure Call (RPC) is a protocol that lets a program request services from a remote computer over a network without needing to understand the underlying network details.

#Local call: write code locally and run it on the same machine.
#Remote call: place the code on a remote server, invoke it from your computer, and receive the result over the network.

Relationship Between NFS and RPC

#NFS transfers data over the network using ports that are chosen randomly and can change. Because of this, NFS relies on the RPC protocol to negotiate and manage the communication.

NFS Workflow

1. After the NFS server starts, it registers its port information with the rpcbind service.
2. The NFS client connects to the server's rpcbind service via TCP/IP and obtains the specific port numbers.
3. The client sends the desired function call to the server using the obtained port.
4. The NFS server, through the rpc.nfsd process, checks whether the client has permission.
5. The rpc.mount process on the server verifies the client's operation rights.
6. Finally, the server translates the request into a local command, passes it to the kernel, and the kernel interacts with the hardware.

Conclusion: Communication between NFS clients and servers is based on the RPC protocol and requires the rpcbind service to be running.

rpcbind Process

* A user accesses a web application, which triggers an NFS file‑access request from the NFS client.
* The client’s RPC service contacts the NFS server’s RPC service on port 111 to request the NFS file‑access function.
* The NFS server’s RPC finds the registered NFS port and informs the client.
* The client now knows the correct port, connects to the NFS server, and performs the data operation.
* After the client finishes, it returns the result to the front‑end program, completing the request.

NFS Configuration

# NFS service configuration file: /etc/exports
# Syntax: <shared_directory> <client_address>(options)

# Client address types:
# *            : all clients
# 172.16.1.7    : a specific client
# 172.16.1.7/24 : an entire subnet
# 192.168.0.0/24(rw) 192.168.1.0/24(ro) : different permissions for different subnets

# Common export options:
# ro            : read‑only
# rw            : read‑write
# root_squash   : map root accesses on the client to the anonymous user (nfsnobody) on the server
# no_root_squash: keep root privileges (insecure, avoid using)
# all_squash    : map all client users to the anonymous user (commonly used for security)
# sync          : write data synchronously to memory and disk (safe but slower)
# async         : write to memory first, flush later (faster but risk of data loss)

# Example export line for production:
# /nfs/uoload 172.16.1.0/24(rw,sync,all_squash,anonuid=200,anongid=200)
# This grants read‑write access, synchronous writes, maps all users to nfsnobody, and forces all file ownership to UID/GID 200.

Key Commands

[root@nfs-31 ~]# showmount -e 172.16.1.31
Export list for 172.16.1.31:
/nfs/share *

[root@nfs-31 /nfs/share]# cat /etc/exports
/nfs/uoload 172.16.1.0/24(rw,sync,all_squash,anonuid=200,anongid=200)

[root@rsync-41 ~]# mount -t nfs 172.16.1.31:/home/chaoge /nfs_chaoge/

NFS Failure Cases

1. Client has not mounted NFS:
   # umount /usr/share/nginx/html
   # mount -t nfs 172.16.1.31:/nfs-nginx /usr/share/nginx/html/

2. Server side failure (NFS service down) causing web pages to hang:
   # systemctl restart nfs

3. After fixing the server, the client mount recovers automatically.

4. If the NFS server is completely down and cannot be restored quickly, force‑unmount the client:
   # mount -l | grep nfs   # check mounted NFS entries
   # umount -fl <mount_point>   # force unmount
   # Afterwards, focus on restoring the NFS service.

Source: https://www.cnblogs.com/sxy-blog/p/17514246.html (© original author)