Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to turn the raspberry pie home laboratory into a network file system. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

A shared file system is a good way to add versatility and functionality to home labs. Sharing a centralized file system for clients in the lab makes it quite easy to organize data, back up, and share data. This is particularly useful for Web applications that load balance across multiple servers and persistent volumes used by Kubernetes because it allows Pod to be rotated with persistent data on any number of nodes.

Whether your home lab is made up of regular computers, redundant corporate servers, or raspberry pies or other single board computers (SBC), shared file systems are a useful asset, and network file system (NFS) servers are a good way to create shared file systems.

I've written about building a "home private cloud", a home lab made up of raspberry pie or other SBC, and maybe some other consumer hardware or desktop PC. The NFS server is an ideal way to share data between these components. Since most SBC operating systems run through SD cards, there are some challenges. Especially when used as the operating system disk of a computer, the failure rate of SD cards will increase, and they are not used to read and write continuously. What you really need is a real hard drive: they are usually cheaper per GB than SD cards, especially for larger disks, and they are less likely to continue to fail. Raspberry pie 4 now comes with a USB 3.0 interface, and USB 3.0 hard drives are ubiquitous and affordable. This is a perfect match. In this project, I plugged a USB 3.0 external hard drive using 2TB into Raspberry Pie 4 running a NFS server.

Raspberry Pi with a USB hard disk

Install NFS server software

I run the Fedora server on the raspberry pie, but this project can also run on other distributions. To run the NFS server on Fedora, you need the nfs-utils package, which is fortunately installed (at least in Fedora 31). If you are going to run the NFSv3 service, you also need the rpcbind package, but it is not a strict requirement for NFSv4.

If you don't already have these packages on your system, use the dnf command to install them.

# install nfs-utils and rpcbind$ sudo dnf install nfs-utils rpcbind

Raspbian is another popular operating system used with raspberry pie, with almost exactly the same settings. The package names are different, but this is the only major difference. To install the NFS server on a system running Raspbian, you need the following software packages.

Nfs-common: these files are common to NFS servers and clients.

Nfs-kernel-server: the main NFS server software package.

Raspbian uses apt-get to manage packages (instead of using dnf as Fedora does), so use it to install packages.

# for Raspbian systems, use apt-get to install the NFS package $sudo apt-get install nfs-common nfs-kernel-server to prepare a USB hard disk as a storage device

As I mentioned above, USB hard drives are a good choice for storage for raspberry pies or other SBC, especially SD cards for operating system disk mirroring. For home private clouds, you can use cheap USB 3.0hard drives for large-scale storage. Insert the disk, use fdisk to find out the device ID assigned to it, and you can use it to work.

# find your hard drive using fdisk # irrelevant hard disk information has been omitted $sudo fdisk-l Disk / dev/sda: 1.84 TiB, 2000398933504 bytes, 3907029167 sectorsDisk model: BUP Slim BKUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: dosDisk identifier: 0xe3345ae9 Device Boot Start End Sectors Size Id Type/dev/sda1 2048 3907028991 3907026944 1.8T 83 Linux

For clarity, in the example output above, I omitted the information on all the other disks except the one I was interested in. You can see that the USB disk I want to use is assigned a device / dev/sda, and you can see some information about the model (Disk model: BUP Slim BK), which helps me identify the correct disk. The disk already has a partition, and its size confirms that it is the disk I am looking for.

Note: please make sure that the disks and partitions of your device are correctly identified. It may be different from the example above.

Each partition created on the drive has a special universal unique identifier (UUID). The computer uses UUID to ensure that it uses the / etc/fstab configuration file to mount the correct partition to the correct location. You can use the blkid command to retrieve the UUID of the partition.

# get the block device attributes of the partition # make sure you use the appropriate partition, it should be different. $sudo blkid / dev/sda1 / dev/sda1: LABEL= "backup" UUID= "bd44867c-447c-4f85-8dbf-dc6b9bc65c91" TYPE= "xfs" PARTUUID= "e3345ae9-01"

Here, the UUID of / dev/sda1 is bd44867c-447c-4f85-8dbf-dc6b9bc65c91. Your UUID will be different, so write it down.

Configure raspberry pie to mount this disk at startup, and then mount it

