Installation and configuration of NFS service in Linux Environment

Article catalogue

1. NFS introduction

NFS is the abbreviation of network file system. As its name suggests, it is the network file storage system. It was first developed by Sun company. It is also one of the file systems supported by FreeBSD. It allows computers in the network to share resources through TCP/IP network. Through NFS, our local NFS client applications can transparently read and write files on the server NFS server, just as convenient as accessing local files. In short, NFS is a service that allows different hosts and different operating systems to share storage through the network.

In the process of file transfer or information transfer, NFS relies on RPC (Remote Procedure Call) protocol, that is, Remote Procedure Call. All functions of NFS must be registered with RPC. In this way, RPC can understand the functions of NFS, such as Port, PID, IP monitored by NFS on the server, and the client can find the correct corresponding Port through RPC query. Therefore, NFS can successfully provide services only when RPC exists. Simply understand the relationship between NFS and RPC: NFS is a file storage system, and RPC is responsible for information transmission.

2. Environment and software preparation

In this demonstration environment, I install Linux system on the virtual machine to perform the operation. The following is the installed software and version:

  • Oracle VirtualBox: 5.1.20 r114628 (Qt5.6.2)
  • System: CentOS Linux release 7.3.1611 (Core)
  • rpcbind: 0.2.0-38.el7.x86_64
  • nfs-utils: 1.3.0-0.54.el7.x86_64

3. Services for NFS installation

Through the above brief introduction, we know that service for NFS needs to rely on RPC service, so here, the NFS server needs to install rpcbind and NFS utils, and the client only needs to install NFS utils. Since I choose CentOS system, I can use yum to install quickly.

First, confirm whether the lower server system has NFS installed.

$ rpm -qa nfs-utils rpcbind
nfs-utils-1.3.0-0.54.el7.x86_64
rpcbind-0.2.0-38.el7.x86_64

Note: I have completed the installation here. If it is empty, it indicates that it is not installed.

Then, install services for NFS

# Server
$ yum install -y nfs-utils rpcbind
# client
$ yum install -y nfs-utils

Another installation command for Ubuntu 16.04 is:

# Server
apt install nfs-kernel-server
# client
apt install nfs-common

4. NFS configuration and use

We create a shared directory / data/share on the server side as the remote entry for the client to mount, and then set the permissions.

$ mkdir -p /data/share
$ chmod 666 /data/share

Then, modify the NFS configuration file / etc/exports

$ vim /etc/exports
/data/share 10.222.77.0/24(rw,sync,insecure,no_subtree_check,no_root_squash)

To explain, there are many parameters behind the configuration here, and each parameter has different meanings. For details, please refer to the following. Here, I configured the / data/share file directory to allow clients with IP in the 10.222.77.0/24 range to mount. Of course, if the client IP is not in the range and wants to mount, you can set the IP range to be larger or set it to * to allow all clients to mount. For example, / home * (RO, sync, secure, no_root_square) set the / home directory to allow all clients to mount read-only.

parameter explain
ro read-only access
rw Read write access
sync All data is written to the share on request
async nfs can respond to requests before writing data
secure nfs is sent through secure TCP/IP ports below 1024
insecure nfs is sent through ports above 1024
wdelay If multiple users want to write to the nfs directory, write as a group (default)
no_wdelay If multiple users want to write to the nfs directory, write immediately. This setting is not required when async is used
hide Do not share its subdirectories in the nfs shared directory
no_hide Subdirectories of shared nfs directory
subtree_check When sharing subdirectories such as / usr/bin, force nfs to check the permissions of the parent directory (default)
no_subtree_check Do not check parent directory permissions
all_squash UID and GID of shared file map anonymous user anonymous, which is suitable for public directory
no_all_squash Keep UID and GID of shared files (default)
root_squash All requests of the root user are mapped to the same permissions as the anonymous user (default)
no_root_squash The root user has full administrative access to the root directory
anonuid=xxx Specifies the UID of the anonymous user in the / etc/passwd file of the nfs server
anongid=xxx Specifies the GID of the anonymous user in the / etc/passwd file of the nfs server

