Alright, let’s get you connected to that NFS share. The mount command is your Swiss Army knife here, but like any good tool, you can use it for quick jobs or set it up for permanent, reliable work. We’re going to cover both: the quick-and-dirty on-the-fly mount and the proper, “I don’t want to do this every reboot” method using /etc/fstab.

The On-the-Fly mount Command

Think of the mount command as a temporary hookup. It’s great for testing a share or for a one-off data transfer, but it won’t survive a reboot. The basic syntax is deceptively simple, which is where most of the pitfalls hide.

sudo mount -t nfs -o options server:/path/to/share /local/mountpoint

Let’s break down why you’re typing all that:

  • -t nfs: You’re telling the kernel, “Hey, this isn’t some local filesystem; it’s NFS.” Honestly, most modern kernels will figure this out themselves, but I like being explicit. It’s polite.
  • -o options: This is where the real magic (and pain) happens. This comma-separated list controls how the share behaves. We’ll get to the important ones in a second.
  • server:/path/to/share: This is the address. Note the colon (:). It’s not a typo. This is the Sun/Solaris legacy showing through, and we’re stuck with it.
  • /local/mountpoint: This must be an existing, empty directory. If it’s not empty, its contents will be completely hidden until you unmount the share. This has tripped me up more times than I’d care to admit.

Now, for a realistic example. Let’s say you have a server named nfs-server with a share called data. You want to mount it on your machine under /mnt/remote-data.

sudo mkdir /mnt/remote-data  # Create the mount point first!
sudo mount -t nfs -o nolock,hard,intr nfs-server:/data /mnt/remote-data

Why those options?

  • nolock: This disables file locking. In many modern setups, especially with a single client, you can get away with this and avoid the hassle of running a separate lockd daemon. It’s technically a bad practice for a multi-client environment, but let’s be honest, we’ve all used it to get a stubborn share to work.
  • hard: This is non-negotiable. This means if the server disappears, your system will wait forever for it to come back, relentlessly retrying. This is what you want. With soft, requests will eventually fail, corrupting your data. Never use soft for anything important. I’m not kidding.
  • intr: This lets you interrupt a stuck I/O request (say, if the server exploded) with a signal like Ctrl+C. With hard mounting, this is your lifeline. These days, this is often the default, but I always specify it because I like my lifelines explicit.

Configuring /etc/fstab for Persistence

Using mount by hand is for chumps and troubleshooters. For anything permanent, you use /etc/fstab. This file is the system’s directory of what to mount where at boot time. The syntax is a beautiful, cryptic piece of Unix history.

Here’s the entry that corresponds to our manual mount above:

# <file system>          <mount point>   <type>  <options>       <dump>  <pass>
nfs-server:/data   /mnt/remote-data   nfs     hard,intr,timeo=300,retrans=5   0       0

Let’s decode the new options and those weird numbers at the end:

  • timeo=300: This sets the timeout for an NFS request to 300 tenths of a second (so, 30 seconds). If the request fails after that time, it will retry.
  • retrans=5: The number of times to retry a request before throwing a major error. The combination of timeo and retrans defines your system’s stubbornness. The values above mean it will try for a total of 150 seconds (5 retries * 30 seconds) before really complaining.
  • <dump> and <pass>: These are relics for the dump backup utility and fsck filesystem check. They do precisely nothing for NFS filesystems. Set them to 0 and forget they exist.

To mount it after adding the entry, you can either reboot or just run sudo mount -a. This command tries to mount everything in fstab that isn’t already mounted, and it’s your best friend for testing new entries. If you screwed up the syntax, mount -a will tell you immediately.

The Crucial Edge Cases and Pitfalls

  1. Permission Nightmares: This is the big one. NFS permissions are mapped from your user ID on the client to the user ID on the server. If your UID on your laptop is 1000 but your user on the server is 1001, you’ll have a bad time. You’ll see “Permission denied” everywhere. The solution is either to standardize UIDs/GIDs across systems (a pain) or use the server’s UID mapping (see all_squash in the export options, which is a topic for another day).
  2. The Stale File Handle: This is the classic NFS error. It means your client has a file open, the share got reconfigured or remounted on the server, and now your client is pointing to something that no longer exists in the same way. The only fix is to unmount and remount on the client. It’s infuriating.
  3. Version Mismatch: If your mount is painfully slow or just fails, explicitly try adding vers=3 or vers=4.1 to your mount options. The automagic negotiation doesn’t always work, and forcing the version is the first thing I try when things feel broken. NFSv4 also simplifies things by having a single TCP port (2049), so your firewall rules are easier.