Setting up an NFS (Network File System) mount on Ubuntu 24 might seem like a daunting task, but it’s actually one of the most elegant solutions for sharing files across multiple Linux systems in your network. Whether you’re managing a cluster of servers, setting up a development environment, or just want to centralize your storage, NFS allows you to mount remote directories as if they were local filesystems. This guide will walk you through everything from the basic concepts to advanced configurations, complete with real-world examples and troubleshooting tips that’ll save you hours of head-scratching. By the end of this post, you’ll have a solid understanding of how to implement NFS properly and avoid the common pitfalls that catch most people off guard.

How NFS Actually Works Under the Hood

NFS operates on a client-server model where one machine (the server) exports directories, and other machines (clients) mount these directories over the network. Think of it as creating a tunnel between filesystems – when you write to what appears to be a local directory, the data actually travels over the network and gets stored on the remote server.

The magic happens through a series of RPC (Remote Procedure Call) services:

• rpcbind – Acts as the traffic director, mapping RPC services to network ports
• nfs-server – The main NFS daemon that handles file operations
• rpc.mountd – Manages mount requests and exports
• rpc.nfsd – The kernel-level NFS daemon (usually multiple instances)

NFS has evolved significantly over the years. While NFSv2 was painfully slow and NFSv3 improved performance considerably, NFSv4 (which we’ll focus on) brought major improvements including better security, stateful operations, and built-in locking mechanisms. The performance difference is substantial – NFSv4 can be up to 30% faster than NFSv3 in typical workloads.

Step-by-Step NFS Setup Guide

Let’s dive into the practical stuff. I’ll assume you have two Ubuntu 24 machines: one server (192.168.1.100) and one client (192.168.1.101). If you need additional servers for testing, consider grabbing a VPS or dedicated server for more serious production setups.

Server Side Configuration

First, let’s get the NFS server up and running:

# Update package list
sudo apt update

# Install NFS server packages
sudo apt install nfs-kernel-server -y

# Create directories to share
sudo mkdir -p /srv/nfs/shared
sudo mkdir -p /srv/nfs/projects

# Set proper ownership and permissions
sudo chown nobody:nogroup /srv/nfs/shared
sudo chown nobody:nogroup /srv/nfs/projects
sudo chmod 755 /srv/nfs/shared
sudo chmod 755 /srv/nfs/projects

Now comes the crucial part – configuring the exports. Edit the `/etc/exports` file:

sudo nano /etc/exports

Add your export configurations. Here are some practical examples:

# Basic read-write share for a specific client
/srv/nfs/shared 192.168.1.101(rw,sync,no_subtree_check)

# Share with multiple clients using subnet notation
/srv/nfs/projects 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

# Read-only share for backup purposes
/srv/nfs/backups 192.168.1.0/24(ro,sync,no_subtree_check)

# High-performance share with async writes (use carefully!)
/srv/nfs/temp 192.168.1.101(rw,async,no_subtree_check,no_root_squash)

Let’s break down these options:

• rw/ro – Read-write or read-only access
• sync – Writes are committed to storage before responding (safer but slower)
• async – Writes are cached (faster but riskier)
• no_subtree_check – Disables subtree checking for better performance
• no_root_squash – Allows root user on client to have root privileges on the share
• root_squash – Maps root user to anonymous user (default, more secure)

Apply the configuration and start services:

# Apply the new exports
sudo exportfs -a

# Start and enable NFS services
sudo systemctl start nfs-kernel-server
sudo systemctl enable nfs-kernel-server

# Verify exports are active
sudo exportfs -v

Client Side Configuration

On the client machine, the setup is much simpler:

# Install NFS client utilities
sudo apt update
sudo apt install nfs-common -y

# Create mount points
sudo mkdir -p /mnt/nfs/shared
sudo mkdir -p /mnt/nfs/projects

# Test the connection first
showmount -e 192.168.1.100

# Mount the shares
sudo mount -t nfs4 192.168.1.100:/srv/nfs/shared /mnt/nfs/shared
sudo mount -t nfs4 192.168.1.100:/srv/nfs/projects /mnt/nfs/projects

# Verify mounts
df -h | grep nfs

For permanent mounts, edit `/etc/fstab`:

sudo nano /etc/fstab

Add these lines:

192.168.1.100:/srv/nfs/shared /mnt/nfs/shared nfs4 defaults,_netdev 0 0
192.168.1.100:/srv/nfs/projects /mnt/nfs/projects nfs4 defaults,_netdev 0 0

