How to Set Up an NFS Server on Linux: Share Files Across Your Network

If you’ve ever found yourself scp-ing the same files between three different VMs at 11pm on a Tuesday, this guide is for me — I mean, for you. Learning how to set up an NFS server on Linux changed my homelab forever, and I want to save you the months of “good enough” workarounds I lived through. By the end of this guide, your servers will share storage like they were always meant to.

I’ll walk you through the whole thing on both Ubuntu and RHEL-based systems, cover the security gotchas that bite beginners, and share the performance tuning tweaks that most tutorials skip. There’s one mount option in particular that doubled my read throughput on a Gigabit link — we’ll get to that in section 9.

What Is NFS and When Should You Use It?

NFS stands for Network File System. It lets a Linux client treat a remote directory exactly like a local folder. You browse it with ls, edit files with your normal editor, and the kernel handles the network transport invisibly. Sun Microsystems shipped NFS back in 1984, but the protocol has aged remarkably well.

Get a VPS from as low as $11/year! WOW!

NFSv4 is the modern standard you should target. It uses a single TCP port (2049), supports stateful sessions, has integrated locking, and can do Kerberos-based authentication. NFSv3 still works, but it relies on a constellation of helper services like rpcbind, mountd, and statd that each grab dynamic ports — a nightmare for firewall rules.

I reach for NFS when I need:

• Homelab shared storage: One ZFS pool, multiple VMs, no duplication.
• Proxmox or KVM shared VM disks: Live migration becomes possible because every node sees the same images. If you’re spinning up a virtualization stack, see my roundup of the best Linux virtualization tools.
• Centralized backups: All your machines write to one mounted share.
• CI/CD artifact sharing: Build agents drop artifacts into a common share for downstream jobs.

NFS is not the same thing as rsync for file synchronization. NFS is a live, shared filesystem — every change is immediately visible to every client. Rsync is a one-way copy you run on a schedule. They solve different problems, and I use both, often on the same machines.

Installing the NFS Server Packages

Package naming differs across distros, which is the first place new admins trip. Let’s split this by distribution family.

Ubuntu and Debian

On the server:

sudo apt update
sudo apt install nfs-kernel-server

On any client machine that will mount the share:

sudo apt install nfs-common

RHEL, AlmaLinux, Rocky Linux, and Fedora

One package handles both server and client roles here:

sudo dnf install nfs-utils

That’s the whole installation. Linux packagers did the heavy lifting for us a long time ago. The interesting work happens in the next few steps.

Creating Your Export Directories

Pick a directory you actually want to share. I keep mine under /srv/nfs/ by convention because the Filesystem Hierarchy Standard reserves /srv for service data, and it keeps NFS exports out of /home or /mnt where I might accidentally clobber them.

sudo mkdir -p /srv/nfs/data
sudo chown nobody:nogroup /srv/nfs/data
sudo chmod 755 /srv/nfs/data

The nobody:nogroup ownership matters. Because root_squash is on by default (which we want — we’ll get to why), remote root operations get mapped to the local nobody user. If you want a refresher on how chmod and chown actually work, my guide on Linux file permissions covers the mental model.

If you want to export multiple directories under NFSv4, the cleanest approach is a pseudo-root with bind mounts:

sudo mkdir -p /srv/nfs4/{media,backups}
sudo mount --bind /mnt/storage/media /srv/nfs4/media
sudo mount --bind /mnt/storage/backups /srv/nfs4/backups

This presents a clean tree to clients without scattering exports across the filesystem. Add the bind mounts to /etc/fstab if you want them to survive reboots.

Configuring /etc/exports: Defining What to Share

The /etc/exports file is the heart of any NFS server setup. Each line follows a simple pattern:

/path/to/export client-ip-or-subnet(options)

One detail trips up nearly everyone: there is no space between the client spec and the parenthesis. A space changes the meaning entirely — it tells NFS to export to “all clients with these options” plus a separate entry for that IP. I learned this the way you learn most NFS lessons: by debugging it for an hour.

Export Options Explained

• rw / ro: Read-write or read-only. Use ro whenever clients don’t need to write.
• sync: Acknowledge writes only after they hit disk. Safer. Default.
• async: Acknowledge before the write completes. Faster, but a server crash can lose data. Only use for scratch space.
• root_squash: Maps remote UID 0 to nobody. KEEP IT ON.
• no_root_squash: Allows remote root to act as local root. This is a privilege escalation vector. Don’t.
• no_subtree_check: Skips subtree checking. Recommended for performance and stability.

