How to Mount Directory to NFS Server

Say you already have an NFS server running somewhere on your network — maybe a box holding shared media, a common document root for a couple of web servers, or scratch storage for a small cluster — and now you want another machine to actually use that storage. The goal on the client is simple: mount the remote share so a directory like /var/www behaves exactly like a local folder, and have it come back automatically after a reboot. This tutorial covers that client side: mounting the share, making it persistent, and fixing it when it misbehaves.

You need a working NFS server before any of this makes sense. If you don’t have one yet, start with my other tutorial and come back here: How to Setup NFS Server in Ubuntu.

Prerequisite

1. Ubuntu (any modern LTS release)
2. An active NFS server you can reach over the network

Sudo Privileges

Before we start, let’s switch to root so we don’t hit permission issues during configuration.

sudo su

Install Dependencies

The client needs the nfs-common package, which provides the tools to mount and talk to an NFS server.

apt update && apt install nfs-common

Create a Directory to Mount Into

This is the local directory where the remote share will appear. It’s just an empty folder; once mounted, anything inside it actually lives on the server. For example, to use /var/www as the mount point:

mkdir -p /var/www

A note worth remembering: if the directory already has files in them, those files get hidden (not deleted) while the share is mounted on top, and they reappear when you unmount. So mount into an empty directory unless you know what you’re doing.

Mounting to the NFS Server

First, find out what the server actually offers. You need the server’s IP address; if it’s at 192.168.5.50, list its exports with:

showmount -e 192.168.5.50

This returns the paths the server is sharing, along with which clients each one allows:

Export list for 192.168.5.50:
/nfs/share1 *
/nfs/share2 192.168.5.0/24
/nfs/share3 192.168.10.0/24

Pick the path that suits you and mount it. The format is server_ip:/export_path local_mount_point:

mount -t nfs 192.168.5.50:/nfs/share1 /var/www

That’s it for a one-time mount. If you create a file inside /var/www, it’s stored on the NFS server, not locally.

There’s one big catch, though: this mount does not survive a reboot. Restart the machine and /var/www is back to being a plain empty local folder. For anything beyond a quick test, you want the mount to come back automatically, which is the next section.

Making the Mount Persistent with /etc/fstab

To have the share mount automatically on every boot, add it to /etc/fstab, the file that lists filesystems the system should mount. Open it:

nano /etc/fstab

Add a line in this format (each field is separated by spaces or tabs):

192.168.5.50:/nfs/share1  /var/www  nfs  defaults,_netdev,nofail  0  0

Here’s what each of the six fields means:

1. 192.168.5.50:/nfs/share1 — the remote share, same server:/path you used in the mount command.
2. /var/www — the local mount point.
3. nfs — the filesystem type.
4. defaults,_netdev,nofail — the mount options (explained below).
5. 0 — the dump field; leave it 0 for NFS (it’s not a local disk to back up this way).
6. 0 — the fsck pass; leave it 0 because you never run fsck on a network share.

The two options that matter most here are about boot ordering and not getting stuck, and both are documented in the mount(8) man page:

• _netdev tells the system this filesystem lives on a device that needs the network. Without it, the system may try to mount the share before networking is up — and fail every time. _netdev holds the mount until the network is available.
• nofail tells the system not to treat a failed mount as a fatal error during boot. Without it, if the server is unreachable when the machine starts, the boot can hang or drop into an emergency shell. With nofail, the machine boots normally and simply skips the share until it can reach the server.

To test the line without rebooting, unmount first if it’s already mounted, then mount everything in fstab:

umount /var/www
mount -a

If mount -a returns with no errors and /var/www shows the share, your fstab entry is correct and will work on the next boot.

NFSv3 vs NFSv4 (and How to Tell Which You’re Using)

NFS has two versions you’ll meet in practice, and mixing them up causes a surprising amount of confusion:

• NFSv4 is the modern default on current Ubuntu. It runs over a single TCP port, 2049, which makes it firewall-friendly and simpler to reason about.
• NFSv3 is older. It needs rpcbind on port 111 plus several helper services on dynamic ports, so it’s much harder to get through a firewall.

According to the nfs(5) man page, when you don’t specify a version the client tries 4.2 first and negotiates downward until it finds something the server supports. That usually does the right thing, but it also means a mount can silently land on v3 if the server’s v4 isn’t set up — which then behaves differently than you expect.