Now that you have identified the disk and partition to use, you need to tell the computer how to mount it, and do so every time you boot. Mount it now. Because this is a USB disk, it may be unplugged, so you also need to configure the raspberry pie not to wait if the disk is not plugged in or other unavailable conditions.

In Linux, tell the computer what to do with it by adding the partition to the / etc/fstab configuration file, including where you want it to be mounted and some parameters. This example will mount the partition to / srv/nfs, so create this path first:

# create the mount point of the disk partition $sudo mkdir-p / srv/nfs

Next, modify the / etc/fstab file using the following syntax format:

Use the UUID you identified earlier as the disk ID. As I mentioned in the previous step, the mount point is / srv/nfs. For the file system type, it is usually best to choose its actual file system, but because this is a USB disk, use auto.

For option values, use nosuid,nodev,nofail.

A narrator about the manual page

In fact, there are many possible options, and the man page (man) is the best way to view them. Looking at the man pages of fstab is a good start.

# Open the manual page of fstab $man fstab

This opens the manual / documentation related to the fstab command. In the man page, each option is broken down into different content to show its role and common choices. For example, "the fourth field (fs_mntopts)" gives some basic information about the options available in this field and guides you to man 8 mount for a more in-depth description of the mount options. This makes sense, because the / etc/fstab file essentially tells the computer how to mount the disk automatically, just as you use the mount command manually.

You can get more information about the options you will use from the mount man page. The number 8 represents the chapter of the man page. In this case, Chapter 8 is the system management tools and daemons.

You can get a list of standard chapters from the man man page.

Back to the mount disk, let's take a look at man 8 mount.

# Open the mount manual page $man 8 mount in Chapter 8

In this man page, you can see the effects of the options listed above.

Nosuid: ignore the suid/guid bit. Any files placed on USB drives are not allowed to be executed as root. This is a good security practice.

Nodev: do not recognize characters or block special devices in the file system, that is, ignore any device nodes on the U disk. Another good security practice.

Nofail: do not log any errors if the device does not exist. This is a U disk and may not be inserted, so in this case, it will be ignored.

Go back to the line you are adding to the / etc/fstab file, and finally there are two options: fs_freq and fs_passno. Their values are related to some outdated options, and most modern systems only use 0 for both options, especially for file systems on USB disks. The value of fs_freq is related to the dump command and the dump of the file system. The value of fs_passno defines the file system to be fsck at startup and its order. If this value is set, the root partition is usually 1 and the other file system is 2. Set this value to 0 to skip using fsck on that partition.

In your favorite editor, open the / etc/fstab file, add the entry for the partition on the U disk, and replace the value here with the value obtained in the previous step.

# With sudo, or as root, add the partition info to the / etc/fstab fileUUID= "bd44867c-447c-4f85-8dbf-dc6b9bc65c91" / srv/nfs auto nosuid,nodev,nofail,noatime 0 enable and start the NFS server

After installing the package and adding partitions to your / etc/fstab file, you can now start the NFS server. In a Fedora system, you need to enable and start two services: rpcbind and nfs-server. Use the systemctl command to do this.

# start NFS server and rpcbind$ sudo systemctl enable rpcbind.service$ sudo systemctl enable nfs-server.service$ sudo systemctl start rpcbind.service$ sudo systemctl start nfs-server.service

On Raspbian or other Debian-based distributions, you only need to use the systemctl command to enable and start the nfs-kernel-server service, as above.

RPCBind

The rpcbind tool is used to map a remote procedure call (RPC) service to the port it listens on. According to the rpcbind man pages:

"when a RPC service starts, it tells rpcbind the address it is listening to and the RPC program number it is preparing for the service. When the client wants to make a RPC call to a given program number, it first contacts the rpcbind on the server machine to determine the address where the RPC request should be sent."

In the case of the NFS server, rpcbind maps the protocol number of the NFS to the port on which the NFS server listens. However, NFSv4 does not need to use rpcbind. If you only use NFSv4 (by removing version 2 and version 3 from the configuration), you don't need to use rpcbind. I put it here for backward compatibility with NFSv3.

Export mounted file system

