Learn NAS - NFS Sharing

#Introduction

If SMB is the protocol of the Windows world, then NFS (Network File System) is the protocol of the Unix-like and virtualization world. Episode 10 covers NFS comprehensively: how to define exports in /etc/exports, the differences between NFSv3 and v4, how to secure it with Kerberos, and how to use it as shared storage for hypervisors and containers.

NFS is the backbone of many infrastructures thanks to its high performance and simple model. Understanding NFS opens the door to major topics like Proxmox shared storage, Kubernetes persistent volumes, and development workloads that need direct mounts.

By the end of this episode you'll be able to create correct NFS exports, choose the right protocol version, apply Kerberos authentication, and integrate NFS into hypervisors and containers.

#The Exports Format in /etc/exports

#/etc/exports Basics

Every directory you want to share is registered in /etc/exports, one line per export. Each line contains a path, a client list, and options enclosed in parentheses.

/tank/data      192.168.1.0/24(rw,sync,no_subtree_check)
/tank/backup    10.0.20.0/24(ro,root_squash)

The first line shares /tank/data to the LAN subnet with read-write access; the second line shares /tank/backup read-only to the backup network. The root_squash option on the second line maps the client root to an unprivileged user, preventing privileged access.

#Refreshing Exports

After changing /etc/exports, the exports must be refreshed without restarting the service:

exportfs -ra
exportfs -v

The exportfs -ra command rewrites all exports, while exportfs -v lists the active exports along with the applicable options.

#NFSv3 versus NFSv4

#Main Differences

NFSv3 is a simple, widely supported protocol, but it lacks modern security features and semantics. NFSv4 brings integration with strong authentication, delegation support, and compound operations that reduce round trips.

/tank/data   192.168.1.0/24(rw,vers=4)

The vers=4 option restricts the export to NFSv4. For maximum compatibility with old clients, NFSv3 can still be kept, but the right direction is moving to NFSv4.

#Mounting with a Specific Version

On the client side, choose the protocol version when mounting. NFSv4 uses the fixed port 2049, making it more firewall-friendly than NFSv3, which uses dynamic ports.

sudo mount -t nfs -o vers=4.2 192.168.1.100:/tank/data /mnt/data

The mount -t nfs -o vers=4.2 command forces NFSv4.2, a version that supports features like copy offload and server-side copy.

#Kerberos Authentication

#Why Kerberos

Without Kerberos, NFS trusts the client's IP address and user ID. Kerberos adds verified identity so a user on the client is recognized as the same user on the server. This configuration requires a KDC (like Active Directory or MIT Kerberos) running on the network.

/tank/data   192.168.1.0/24(rw,sec=krb5)

The sec=krb5 option mandates Kerberos authentication for the export. The krb5p mode adds encryption on top of authentication, protecting data in transit.

#Applying It on TrueNAS SCALE

TrueNAS SCALE uses Kerberos through the directory service configuration and the nfs section in the Web UI. Once a ticket is obtained, clients can mount the export with Kerberos credentials:

kinit devnull@LAB.LAN
sudo mount -t nfs -o sec=krb5 192.168.1.100:/tank/data /mnt/data

The kinit command obtains a ticket from the KDC, then mount -o sec=krb5 uses that identity. Without a valid ticket, a mount with sec=krb5 is rejected.

#Nconnect and Throughput

#Increasing Parallelism

NFS historically limits one TCP connection per mount, which caps throughput on high-latency links. The nconnect option opens several parallel connections to take advantage of multiple cores and network paths.

sudo mount -t nfs -o nconnect=8 192.168.1.100:/tank/data /mnt/data

The nconnect=8 option opens eight parallel connections to the server. On 10GbE networks, this is often the difference between saturating the link or not.

#When to Use nconnect

nconnect is most effective for parallel workloads like large builds, databases, and many clients. For a single sequential process, one connection is enough. Common values range from 4 to 16; adjust to your core count and network throughput.

#NFS for Virtualization and Containers

#Shared Storage for Proxmox/KVM

NFS is the go-to shared storage for hypervisors. With NFS, all cluster nodes see the same dataset, enabling live VM migration without copying disks.

pvesm add nfs nas-tank --server 192.168.1.100 --export /tank/data

The pvesm add nfs command registers an NFS export as storage on Proxmox. VMs and templates can then be stored on top of it.

#Persistent Volumes in Kubernetes

In Kubernetes, NFS can be used as a simple PersistentVolume (PV) without a cloud provider. It's a practical choice for homelab clusters.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nas-pv
spec:
  capacity:
    storage: 500Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.100
    path: /tank/data

The YAML manifest above registers the NFS export as a PV that many pods can use at once. This ReadWriteMany pattern is a staple of shared storage for containers.

#Development Workflows

Many teams use NFS as a shared mount for development environments: code lives on the NAS and is accessed by all developer machines with automatic synchronization. Combining NFS with tools like Vagrant and Docker Desktop delivers much better speed than other volume types.

#Closing

In this episode 10 you mastered NFS: defining exports in /etc/exports, distinguishing NFSv3 and v4, applying Kerberos authentication with sec=krb5, using nconnect for throughput, and integrating NFS with hypervisors, Kubernetes, and development workflows.

Key takeaways:

• NFS exports are defined in /etc/exports and refreshed with exportfs -ra.
• NFSv4 is more secure and modern; NFSv3 is for old client compatibility.
• sec=krb5 verifies identity; krb5p adds encryption.
• nconnect opens parallel connections for parallel workloads.
• NFS is the foundation of virtualization and container shared storage.

In the next episode, episode 11, we'll cover iSCSI and block storage — from the target and initiator concepts, LUNs, CHAP authentication, to zvols as backing store and their use for VMware, Hyper-V, and Kubernetes PVs. NFS serves file needs; now it's block-level access's turn.