NFS: Network File Sharing on Linux

By Kokil Thapa | Last reviewed: September 2026

NFS: Network File Sharing on Linux lets multiple machines treat a remote directory as local storage over TCP/IP. You export a path on a server, mount it on clients, and applications read and write files as if they lived on disk. That pattern powers shared Laravel storage/ folders, CI artefact directories, and nightly database dumps on Ubuntu 22/24. If you run production infrastructure alongside Linux system administration in Nepal, NFS belongs in your daily toolkit. This guide covers server setup, client mounts, firewall rules, and the failure modes I see on real deployments.

What is NFS and how does NFS network file sharing on Linux work?

NFS is a kernel-level protocol for sharing files across a network. A server process (nfsd) serves exported paths. Client kernels translate file operations into RPC calls. The result feels like a local filesystem, but latency and locking behave differently from block storage.

Modern Linux deployments should prefer NFSv4. It uses a single TCP port (2049), integrates better with firewalls, and supports pseudo-root exports. NFSv3 still appears on legacy systems and some NAS appliances. It relies on separate RPC ports and often needs rpcbind. For new Ubuntu 24.04 or 22.04 servers, default to v4 unless a client explicitly requires v3.

NFS is not a replacement for object storage like S3. It is a POSIX filesystem over the network. That makes it ideal when applications expect normal file paths—PHP uploads, WordPress wp-content, or rsync targets. It is a poor fit for millions of tiny files or strict multi-site consistency without extra tooling. Compare it with rsync for efficient file sync and backup when you only need periodic copies, not live shared writes.

The Linux kernel implements the client side natively. No FUSE layer is required for standard mounts. That keeps overhead low for sequential reads and large file writes. Random I/O over high-latency links will feel slow—plan accordingly on cross-region links from Kathmandu to overseas VPS hosts.

How do you install and configure an NFS server on Ubuntu?

On Ubuntu 22.04 or 24.04, install the server packages and create a dedicated export directory. Keep exports on a separate filesystem or LVM volume when possible. A full root partition caused by runaway logs on a shared mount is a pain I have cleaned up more than once.

Install packages and prepare the export path

sudo apt update
sudo apt install nfs-kernel-server
sudo mkdir -p /srv/nfs/shared
sudo chown nobody:nogroup /srv/nfs/shared
sudo chmod 2770 /srv/nfs/shared

For NFSv4, set a pseudo-root in /etc/default/nfs-kernel-server:

RPCNFSDOPTS="-N 4"
NEED_STATD=no
NEED_IDMAPD=yes

Define exports in /etc/exports. Restrict by client subnet, not the whole internet:

/srv/nfs/shared  10.0.1.0/24(rw,sync,no_subtree_check,fsid=0,crossmnt,no_root_squash)
/srv/nfs/shared  10.0.1.10(ro,sync,no_subtree_check)

Apply changes and verify:

sudo exportfs -ra
sudo exportfs -v
sudo systemctl enable --now nfs-server
showmount -e localhost

Pair this with proper Linux file permissions and ACLs on the export path. NFS respects Unix ownership bits. A mismatch between www-data UID on two servers breaks writes silently.

Align UIDs and GIDs across clients

NFS maps numeric UIDs, not usernames. If Apache runs as UID 33 on the web server but UID 34 on the NFS client, permission errors follow. Options:

• Standardise service account UIDs in Ansible or cloud-init.
• Use LDAP or SSSD for central identity on larger fleets.
• For NFSv4, configure idmapd with consistent domain names in /etc/idmapd.conf.

On several sister sites I maintain on shared EC2 infrastructure, we keep web and NFS UIDs identical across Deployer release targets. That avoids midnight permission tickets after a new app server joins the pool.

How do you mount NFS shares on a Linux client?

Clients need the nfs-common package. Test a manual mount first. Persist only after you confirm performance and permissions.

Manual mount for testing

sudo apt install nfs-common
sudo mkdir -p /mnt/nfs/shared
sudo mount -t nfs4 -o rw,hard,intr,rsize=1048576,wsize=1048576 \
  10.0.1.5:/ /mnt/nfs/shared