The NFS server decides which remote clients to share (export) which file systems with based on another configuration file / etc/exports. This file is just an IP (or subnet) mapping to the file system to be shared, as well as some options (read-only or read-write, root removal, etc.). The format of the file is:

(option)

In this example, you mount the export to the partition of / srv/nfs. This is the "contents" section.

The second part, the host, including the host to which you want to export this partition. These hosts can be a single host: specified with a fully qualified domain name (FQDN) or host name, host IP address, or a set of hosts: use wildcard characters to match domains (such as * .example.org), IP networks (such as classless inter-domain routing CIDR identities), or netgroup representations.

The third part includes the options applied to the export.

Ro/rw: export the file system as read-only or read-write.

Wdelay: if another write is about to take place, defer writing to the disk to improve performance (this may be less useful if you are using a solid-state USB disk)

Root_squash: prevent any root user on the client from having root privileges on the host, and set root UID to nfsnobody as a security precaution.

The test exports the partition you mounted at / srv/nfs to a client-- for example, a laptop. Determine the IP address of your client (my laptop is 192.168.2.64, but yours may be different). You can share it to a large subnet, but for testing, limit it to a single IP address. The CIDR logo of this IP is 192.168.2.64 Universe 32 which represents an IP.

Edit the / etc/exports file using your favorite editor and write down your directory, host CIDR, and rw and root_squash options.

# Edit your / etc/exports file like this and replace it with information on your system / srv/nfs 192.168.2.64Unix32 (rw,root_squash)

Note: if you copy the / etc/exports file from another place, or overwrite the original file with a copy, you may need to restore the SELinux context of the file. You can use the restorecon command to restore.

# restore the SELinux context of / etc/exports file $sudo restorecon / etc/exports

When finished, restart the NFS server to receive changes to the / etc/exports file.

# restart the NFS server $sudo systemctl restart nfs-server.service, open the firewall for the NFS service

Some systems do not run firewall services by default. For example, Raspbian defaults to open iptables rules, and ports opened by different services can be used immediately outside the machine. By contrast, the Fedora server runs the firewalld service by default, so you have to open the port for the NFS server (and rpcbind, if you will use NFSv3). You can do this through the firewall-cmd command.

Check the area used by firewalld and get the default area. For Fedora servers, this is the FedoraServer zone.

# list areas # omitted part of the output $sudo firewall-cmd for brevity-- list-all-zones # R to get default zone information # write down the default area $sudo firewall-cmd-- get-default-zone # permanently join the nfs service to the list of allowed ports $sudo firewall-cmd-- add-service=nfs-- permanent # for NFSv3 We need to add some more ports: nfsv3, rpc-mountd, rpc-bind$ sudo firewall-cmd-- add-service= (nfs3,mountd,rpc-bind) # to see the services in the default area and replace $sudo firewall-cmd-- list-services-- zone=FedoraServer # with the default area used in your system. # if everything is all right, overload firewalld$ sudo firewall-cmd-- reload

In this way, you have successfully configured the NFS server with your mounted USB disk partition and exported it to your test system for sharing. Now you can test mount it on the system you added to the export list.

Test NFS export

First, from the NFS server, create a file to read in the / srv/nfs directory.

# create a test file to share echo "Can you see this?" > / srv/nfs/nfs_test

Now, on the client system that you added to the export list, first make sure that the NFS client package is installed. On Fedora systems, it is a nfs-utils package that can be installed with dnf. The Raspbian system has a libnfs-utils package that can be installed with apt-get.

Install the NFS client package:

# install nfs-utils package $sudo dnf install nfs-utils with dnf

Once the client package is installed, you can test the export of NFS. Also on the client side, use the mount command with the NFS server IP and the export path and mount it to a location on the client, in this case the / mnt directory. In this example, the IP of my NFS server is 192.168.2.109, but yours may be different.

# Mount the output of the NFS server to the client host # be sure to replace it with the corresponding information of your host $sudo mount 192.168.2.109:/srv/nfs / mnt # check whether the nfs_test file is visible $cat / mnt/nfs_testCan you see this? This is the end of the article on "how to turn the raspberry pie home laboratory into a network file system". I hope the above content can be helpful to you, so that you can learn more knowledge. If you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.