A Full Example /etc/exports File

# /etc/exports
/srv/nfs/data 192.168.1.0/24(rw,sync,no_subtree_check,root_squash)
/srv/nfs/backups 192.168.1.50(rw,sync,no_subtree_check,root_squash)
/srv/nfs/iso 192.168.1.0/24(ro,sync,no_subtree_check,root_squash)

Restrict by IP or subnet — never use a wildcard * in production. After any edit, reload the exports without restarting the service:

sudo exportfs -ra

Starting and Enabling the NFS Service

Time to flip the switch:

sudo systemctl enable --now nfs-server
sudo systemctl status nfs-server

On Ubuntu the unit is sometimes called nfs-kernel-server instead of nfs-server — both names usually work as aliases on modern releases. If systemctl is new territory for you, my guide on how to manage services with systemctl walks through the basics.

Confirm what is actually being exported:

sudo exportfs -v

This is the source of truth. If your export isn’t listed here, no client will ever see it.

Opening Your Firewall for NFS

Pure NFSv4 only needs TCP port 2049. That’s it. One port. This was the single biggest improvement over NFSv3, and it’s why I push everyone to v4 by default.

UFW (Ubuntu and Debian)

sudo ufw allow from 192.168.1.0/24 to any port 2049 proto tcp
sudo ufw reload

Restricting by source subnet is non-negotiable on any network you don’t fully control. If UFW is new to you, I have a deeper walkthrough on how to configure UFW on Linux.

firewalld (RHEL, Fedora, AlmaLinux)

sudo firewall-cmd --add-service=nfs --permanent
sudo firewall-cmd --reload

For richer source-restricted rules, see my guide on how to use firewalld on Linux. If you’re on an older system without either tool, you can configure iptables rules directly. Whichever firewall you use, never expose port 2049 to the public internet. I repeat: never.

Mounting the NFS Share on the Client

Hop over to the client machine. Make sure nfs-common (Debian/Ubuntu) or nfs-utils (RHEL/Fedora) is installed, then create a mount point.

Temporary Mount for Testing

sudo mkdir -p /mnt/nfs-data
sudo mount -t nfs 192.168.1.10:/srv/nfs/data /mnt/nfs-data

Replace 192.168.1.10 with your server’s IP. If mount returns to the prompt without an error, you’re in. Run df -h to see the share. If the concept of mounting is fuzzy, my guide on how to mount disks in Linux covers the fundamentals.

Persistent Mount via /etc/fstab

For a mount that survives reboots:

192.168.1.10:/srv/nfs/data  /mnt/nfs-data  nfs  defaults,_netdev  0  0

The _netdev flag tells systemd to wait for the network before attempting the mount. Skip it and your client will hang on boot the first time the network comes up slow. Ask me how I know.

For Proxmox hosts and lazier homelab setups, x-systemd.automount is a clean alternative — it mounts on first access instead of at boot, which avoids cascading failures when the storage server reboots.

Testing Your NFS Setup

From the client, query the server’s exports:

showmount -e 192.168.1.10

Heads-up: showmount doesn’t work against a pure NFSv4 server because it depends on the legacy mountd protocol. If you get an empty list, run sudo exportfs -v on the server instead — that’s the authoritative answer. This single quirk causes more “is my NFS broken?” questions than anything else.

Write a test file from the client:

echo 'NFS works' | sudo tee /mnt/nfs-data/test.txt

Then on the server, confirm it landed:

cat /srv/nfs/data/test.txt

If you see NFS works, you’ve crossed the finish line on the basic setup.

Performance Tuning: rsize, wsize, and Mount Options

This is the section most tutorials skip, and it’s where you can wring real throughput out of an honest Gigabit network. The defaults are conservative for compatibility, not speed.

The first time I bumped rsize and wsize from the default 131072 to 1048576 on my Proxmox-to-NAS link, sequential reads went from a sluggish ~70 MB/s to nearly saturating the Gigabit link. Same hardware. Same cable. One mount option.

• rsize/wsize=1048576: 1 MB read and write block sizes. Big improvement on Gigabit and faster.
• noatime: Skip access-time updates on every read. Cuts unnecessary write traffic significantly on read-heavy workloads.
• hard: Retry indefinitely on network failure. Safe choice for production data.
• soft: Fail fast after timeout. Use only for scratch data you can lose.