To see which version a mount actually negotiated, check the mount output:

mount | grep nfs

An NFSv4 mount shows the type as nfs4, while a v3 mount shows nfs. For more detail, including the exact version and options, use:

nfsstat -m

which prints each mounted NFS filesystem and its flags (the vers= value tells you the version outright).

If you need to force a specific version, pass it with the vers option. For example, to require NFSv4.2:

mount -t nfs -o vers=4.2 192.168.5.50:/nfs/share1 /var/www

Per the man page, if the server doesn’t support the version you ask for, the mount simply fails rather than falling back — which is sometimes exactly what you want, so you find out immediately.

Verify the Mount

A mount command that returns quietly isn’t proof of much. Confirm the share is really there and writable.

First, check it appears in the mount table with the right source and type:

mount | grep /var/www

You should see your server and export, for example 192.168.5.50:/nfs/share1 on /var/www type nfs4 (rw,...).

Next, confirm it’s mounted and see the space, which comes from the server, not the local disk:

df -h /var/www

The Filesystem column should read 192.168.5.50:/nfs/share1 rather than a local device like /dev/sda1.

Finally, prove you can actually write to it (a mount can succeed read-only or with permission problems). Write a test file and remove it:

touch /var/www/nfs-write-test && rm /var/www/nfs-write-test

If both commands succeed without error, the share is mounted and writable. If touch fails, jump to the troubleshooting section below.

Troubleshooting

Most client-side NFS problems fall into a few recognizable patterns.

The mount hangs or times out

You run mount (or boot the machine) and it just sits there, eventually failing with a timeout. This almost always means the client can’t reach the NFS service on the server. Check the basics in order:

ping 192.168.5.50

to confirm the host is even up, then check the NFS port is open from the client:

showmount -e 192.168.5.50

If ping works but showmount hangs or times out, a firewall is the usual cause — NFSv4 needs TCP port 2049 open between client and server. (If the server is on NFSv3, it also needs port 111 and the rpcbind helpers, which is exactly why v4 is easier.) Open the port on the server side, or confirm the server’s NFS service is running.

This is also the reason the nofail option above matters: without it, an unreachable server at boot can leave the whole machine hanging on the mount.

“access denied by server while mounting”

The mount fails quickly with a message about access being denied by the server. This isn’t a network problem — you reached the server, but its export rules don’t allow this client’s IP. Look at what the server permits:

showmount -e 192.168.5.50

Compare the client/subnet listed next to your export with this machine’s actual IP. If the export is limited to, say, 192.168.5.0/24 and your client is on a different subnet, the server rejects it. The fix is on the server: its /etc/exports entry needs to include your client’s IP or subnet, followed by exportfs -ra.

The mount works, but writing files gives “Permission denied”

The share mounts fine, df looks right, but touch /var/www/test returns Permission denied. The mount succeeded; the permissions didn’t line up. Two common causes:

• root_squash (the default). The server maps the client’s root user down to a low-privilege anonymous account, so even writing as root on the client lands as nobody on the server. If the target directory isn’t writable by that account, the write is denied.
• UID mismatch. With standard NFS, the server identifies users by numeric UID, not by name. If your user is UID 1001 on the client but the files on the server are owned by UID 1000, you don’t have write access even though the username might look the same on both machines.

Diagnose by checking what owns the files and who you are:

ls -ln /var/www
id

Compare the numeric owner/group of the files against your own UID/GID. The fix lives on the server: either adjust the directory ownership/permissions, or set up matching UIDs, or have the export squash all writes to a known account (the server tutorial covers all_squash, anonuid, and anongid).

showmount returns nothing

showmount -e 192.168.5.50 runs but the export list comes back empty. That means you reached the server’s rpcbind, but it isn’t advertising any exports to you. Usually the server simply has no active exports — its /etc/exports is empty or wasn’t reloaded after editing. The fix is on the server: confirm /etc/exports has a valid line and run exportfs -ra, then check again with exportfs -v on the server. (Note that a pure NFSv4-only server may not answer showmount the way a v3 one does, so an empty result isn’t always proof that nothing is exported — try the actual mount as the real test.)

Wrapping Up

You now have an NFS share mounted on the client, set to remount automatically after a reboot, and you know how to confirm it’s working and where to look when it isn’t. If you haven’t set up the server side, or need to revisit its export options, see the companion tutorial: How to Setup NFS Server in Ubuntu.