df -h /mnt/nfs/shared
touch /mnt/nfs/shared/test.txt

For NFSv4, the server path is often server:/ with the export defined by fsid=0. For NFSv3, specify the full export path: 10.0.1.5:/srv/nfs/shared.

Persistent mounts in fstab

10.0.1.5:/  /mnt/nfs/shared  nfs4  defaults,_netdev,noatime,hard,intr  0  0

The _netdev option delays mount until networking is up. Without it, boot can hang waiting for an unreachable server. Use nofail on non-critical mounts so a dead NFS server does not block boot entirely.

Validate fstab before reboot:

sudo mount -a
sudo systemctl daemon-reload

For Laravel or WordPress stacks that share user uploads across app nodes, I mount NFS at the same path on every node—typically /var/www/shared/storage symlinked into each release. That mirrors patterns in Laravel file uploads with local storage, but keeps files on your own LAN instead of object storage.

NFSv3 vs NFSv4: which version should you use on Linux?

Pick the version based on client compatibility and firewall constraints. The table below summarises what I recommend in 2026.

Official kernel documentation at kernel.org NFS documentation covers both versions in depth. Ubuntu’s server guide at Ubuntu NFS installation docs matches the package names above for 22.04 and 24.04.

How do you secure NFS exports on a production Linux server?

NFS was designed for trusted LANs. Treat every export as sensitive. Never expose port 2049 to the public internet without Kerberos and strict ACLs—a scanned VPS in any region gets probed within hours.

Network and firewall rules

Allow NFS only from known client subnets. With UFW on Ubuntu:

sudo ufw allow from 10.0.1.0/24 to any port nfs
sudo ufw deny nfs

For nftables setups, see nftables as the modern Linux firewall or the older iptables vs nftables comparison. Restrict source IPs at the cloud security group level too. Double layers beat a single misconfigured rule.

Export options that matter

1. Client IP restriction — list subnets in /etc/exports, never *.
2. ro vs rw — give read-only where writes are not required (static assets, log aggregation readers).
3. root_squash — map remote root to nobody unless you have a specific reason for no_root_squash.
4. sync — wait for disk commit before acknowledging writes; safer for databases copied to NFS.
5. Kerberos (sec=krb5p) — required for multi-tenant or cross-datacenter links; rarely configured on small VPS setups but worth knowing.

Document every export in your runbook. On a legal-tech portal I built, client document storage stayed on local disk with encrypted backups. NFS was reserved for shared static assets between load-balanced nodes—not for confidential PDFs crossing an unsegmented LAN.

For dedicated storage appliances, read TrueNAS for network storage as an alternative when you want ZFS snapshots and a GUI instead of raw Linux exports.

How do you troubleshoot common NFS mount failures on Linux?

Most NFS problems fall into four buckets: network, exports, permissions, and stale mounts. Work through them in that order before reinstalling packages.

Diagnose step by step

ping -c 3 10.0.1.5
rpcinfo -p 10.0.1.5
showmount -e 10.0.1.5
sudo mount -v -t nfs4 10.0.1.5:/ /mnt/nfs/shared
dmesg | tail -20
journalctl -u nfs-server --since "10 min ago"

Common errors and fixes:

• Connection timed out — firewall, wrong security group, or server down. Check Ubuntu network troubleshooting steps first.
• Access denied — client IP not listed in /etc/exports. Run exportfs -ra after edits.
• Stale file handle — server export changed or filesystem recreated. Unmount with umount -l, remount, restart dependent services.
• Permission denied on write — UID/GID mismatch or export mounted ro. Compare id www-data on both hosts.
• Boot hang — missing _netdev or nofail in fstab. Fix fstab from recovery mode if needed.

Monitor mount health with Linux server monitoring with Netdata and alerts. Alert on export disk usage above 85%. A full NFS volume takes down every client at once.

What are practical NFS use cases for web and application servers?

NFS shines when several Linux app servers need the same writable directory. These patterns appear regularly in my deployment work.

