Serving Up Network Storage
One of the coolest perks of running a server is sharing storage across your network. Enter NFS (Network File System) — a way to let client machines access storage as if it were local.
Why is this handy? A few classic use cases: - Centralized home directories (often paired with LDAP) - Applications needing a shared data store - Multiple servers writing logs to one place
Honestly, the use cases are endless — and the setup is refreshingly simple.
Server-Side NFS Setup
This article covers setting up the server side. See
Accessing Network Storage for how to mount
NFS shares on clients. ⚠️ You’ll need root for all of this. Storage and
networking are not “normal user” territory.
Step 1: Install the NFS Server Package
First, add the NFS service. Package names differ by distro:
dnf install nfs-utils # RHEL Family
apt install nfs-kernel-server # Debian Family
Step 2: Create an Export Listing
Exports tell NFS which directories you want to share. You almost never share
the whole filesystem — it’s much safer (and saner) to create a dedicated
share, e.g. /share or /logs.
Edit /etc/exports and define your shares:
rw→ read/writeno_root_squash→ allows clientrootto act asrooton the share (use with caution!)
Step 3: Enable the Service and Adjust Permissions
Turn on the NFS service:
systemctl enable --now nfs-server # RHEL Family
systemctl enable --now nfs-kernel-server # Debian Family
If you’re running firewalld, allow NFS-related services:
firewall-cmd --add-service=nfs
firewall-cmd --add-service=rpc-bind
firewall-cmd --add-service=mountd
firewall-cmd --runtime-to-permanent
Step 4: Validate with a Client System
On a client system, check that the server is actually exporting its shares:
# showmount -e <Name_of_NFS_Server> or <IP_of_NFS_Server>
showmount -e homeServer # OR
showmount -e 192.168.250.250
Expected output looks like this:
Enterprise Best Practices for NFS
A basic NFS setup works fine at home or in a lab, but in Production you’ll want to tighten things up. Here are some smart defaults:
Use root_squash (not no_root_squash)
- By default, NFS maps remote
rootusers to a harmless local user (usuallynfsnobody). - This prevents a compromised client from owning your NFS server.
- Only use
no_root_squashfor very specific, controlled use cases.
Restrict access by host or subnet
- Instead of
*(any host), use IPs or CIDR blocks:
Enable sync writes
- Forces writes to hit disk before returning “success.”
- Safer (though slower) than
async.
Set appropriate filesystem permissions
- NFS exports don’t override Linux permissions.
- Make sure your shared directories have correct ownership and mode bits.
Watch SELinux
- On RHEL-family systems, SELinux may block NFS exports by default.
- Enable with:
Monitor with showmount and exportfs
exportfs -vshows exactly what’s being shared and with what options.- Run it after changes to confirm settings are live.
Consider NFSv4
- Newer, cleaner protocol with better performance and security.
- Reduces port juggling (everything runs over TCP/2049).
Bottom line: keep it tight. Don’t export wide-open shares unless you’re in a safe lab environment.