Next, let's start the RPC service.

$ service rpcbind start
# Or you can use the following command
$ /bin/systemctl start rpcbind.service

# View the list of ports registered by rpc server of NFS service item
$ rpcinfo -p localhost 
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper

Now, let's take a look at the list of NFS service 111 ports that haven't been started. Let's just look at the list of NFS service 111 ports that haven't been started.

# Start NFS service
$ service nfs start
# Or you can use the following command
/bin/systemctl start nfs.service

# After starting service for NFS, rpc service has enabled port mapping list for NFS
# rpcinfo -p localhost
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  33745  status
    100024    1   tcp  36980  status
    100005    1   udp  20048  mountd
    100005    1   tcp  20048  mountd
    100005    2   udp  20048  mountd
    100005    2   tcp  20048  mountd
    100005    3   udp  20048  mountd
    100005    3   tcp  20048  mountd
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    3   udp   2049  nfs_acl
    100021    1   udp  38960  nlockmgr
    100021    3   udp  38960  nlockmgr
    100021    4   udp  38960  nlockmgr
    100021    1   tcp  38362  nlockmgr
    100021    3   tcp  38362  nlockmgr
    100021    4   tcp  38362  nlockmgr

We found that after the NFS service was started, the port list registered by rpc increased significantly. OK now that the server is started, check whether the set / etc/exports configuration is loaded correctly on the server.

$ showmount -e localhost
Export list for localhost:
/data/share 10.222.77.0/24

5. NFS test

Finally, test whether it can be mounted correctly on another Linux virtual machine. First, we can view the shared directory information of the NFS server (the IP of the upper server is 10.222.77.86) on the client.

# showmount -e 10.222.77.86
Export list for 10.222.77.86:
/data/share 10.222.77.0/24

Then, create the hanging directory / share on the client

$ mkdir -p /share

Finally, mount the remote directory to the local / share directory.

$ mount 10.222.77.86:/data/share /share
$ df -h | grep 10.222.77.86
Filesystem                 Size  Used  Avail Use% Mounted on
10.222.77.86:/data/share   27G   11G   17G   40%  /share

As you can see, the remote NFS directory can be mounted locally correctly. Note: the mount point / share directory must already exist and there are no files or subdirectories in the directory.

Finally, we create a file in the / data/share directory of the NFS server to see if the client can read and modify it correctly.

# Server write
$ echo "This is NFS server." > /data/share/nfs.txt
# ll /data/share/
total 4
-rw-r--r-- 1 root root 20 Nov  5 16:49 nfs.txt

# Client read
$ ll /share/
total 4
-rw-r--r-- 1 root root 20 Nov  5 16:49 nfs.txt
$ cat /share/nfs.txt
This is NFS server.

# Client write
$ echo "This is NFS client." >> /share/nfs.txt

# Server read
$ cat /data/share/nfs.txt
This is NFS server.
This is NFS client.

This is because the NFS remote directory permission is set to rw and has read-write permission. If it is set to ro, the client can only read and cannot write. It is reasonably configured according to the actual application scenario, so it will not be demonstrated here. It is mentioned here that NFS is mounted using UDP protocol by default. In order to improve the stability of NFS, TCP protocol can be used for mounting. The following commands can be used for client mounting commands:

$ mount 10.222.77.86:/data/share /share -o proto=tcp -o nolock

Finally, if the client wants to uninstall NFS mount, use the following command.

$ umount /share

Well, the above briefly introduces the installation, configuration and use of NFS. Using it, we can easily share storage with different hosts and operating systems through the network. Next, we continue to study various ways to mount NFS in Kubernetes cluster to mount network file storage system.

Posted by glory452 on Sat, 21 May 2022 14:56:07 +0300