• Shared Laravel storage — mount NFS at a persistent path outside Deployer releases so user uploads survive symlink swaps.
• Centralised backup landing zone — cron jobs on multiple hosts write to one NFS export; a single host runs automated database backups on Linux from that pool.
• CI artefact storage — GitLab runners share build caches without duplicating gigabytes per runner.
• Media processing — large video or image batches read from one export during transcoding.
• Kubernetes ReadWriteMany volumes — see NFS as Kubernetes persistent storage when your cluster needs shared PVC access.

When latency or durability requirements exceed what NFS offers, move to S3-compatible object storage. The AWS S3 for Laravel file storage guide covers that path. NFS stays cheaper and simpler on a private LAN with two to five nodes—typical for Nepal SMB hosting budgets around Rs 5,000–15,000/month (~USD 37–110) per VPS.

Prepare the underlying disk with LVM for flexible disk management so you can grow the export volume without downtime. Configure networking cleanly first using the Ubuntu network configuration guide.

Sister sites on my shared Deployer 7 pipeline—such as the Notary Kathmandu portfolio project—run on isolated releases but share operational patterns. NFS is optional there; when we add it, the goal is always shared media without coupling deploy paths.

Use the JSON formatter tool when debugging API payloads that reference NFS-mounted paths in container specs. Small utilities save time during incident response.

Key Takeaways

• Default to NFSv4 on Ubuntu 22/24: single port 2049, simpler firewall rules, and better locking than NFSv3.
• Restrict exports by client IP in /etc/exports; never expose NFS to the public internet without Kerberos.
• Match UID/GID for service accounts across every server that reads or writes the same export.
• Use _netdev and nofail in fstab so boot does not hang when the NFS server is unreachable.
• Run exportfs -ra after every export change, and monitor export disk space with alerts.
• For multi-node Laravel or WordPress farms, mount NFS outside release directories and symlink into each deploy.

People Also Ask

Is NFS safe to use over the internet?

No, not in its default configuration. NFS assumes a trusted network. Exposing port 2049 publicly invites brute-force and mis-mount attacks. Keep NFS on private subnets or VPNs. Use Kerberos (RPCSEC_GSS) if traffic must cross untrusted segments. For public-cloud file access, prefer SSH, VPN, or object storage instead.

What is the difference between hard and soft NFS mounts?

A hard mount retries I/O indefinitely when the server disappears. Applications hang but data stays consistent once the server returns. A soft mount returns errors after a timeout, which can corrupt files under write load. Production servers should use hard with intr (where supported) for interactive recovery.

Can Docker or Kubernetes use NFS storage?

Yes. Bind-mount an NFS path into containers on bare metal or VM hosts. In Kubernetes, install an NFS provisioner or manually define PersistentVolumes pointing at your export. ReadWriteMany access mode requires shared filesystems like NFS; block storage cannot serve multiple writers that way.

How does NFS compare to Samba for Linux file sharing?

NFS is native to Linux and Unix—lower overhead, kernel integration, ideal for Linux-to-Linux. Samba speaks SMB/CIFS and suits mixed Windows/Linux environments. For a fleet of Ubuntu app servers sharing uploads, NFS is the lighter choice. For office staff on Windows laptops, Samba wins.

Deploy shared storage with confidence

NFS: Network File Sharing on Linux remains the fastest way to give several Ubuntu servers one writable directory without rewriting your application. Install nfs-kernel-server, export with IP restrictions, mount with NFSv4 and sensible fstab options, and align UIDs before go-live. Monitor disk space, keep exports off the public internet, and document every client subnet in your runbook.

If you want help designing shared storage for a multi-server Laravel stack, WordPress farm, or backup pipeline, review our support and maintenance services in Nepal or browse the Adventure Third Pole Trek portfolio for a production Laravel + Livewire deployment. For broader context on permissions that affect every mount, read Ubuntu file permissions explained and learn how systemd manages services on Linux so nfs-server starts reliably after reboot. Visit about me for background, or contact us to plan your next infrastructure change.