Tuned mount command:

sudo mount -t nfs -o rsize=1048576,wsize=1048576,hard,noatime,_netdev \
  192.168.1.10:/srv/nfs/data /mnt/nfs-data

For the full menu of available options, the full list of NFS mount options man page is the canonical reference. If your server is genuinely busy, also bump the nfsd thread count by editing /etc/nfs.conf or RPCNFSDCOUNT — the default of 8 is low for serious workloads.

NFS Security Best Practices

NFS in the default configuration is reasonably safe on a trusted LAN. Step outside that, or get sloppy with options, and things go sideways fast.

“Never disable root squashing. Do not use the no_root_squash option and review existing installations to make sure it is not used.” — Red Hat NFS security hardening guide

Here is the actual attack scenario that quote is warning about: with no_root_squash, an attacker who gains root on any client (or someone you let mount the share) can chmod, chown, and create setuid binaries on the server. That’s full server compromise from any client. root_squash is the wall stopping that, and it’s on by default. Leave it on.

The first NFS share I exposed across a wider network, I learned the discipline of treating every mount as a security boundary. It’s not a “share folder, click OK” world. The defaults are sane, but every option you change deserves a moment of thought.

Troubleshooting Common NFS Problems

Three problems account for maybe 90% of the NFS bug reports I see in IRC and Discord help channels. Let’s hit them in order.

Permission Denied

Almost always one of three things: a syntax error in /etc/exports (look for stray spaces around the parenthesis), forgetting sudo exportfs -ra after the edit, or a firewall blocking port 2049. Verify the live exports with sudo exportfs -v on the server, then test connectivity from the client:

nc -zv 192.168.1.10 2049

Stale File Handle

This one looks scary but is mundane: a file or directory on the server got deleted and recreated with the same path, so its inode changed under the client’s nose. Fix it with one command on the server:

sudo exportfs -ra

Then unmount and remount on the client. Done.

Mount Hangs or Times Out

Confirm the server is actually running NFS:

sudo systemctl status nfs-server

Then check the firewall, ping the server IP, and tail the service logs. If you’re new to the journal, see how to check logs with journalctl:

journalctl -u nfs-server -f

Nine times out of ten the answer surfaces in those logs within seconds.

Frequently Asked Questions

Is NFS faster than Samba?

For Linux-to-Linux file sharing on a trusted network, yes — usually noticeably so, especially with tuned rsize/wsize. Samba shines for mixed environments with Windows clients.

Can I run NFS over the public internet?

You can, but you shouldn’t. Wrap it in a VPN like WireGuard or use NFSv4 with Kerberos (sec=krb5p) for actual encryption. Plain NFS over the internet is asking for trouble.

Why does showmount -e return nothing on my new server?

NFSv4-only servers don’t run the legacy mountd protocol that showmount queries. Use sudo exportfs -v on the server itself for a definitive list.

Should I use NFSv3 or NFSv4 for a new setup?

NFSv4. Single port, stateful sessions, integrated locking, optional Kerberos auth. There’s no reason to pick v3 for a green-field deployment in 2026.

Wrapping Up and Where to Go Next

That’s the full ride: install, export, firewall, mount, tune, secure, troubleshoot. NFS rewards a careful first hour with years of low-maintenance shared storage. My first homelab cluster went from “three Proxmox nodes manually scp-ing VM disks around” to “shared pool, live migration, instant backups” in one weekend with the steps above. That moment when you ls /mnt/nfs-data and watch files materialize from another machine genuinely doesn’t get old.

For deeper dives, both the Arch Wiki NFS reference and Red Hat’s official RHEL 9 NFS deployment documentation are excellent next stops. The Arch Wiki is my go-to reference even when I’m not on Arch — it’s that thorough.

If you found this useful, my WireGuard VPN setup guide pairs perfectly with NFS for secure remote access, and my Linux virtualization roundup is the natural next step if you’re building toward a real homelab cluster. Browse the rest of the Linux guides on the site — there’s plenty more to dig into, and I’d love to hear what you’re building.

Alexa Velinxs

I'm Alexa Velinxs, a cryptocurrency trading expert passionate about demystifying digital assets for both beginners and seasoned investors. Through my writing, I share actionable strategies, market insights, and practical tips to help you navigate the crypto landscape with confidence. Let's explore the future of finance together.

See Full Bio