Network file system (NFS)
Introduction to nfs
- NFS (Network File System), namely Network File System, is one of the file systems supported by FreeBSD. It allows computers in the network to share resources through TCP/IP network
- In NFS applications, local NFS client applications can transparently read and write files on remote NFS servers, just like accessing local files
- nfs is suitable for file sharing between Linux and Unix, but cannot realize file sharing between Linux and Windows
- nfs is a protocol running in the application layer, which listens on 2049/tcp and 2049/udp sockets
- nfs service can only authenticate based on IP
nfs features
- NFS (Network File System), namely Network File System, is one of the file systems supported by FreeBSD. It allows computers in the network to share resources through TCP/IP network
- In NFS applications, local NFS client applications can transparently read and write files on remote NFS servers, just like accessing local files
- nfs is suitable for file sharing between Linux and Unix, but cannot realize file sharing between Linux and Windows
- nfs is a protocol running in the application layer, which listens on 2049/tcp and 2049/udp sockets
- nfs service can only authenticate based on IP
Application scenarios of nfs
nfs has many practical application scenarios. Here are some common scenarios:
- Multiple machines share a CDROM or other device. This is cheaper and easier to install software on multiple machines
- In a large network, it may be convenient to configure a central NFS server to place the home directory of all users. These directories can be output to the network so that users can always get the same home directory no matter which workstation they log in on
- Different clients can watch video files on NFS to save local space
- The work data completed on the client can be backed up and saved to the user's own path on the NFS server
System composition of nfs
The nfs system has at least two main parts:
- An nfs server
- Several clients
The architecture of nfs system is as follows:
The client remotely accesses the data stored on the NFS server through the TCP/IP network
Before the NFS server is officially enabled, you need to configure some NFS parameters according to the actual environment and requirements
nfs working mechanism
nfs is based on rpc to realize network file system sharing. So let's talk about rpc first.
RPC
RPC (Remote Procedure Call Protocol), a Remote Procedure Call Protocol, is a protocol that requests services from remote computer programs through the network without understanding the underlying network technology.
RPC Protocol assumes the existence of some transmission protocols, such as TCP or UDP, to carry information data between communication programs. In the OSI network communication model, RPC spans the transport layer and application layer.
RPC adopts client / server mode. The requester is a client, and the service provider is a server.
The working mechanism of rpc is shown in the figure above. The following describes it:
- The client program initiates an RPC system call and sends it to another host (server) based on TCP protocol
- The server listens on a socket. After receiving the system call request from the client, it executes the received request and its passed parameters through the local system call, and returns the result to the local service process
- After receiving the returned execution result, the service process of the server encapsulates it into a response message, and then returns it to the client through rpc Protocol
- The client call process receives the reply information, gets the result of the process, and then calls the execution to proceed.
nfs working mechanism
//The NFS server side runs four processes:
nfsd
mountd
idmapd
portmapper
idmapd //Realize the centralized mapping of user accounts. All accounts are mapped to NFSNOBODY, but they can be accessed as local users
mountd //It is used to verify whether the client is in the list of clients allowed to access this NFS file system. If yes, access is allowed (issue a token and go to nfsd with the token). Otherwise, access is denied
//The service port of mountd is random, and the random port number is provided by the rpc service (portmapper)
nfsd //The nfs daemon listens on 2049/tcp and 2049/udp ports
//It is not responsible for file storage (the local kernel of NFS server is responsible for scheduling storage). It is used to understand the rpc request initiated by the client, transfer it to the local kernel, and then store it on the specified file system
portmapper //RPC service of NFS server, which listens on 111/TCP and 111/UDP sockets and is used to manage remote procedure calls (RPCs)
The following is an example to illustrate the simple workflow of NFS:
Requirement: view the information of the file, which is stored on the remote NFS server host (mounted in the local directory / shared/nfs)
- The client initiates an instruction to view file information (ls file) to the kernel. The kernel knows through the NFS module that this file is not a file in the local file system, but a file on the remote NFS host
- The kernel of the client host encapsulates the instruction (system call) to view the file information into an RPC request through the RPC Protocol and sends it to the portmapper of the NFS server host through port 111 of TCP
- The portmapper (RPC service process) of the NFS server host tells the client that the mountd service of the NFS server is on a certain port, and you go to it for verification
Because mountd must register a port number with portmapper when providing services, portmapper knows which port it works on
- After the client knows the mountd process port number of the server, it requests verification through the known mountd port number of the server
- After receiving the verification request, mountd verifies whether the requesting client is in the list of clients allowed to access the NFS file system. If it is, access is allowed (issue a token and go to nfsd with the token). Otherwise, access is denied
- After the verification is passed, the client holds the token issued by mountd to go to the nfsd process of the server and request to view a file
- The nfsd process on the server side initiates a local system call to request the kernel to view the information of the file to be viewed by the client
- The kernel of the server executes the system call of the nfsd request and returns the result to the nfsd service
- After receiving the result returned by the kernel, the nfsd process encapsulates it into rpc request message and returns it to the client through tcp/ip protocol
Format of exports file
The main configuration file of NFS is / etc/exports. In this file, you can define parameters such as output directory (i.e. shared directory), access permissions and accessible hosts of NFS system. The file is empty by default and is not configured to output any shared directories. This is based on security considerations. In this way, even if the system starts NFS, it will not output any shared resources.
Each line in the exports file provides the setting of a shared directory. The command format is:
<Output directory> [Client 1(Option 1,Option 2,...)] [Client 2(Option 1,Option 2,...)]
Except that the output directory is a required parameter, other parameters are optional. In addition, the output directory in the format is separated from the client, and between the client and the client, but there can be no space between the client and the option.
A client is a computer on the network that can access this NFS shared directory. The designation of the client is very flexible. It can be the IP or domain name of a single host, or the host in a subnet or domain.
Common client assignment methods:
| client | explain |
|---|---|
| 192.168.200.152 | Specify the host with the IP address |
| 192.168.200.154/24 (or 192.168.200. *) | Specify all hosts in the subnet |
| www.slyybw.com | Specify the host of the domain name |
| *.slyybw.com | Specify all hosts in the slyybw.com domain |
| *(or default) | All hosts |
Options are used to set access permissions, user mappings, and so on for shared directories. There are many options in the exports file, which can be divided into three categories:
- Access options (used to control access to shared directories)
- User mapping options
- By default, when the client accesses the NFS server, if the remote access user is root, the NFS server will map it to a local anonymous user (the user is nfsnobody) and its user group to an anonymous user group (the user group is also nfsnobody), which helps to improve the security of the system.
- Other options
Access options:
| Access options | explain |
|---|---|
| ro | Set output directory read-only |
| rw | Set output directory read / write |
User mapping options:
| User mapping options | explain |
|---|---|
| all_squash | Map all ordinary users and groups of remote access to anonymous users or user groups (nfsnobody) |
| no_all_squash | Do not map all ordinary users and user groups of remote access to anonymous users or user groups (default setting) |
| root_squash | Map the root user and its user group to anonymous users or user groups (default setting) |
| no_root_squash | The root user and the user group to which they belong are not mapped to anonymous users or user groups |
| anonuid=xxx | Map all users of remote access to anonymous users and specify the anonymous user as the local user account (UID=xxx) |
| anongid=xxx | Map all remote access user groups to anonymous user groups, and specify the anonymous user group as the local user group (GID=xxx) |
Other common options:
| Other options | explain |
|---|---|
| secure | Restrict clients to connect to NFS servers only from TCP/IP ports less than 1024 (default setting) |
| insecure | Allow clients to connect to NFS servers from TCP/IP ports greater than 1024 |
| sync | Writing data into memory buffer or disk synchronously is inefficient, but it can ensure data consistency |
| async | Save the data in the memory buffer before writing to disk if necessary |
| wdelay | Check whether there are related write operations. If so, these write operations are executed together to improve efficiency (default setting) |
| no_wdelay | If there is a write operation, it will be executed immediately. It should be used with sync configuration |
| subtree_check | If output directory is a subdirectory, NFS server checks permissions of the its parent directory (default) |
| no_subtree_check | Even if the output directory is a subdirectory, NFS does not check the permissions of its parent directory, which can improve efficiency |
| nohide | If you mount one directory on top of the another, original directory is usually hidden or appears empty. To disable this behavior, enable the hide option |
nfs management
// nfs installation:
yum -y install nfs-utils
// Start service
systemctl start rpcbind nfs-server
// Use the shoumount command to test the output directory status of the NFS server:
// Syntax: showmount [options] [NFS server name or address]
// Common options are:
-a #Displays all client hosts of the specified NFS server and the directories to which they are connected
-d #Displays all output directories connected by clients in the specified NFS server
-e #Displays the shared directory for all outputs on the specified NFS server
// Set the client to automatically mount nfs after startup: edit the / etc/fstab file and add the content in the following format
SERVER:/PATH/TO/EXPORTED_FS /mnt_point nfs defaults,_netdev 0 0
exportfs #Special tool for maintaining file system tables exported by exports file
-a #Output all directories set in the / etc/exports file
-r #Reread the settings in the / etc/exports file and make them take effect immediately without restarting the service
-u #Stop outputting a directory
-v #Displays the directory on the screen when outputting the directory
Check the options used by the output directory:
In the configuration file / etc/exports, even if only one or two options are set on the command line, there are actually many default options when actually outputting the directory. You can see what options are used by looking at the / var/lib/nfs/etab file
[root@localhost ~]# cat /var/lib/nfs/etab
case
1. Manually set up an nfs server
- Open the / nfs/shared directory for all users to consult materials
- The open / nfs/upload directory is the data upload directory of the 172.16.12.0/24 network segment, and maps all users and their user groups to NFS upload, with both UID and GID of 300
//Prepare two hosts, one as the server and the other as the client //client [root@localhost ~]# hostnamectl set-hostname client [root@localhost ~]# bash [root@client ~]# //Server [root@localhost ~]# hostnamectl set-hostname service [root@localhost ~]# bash [root@service ~]# //NFS utils should be installed on both the client and server [root@service ~]# yum -y install nfs-utils [root@client ~]# yum -y install nfs-utils //Start the server automatically [root@service ~]# systemctl enable --now nfs-server.service Created symlink /etc/systemd/system/multi-user.target.wants/nfs-server.service → /usr/lib/systemd/system/nfs-server.service. [root@service ~]# //Create / nfs/shared on the server side as a shared directory [root@service ~]# mkdir -p /nfs/shared [root@service ~]# //In the server nfs main configuration file / etc/exports, specify the shared directory, user, and permissions [root@service shared]# vim /etc/exports [root@service ~]# cat /etc/exports /nfs/shared *(ro) //Meet the requirements of the first question, open the / nfs/shared directory, and all users support read-only permission [root@service shared]# systemctl restart nfs-server.service //Return to the client to search the directory shared by the server [root@client ~]# showmount -e 192.168.200.152 Export list for 192.168.200.152: /nfs/shared * //Add a permanent mount in the last line of the client / etc/fstab file [root@client ~]# vim /etc/fstab 192.168.200.152:/nfs/shared /mnt nfs defaults,_netdev 0 0 [root@client ~]# mount -a [root@client ~]# df -h [root@client ~]# df -h file system Capacity used available used% Mount point devtmpfs 883M 0 883M 0% /dev tmpfs 900M 0 900M 0% /dev/shm tmpfs 900M 17M 884M 2% /run tmpfs 900M 0 900M 0% /sys/fs/cgroup /dev/mapper/rhel-root 46G 2.9G 43G 7% / /dev/nvme0n1p1 1014M 179M 836M 18% /boot tmpfs 180M 0 180M 0% /run/user/0 192.168.200.152:/nfs/shared 50G 4.5G 46G 9% /mnt //Verify the effect, return to the server, write a file in the shared directory, and return to the client for access [root@service shared]# pwd /nfs/shared [root@service shared]# vim test [root@service shared]# cat test hello world!!! [root@service shared]# //To client access [root@client ~]# cd /mnt/ [root@client mnt]# ls test [root@client mnt]# cat test hello world!!! [root@client mnt]# vim test [root@client mnt]# rm -rf test rm: Cannot delete'test': Read-only file system [root@client mnt]# mkdir 111 mkdir: Unable to create directory '111': Read-only file system [root@client mnt]# ll Total consumption 4 -rw-r--r-- 1 root root 15 9 June 25-17:10 test
// Second, open the / nfs/upload directory [root@service nfs]# mkdir upload [root@service nfs]# ls shared upload [root@service nfs]# //Create user NFS upload on the server and set uid and gid to 300 [root@service ~]# useradd -u 300 nfs-upload [root@service ~]# id nfs-upload uid=300(nfs-upload) gid=1001(nfs-upload) groups=1001(nfs-upload) [root@service ~]# groupmod -g 300 nfs-upload [root@service ~]# id nfs-upload uid=300(nfs-upload) gid=300(nfs-upload) groups=300(nfs-upload) [root@service ~]# setfacl -m u:nfs-upload:rwx /nfs/upload [root@service ~]# //In the nfs main configuration file / etc/exports on the server side, specify the shared directory, network segment and permissions. The user groups to which they belong are mapped to nfs upload, and their UID and GID are 300 [root@service ~]# vim /etc/exports [root@service ~]# cat /etc/exports /nfs/shared *(ro) /nfs/upload 192.168.200.0/24(rw,anonuid=300,anongid=300) [root@service ~]# systemctl restart nfs-server.service //Search the shared directory of the server on the client [root@client ~]# showmount -e 192.168.200.152 Export list for 192.168.200.152: /nfs/shared * /nfs/upload 192.168.200.0/24 [root@client ~]# //Add a permanent mount in the last line of the client / etc/fstab file [root@client ~]# vim /etc/fstab 192.168.200.152:/nfs/upload /abc nfs defaults,_netdev 0 0 //Create a mount point [root@client ~]# mkdir /abc [root@client ~]# mount -a [root@client ~]# df -h file system Capacity used available used% Mount point devtmpfs 883M 0 883M 0% /dev tmpfs 900M 0 900M 0% /dev/shm tmpfs 900M 17M 884M 2% /run tmpfs 900M 0 900M 0% /sys/fs/cgroup /dev/mapper/rhel-root 46G 2.9G 43G 7% / /dev/nvme0n1p1 1014M 179M 836M 18% /boot tmpfs 180M 0 180M 0% /run/user/0 192.168.200.152:/nfs/shared 50G 4.5G 46G 9% /mnt 192.168.200.152:/nfs/shared 50G 4.5G 46G 9% /abc [root@client ~]# //Verification effect [root@client ~]# cd /abc/ [root@client abc]# ls [root@client abc]# mkdir 123 [root@client abc]# ll Total consumption 0 drwxr-xr-x 2 300 300 6 9 June 25-17:15 123 //Return to the server to view [root@service ~]# cd /nfs/upload/ [root@service upload]# ls 123 [root@service upload]# ll total 0 drwxr-xr-x 2 nfs-upload nfs-upload 6 Sep 25 17:15 123