Setting Up and Mounting NFS Network Storage
Share one server's directory across many machines and read/write it like a local disk — with the private-network security settings you must not skip.
When several servers need to work off the same files — shared code, an uploads folder, archived logs — copying data back and forth is slow and quickly drifts out of sync. NFS (Network File System) lets one machine export a directory that others mount onto a local path and use as if it were a local disk. Here's the full server-and-client walkthrough on Ubuntu/Debian.
Server: Export a Shared Directory
Install the NFS server and prepare the directory you want to share.
sudo apt update
sudo apt install -y nfs-kernel-server
sudo mkdir -p /srv/share
sudo chown nobody:nogroup /srv/share
Configure /etc/exports
Export rules live in /etc/exports, one per line, in the form directory allowed-network(options):
# Allow only the 10.0.0.0/24 private network, read-write
/srv/share 10.0.0.0/24(rw,sync,no_subtree_check,root_squash)
What the common options mean:
- rw — allow read and write (use ro for read-only)
- sync — return only after data hits disk; safer than async, which is faster but risks data loss
- rootsquash — maps a client's root down to an anonymous user; keep this on so a remote root can't tamper with server files directly
- nosubtreecheck — disables subtree checking for better reliability
Apply the config and open the firewall to the trusted network only:
sudo exportfs -ra # reload exports
sudo exportfs -v # show current exports
sudo systemctl enable --now nfs-kernel-server
sudo ufw allow from 10.0.0.0/24 to any port nfs
Client: Mount and Use It
On each client, install the tools and mount the remote directory. Assume the server's private IP is 10.0.0.10:
sudo apt install -y nfs-common
sudo mkdir -p /mnt/share
sudo mount -t nfs 10.0.0.10:/srv/share /mnt/share
df -h /mnt/share # confirm the mount
Mount Automatically at Boot (fstab)
A manual mount is lost on reboot. Add an entry to /etc/fstab to make it persistent:
# append one line to /etc/fstab
10.0.0.10:/srv/share /mnt/share nfs defaults,_netdev,nofail 0 0
netdev tells the system to wait for the network before mounting, and nofail keeps a missing NFS server from stalling the whole boot.
Security Warning
NFS by default offers no encryption and no strong authentication — access control rests mainly on the source IP and network you allow. Exposed to the public internet, it is trivially scanned and abused. Always:
- Keep it on the private network and never expose the NFS port (2049) to the internet
- Restrict the network tightly in /etc/exports — never use or an overly broad range
- Always keep rootsquash; tighten further with allsquash when appropriate
- Use security groups/firewalls to allow only trusted internal sources; carry cross-site traffic over a VPN or private link
NFS or Object Storage?
They solve different problems — don't force one into the other's job:
- NFS fits workloads that need POSIX file semantics, random read/write, and many machines sharing one directory (shared build artifacts, scratch data). Its scalability and cross-region reach are limited.
- Object storage (S3-compatible) fits large volumes of static, write-once-read-many files (backups, images, video). It's highly available and cross-region by design, but is accessed over an HTTP API and can't overwrite in place at a byte offset.
Rule of thumb: choose NFS when you want it to "behave like a disk," and object storage when you want "massive archival plus global distribution."
Summary
NFS boils down to exports on the server, mount on the client, and an fstab entry to make it stick. On security, hold three lines without exception: private network only, restrict the allowed range, and keep rootsquash. Reach for NFS to share a live directory and object storage to archive at scale — let the access pattern decide.