The `_netdev` option ensures the mount waits for network connectivity before attempting to mount during boot.

Real-World Examples and Use Cases

Performance Optimization Scenarios

Let’s look at some performance-tuned configurations for different scenarios:

Use Case	Mount Options	Export Options	Performance Impact
Database Storage	rsize=8192,wsize=8192,hard,intr	sync,no_subtree_check	High reliability, moderate speed
Media Streaming	rsize=65536,wsize=65536,soft,timeo=14	async,no_subtree_check	High throughput, some risk
Development Files	rsize=32768,wsize=32768,hard	sync,no_subtree_check	Balanced performance
Backup Storage	rsize=131072,wsize=131072,soft	async,no_subtree_check	Maximum throughput

High-Performance Setup Example

For a high-throughput scenario (like a video processing cluster), here’s an optimized configuration:

# Server side - /etc/exports
/srv/media 192.168.1.0/24(rw,async,no_subtree_check,no_root_squash,fsid=0)

# Client side mount command
sudo mount -t nfs4 -o rsize=131072,wsize=131072,hard,timeo=600,retrans=2 \
  192.168.1.100:/srv/media /mnt/media

This configuration can achieve throughput of 800-900 MB/s on gigabit networks, compared to 200-300 MB/s with default settings.

Security-Focused Configuration

For environments where security is paramount:

# Server side with Kerberos authentication
/srv/secure 192.168.1.0/24(rw,sync,sec=krb5p,no_subtree_check)

# Client mount with encryption
sudo mount -t nfs4 -o sec=krb5p 192.168.1.100:/srv/secure /mnt/secure

Common Failure Scenarios and Solutions

Problem: “mount.nfs: access denied by server while mounting”

# Check if exports are properly configured
sudo exportfs -v

# Verify firewall settings
sudo ufw status
sudo ufw allow from 192.168.1.0/24 to any port nfs

# Check if client IP is correct in exports
sudo tail -f /var/log/syslog

Problem: Extremely slow performance

# Check current mount options
mount | grep nfs

# Benchmark with different settings
time dd if=/dev/zero of=/mnt/nfs/testfile bs=1M count=100

# Monitor network utilization
sudo iftop -i eth0

Problem: Stale file handles after server restart

# Force unmount on client
sudo umount -f /mnt/nfs/shared

# Clear stale handles
sudo umount -l /mnt/nfs/shared

# Remount
sudo mount -a

Advanced Integration and Automation

Docker Integration

NFS works beautifully with Docker for persistent volume storage:

# Create Docker volume using NFS
docker volume create --driver local \
  --opt type=nfs \
  --opt o=addr=192.168.1.100,rw \
  --opt device=:/srv/nfs/docker \
  nfs-volume

# Use in container
docker run -v nfs-volume:/data ubuntu:24.04

Kubernetes Integration

For Kubernetes environments, you can create persistent volumes:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.100
    path: /srv/nfs/k8s

Automated Failover Setup

Here’s a simple bash script for NFS failover monitoring:

#!/bin/bash
# nfs-monitor.sh

PRIMARY_NFS="192.168.1.100"
BACKUP_NFS="192.168.1.200"
MOUNT_POINT="/mnt/nfs/shared"
NFS_PATH="/srv/nfs/shared"

check_nfs() {
    timeout 5 ls "$MOUNT_POINT" >/dev/null 2>&1
    return $?
}

failover_to_backup() {
    echo "Primary NFS failed, switching to backup..."
    sudo umount "$MOUNT_POINT"
    sudo mount -t nfs4 "$BACKUP_NFS:$NFS_PATH" "$MOUNT_POINT"
}

while true; do
    if ! check_nfs; then
        failover_to_backup
    fi
    sleep 30
done

Performance Tuning and Monitoring

NFS performance can be significantly improved with proper tuning. Here are some key metrics to monitor:

# Monitor NFS statistics
nfsstat -c  # Client stats
nfsstat -s  # Server stats

# Check network utilization
sar -n DEV 1 5

# Monitor I/O patterns
iostat -x 1 5

Server-side tuning in `/etc/default/nfs-kernel-server`:

# Increase number of server threads
RPCNFSDCOUNT=16

# Tune RPC slot table entries
echo 128 > /proc/sys/sunrpc/tcp_slot_table_entries
echo 128 > /proc/sys/sunrpc/udp_slot_table_entries

