Sometimes you just need an NFS server. This guide will show how to start a simple, albeit insecure (public read/write), NFSv4 server in a Docker container on a Raspberry Pi. I assume the Pi is all set up and ready to go and that you’ll use an external drive for storage. I also assume you’re at least familiar with parted or fdisk.

Prepare storage drive

(If you already have your external drive formatted and mounted, skip this section.)

Plug the external drive into the Pi. Use the tecmint article or linuxhint as guides for parted to create a single ext4 filesystem that takes up the whole disk. (fdisk also works, if you prefer.)

  • Use msdos partition table
  • Use ext4 filesystem
  • Start at 1
  • End at 1000GB

(0% and 100% also work.)

Once the partition is created, make the actual filesystem:

sudo mkfs.ext4 /dev/sda1

Now make sure it mounts on boot. Create a mount folder with mkdir -p /media/<drive_name>.

Then add a line in /etc/fstab:

#device   mountpoint          fstype options  dump fsck
/dev/sda1 /media/<drive_name> ext4   defaults 0    1

Reboot and check the output of lsblk to see that /dev/sda1 is mounted to /media/<drive_name>.

Set the permissions to allow anything: sudo chmod -R 777 /media/<drive_name>

Run Docker NFSv4 container

If you don’t have Docker installed, install it with:

sudo apt install -y docker.io && \
sudo systemctl enable docker && \
sudo usermod -aG docker $USER

Then run the container:

docker run \
  -d \
  -p 2049:2049 \
  -v /media/<drive_name>/:/nfsshare \
  -e SHARED_DIRECTORY=/nfsshare \
  --name nfs \
  --privileged \
  --restart unless-stopped \
  itsthenetwork/nfs-server-alpine:11-arm

More information about options/flags here.

Test from a Linux client

See relevant article.

  • On a Linux client, install nfs-common.
  • Create an empty folder for the mount point, e.g. ~/pi-nfs.
  • Mount the remote share with sudo mount <ip>:<exported_directory> <mount_point>
  • Touch a file and view it from the Pi, and/or use df -h to verify the share is mounted

The article also shows how to make a /etc/fstab entry for NFS shares, but using Autofs is probably a better choice if you want persistent network shares. NFS is still a good start toward using Autofs, though.

Example mount command:

sudo mount 192.168.0.40:/ ~/pi-nfs

For checking permissions of files on a share, ls -an gives UID/GID (specifically, the -n flag does this).

On permissions

NFS was created a long time ago in computer years, and by default, it uses simple Unix-style permissions. So if you have a file that belongs to UID 1001 on your share, and a user with UID 1001 happens to mount that share on their local machine, that user owns the file on the share. From the NFS server’s perspective, there’s no way to verify that said user actually owns that file–only that the UID seems to match, according to the user. User bob on one machine may have UID 1001, while user charlie has UID 1001 on a different machine; they both have access to the file on the share with UID 1001.

This is rife with security problems. One way to handle it would be to have whitelisted IPs (with perfect network security at layer 3, to prevent rogue machines from spoofing IPs–good luck) and perfect administration of each allowed IP so that users have the same UID across all machines on the network. Another approach, with NFSv4, is to use Kerberos to verify client identities instead of trusting them. Both options are a massive headache to get right.

For this reason, I recommend not using NFS unless you really need to, and if you do, avoid putting sensitive information on NFS shares. Use NFS for convenient filesharing among machines on your network, not for aggregated storage.