Setting Up NFS on Ubuntu Without Losing Your Mind

I have a confession: I hate Samba. Okay, hate is a strong word. Samba is fine if you need to share files with a Windows machine or a Mac that refuses to behave. But if you’re running a pure Linux environment—say, an Ubuntu desktop talking to an Ubuntu server—using SMB is like driving a tank to the grocery store. It works, but it’s loud, heavy, and overkill. That’s why I switched everything in my homelab to NFS (Network File System) about three years ago. It’s native to Linux, the overhead is practically non-existent, and the transfer speeds? Significantly better. But here’s the thing. NFS configuration files look like they were designed in 1985 because, well, they were. The syntax is unforgiving, and if you mess up one flag, your client machine will hang indefinitely during boot. I’ve been there. Staring at a splash screen for ten minutes wondering why my server won’t start, only to realize I forgot the _netdev option. So, let’s walk through setting this up properly on Ubuntu. No fluff, just the config that actually works.

The Server Side (Where the Files Live)

First, you need to install the kernel server. I’m assuming you’ve got sudo access. If you don’t, stop reading and go find your admin.

sudo apt update
sudo apt install nfs-kernel-server

Once that’s installed, check if the service is actually running. Ubuntu is usually good about starting services automatically, but I always double-check because I have trust issues.

sudo systemctl status nfs-kernel-server

If you see a green “active (exited)” or “active (running)” status, you’re good.

Creating the Share

You can export any directory, but I prefer creating a dedicated mount point so I don’t accidentally share my entire /home directory with the network. That happened to a colleague of mine once. Not fun.

sudo mkdir -p /var/nfs/general
sudo chown nobody:nogroup /var/nfs/general

Why nobody:nogroup? Because NFS permissions are tricky. By default, the client user’s ID needs to match the server user’s ID to write files. If user “dave” is ID 1000 on the client but ID 1001 on the server, permissions get messy fast. Setting ownership to nobody is the lazy (but effective) way to ensure clients can actually write to the folder without strict ID mapping. If you’re running a high-security enterprise environment, you’d use Kerberos. But for a home network or small office? This works.

The Exports File (The Tricky Part)

This is where everyone messes up. Open the configuration file:

sudo nano /etc/exports

You need to add a line defining the directory and who can access it. Do **not** just put * for the IP address unless you want your neighbor’s kid scanning your network and finding your backups. Restrict it to your subnet. Here is the line I use:

/var/nfs/general 192.168.1.0/24(rw,sync,no_subtree_check)

Let’s break that down, because the defaults will bite you: * **rw**: Read and write. Obvious. * **sync**: This forces the server to write changes to disk before replying to the client. It’s slightly slower than async, but if your server crashes during a file transfer with async, you lose data. I prefer data integrity over a marginal speed boost. * **no_subtree_check**: Just use this. If you don’t, the server tries to verify if the file is part of a subdirectory for every request. It causes weird permission errors. Save the file (Ctrl+O, Enter, Ctrl+X) and then reload the export table. You don’t need to restart the whole service.

sudo exportfs -a
sudo systemctl restart nfs-kernel-server

Don’t Forget the Firewall

I spent an hour troubleshooting a connection once only to realize UFW (Uncomplicated Firewall) was doing its job too well. You need to let the traffic through.

sudo ufw allow from 192.168.1.0/24 to any port nfs

Check it with sudo ufw status. If you see port 2049 allowed, you’re set.

The Client Side (Where You Want the Files)

Hop over to your other Ubuntu machine. You don’t need the server package here, just the common tools.

sudo apt update
sudo apt install nfs-common

Create a spot to mount the share.

sudo mkdir -p /mnt/nfs_share

Now, the moment of truth. Mount it manually first to make sure it works.

sudo mount 192.168.1.50:/var/nfs/general /mnt/nfs_share

(Replace 192.168.1.50 with your actual server IP). If the terminal just returns to the prompt without an error, congratulations. It worked. Linux philosophy: “No news is good news.” Go check the folder:

ls -l /mnt/nfs_share
touch /mnt/nfs_share/test_file.txt

If that touch command works, you have write access.

Making It Permanent (And Avoiding the Boot Hang)

Mounting manually is annoying. You want this to happen at boot. But editing /etc/fstab for network drives is risky. If the network isn’t up when the OS tries to mount the drive, the boot process halts and waits. And waits. I’ve had to drive to a physical location to plug in a keyboard because of a bad fstab entry. Don’t be me. Edit the fstab file:

sudo nano /etc/fstab

Add this line at the bottom:

192.168.1.50:/var/nfs/general    /mnt/nfs_share   nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

The magic keyword here is **nofail**. If your server is down, or your wifi is acting up, nofail tells Ubuntu, “Hey, if you can’t find this drive, just skip it and boot anyway.” Without it, your system hangs. I also use noatime to stop the system from writing a timestamp every time I just read a file—it’s a small performance tweak, but it adds up.

Why This Matters

Look, cloud storage is convenient. Dropping files into Dropbox is easy. But for moving large ISOs, backups, or media files between machines on your own LAN, NFS is just better. It strips away the authentication handshakes of SMB and just moves bits. Once you get past the initial config headache, it’s incredibly stable. My current setup has been running without a reboot (aside from kernel updates) for six months. The files are just *there*, appearing as if they were on the local disk. Just remember the nofail flag. Seriously.