Comparison with Alternative Solutions

Solution	Performance	Complexity	Cross-platform	Best Use Case
NFS	Good (800MB/s+)	Medium	Linux/Unix focused	Linux clusters, development
CIFS/SMB	Moderate (400MB/s)	Low	Excellent	Mixed Windows/Linux environments
GlusterFS	Excellent (1GB/s+)	High	Good	Distributed storage, high availability
Ceph	Excellent (1GB/s+)	Very High	Good	Large scale storage clusters

Security Considerations and Best Practices

NFS security has historically been its weakest point, but modern implementations offer several improvement options:

# Enable firewall rules
sudo ufw allow from 192.168.1.0/24 to any port 2049
sudo ufw allow from 192.168.1.0/24 to any port 111

# Use specific UIDs/GIDs mapping
echo "1000 65534" > /etc/nfs.map
# Add to exports: map_static=/etc/nfs.map

# Enable NFSv4 with Kerberos (advanced)
sudo apt install krb5-user nfs-common
# Configure /etc/krb5.conf and /etc/idmapd.conf

Troubleshooting Common Issues

Here’s a comprehensive troubleshooting checklist:

# Test basic connectivity
ping 192.168.1.100
telnet 192.168.1.100 2049

# Check NFS services status
sudo systemctl status nfs-kernel-server
sudo systemctl status rpcbind

# Verify exports
sudo exportfs -v
showmount -e 192.168.1.100

# Check logs for errors
sudo journalctl -u nfs-kernel-server -f
sudo tail -f /var/log/syslog | grep nfs

# Test permissions
sudo -u nobody touch /srv/nfs/shared/test
ls -la /srv/nfs/shared/test

Future-Proofing and New Possibilities

NFS continues to evolve, with interesting developments on the horizon:

• NFSv4.2 introduces features like server-side copy, sparse files, and application data block (ADB) support
• pNFS (parallel NFS) allows clients to access storage devices directly, bypassing the server for data transfers
• NFS over RDMA provides ultra-low latency for high-performance computing environments
• Container integration is becoming more seamless with Kubernetes CSI drivers

The integration possibilities are expanding rapidly. I’ve seen setups where NFS serves as the backbone for:

• GitLab CI/CD pipeline shared storage
• Prometheus metrics storage across multiple nodes
• WordPress multisite installations with shared uploads
• Machine learning model storage for distributed training

Conclusion and Recommendations

NFS remains one of the most reliable and straightforward solutions for network file sharing in Linux environments. While it may not have the bells and whistles of modern distributed filesystems, its simplicity and maturity make it an excellent choice for many scenarios.

Use NFS when:

• You need simple, reliable file sharing between Linux systems
• Performance requirements are moderate (under 1GB/s)
• Your network is relatively trusted
• You want something that “just works” without complex configuration

Avoid NFS when:

• You need high availability with automatic failover
• Security is paramount and you can’t implement Kerberos
• You’re dealing with Windows-heavy environments
• You need global namespace across multiple datacenters

For production deployments, always test your configuration thoroughly, monitor performance metrics, and have a backup plan. Consider starting with a VPS for testing before moving to production infrastructure, or go straight to a dedicated server if you’re planning a serious deployment.

The key to NFS success is understanding your specific use case and tuning accordingly. Start with the basics, measure performance, and iterate. With proper setup and tuning, NFS can serve you reliably for years – I’ve seen installations running smoothly for over a decade with minimal maintenance.

Remember: NFS is not just about sharing files; it’s about creating a foundation for distributed computing that can scale with your needs. Whether you’re running a small development team or a large-scale data processing pipeline, the principles and configurations covered in this guide will serve you well.

---

---

This article incorporates information and material from various online sources. We acknowledge and appreciate the work of all original authors, publishers, and websites. While every effort has been made to appropriately credit the source material, any unintentional oversight or omission does not constitute a copyright infringement. All trademarks, logos, and images mentioned are the property of their respective owners. If you believe that any content used in this article infringes upon your copyright, please contact us immediately for review and prompt action.

This article is intended for informational and educational purposes only and does not infringe on the rights of the copyright owners. If any copyrighted material has been used without proper credit or in violation of copyright laws, it is unintentional and we will rectify it promptly upon notification. Please note that the republishing, redistribution, or reproduction of part or all of the contents in any form is prohibited without express written permission from the author and website owner. For permissions or further inquiries, please contact us.