NFS Stale File Handle Fix — Unmount & Remount

Yeah, that Stale NFS file handle error is annoying. You try to ls a directory or edit a file and get nothing but that error. The good news? The fix is usually simple and fast.

Immediate Fix: Unmount and Remount

First thing—don't waste time restarting services or rebooting. The culprit here is almost always a mismatch between what the NFS server exported and what your client thinks it has. So:

Check what's mounted:
```
mount | grep nfs
```
Force unmount the stale mount:
```
umount -f -l /mountpoint
```
- -f = force
- -l = lazy unmount (detaches immediately, even if busy)
Remount the share:
```
mount -t nfs server:/export /mountpoint
```
If you use specific options like proto=tcp,vers=4.2 or hard,intr, include them here too.

That's it. Nine times out of ten, this clears the stale handle. If umount -f -l fails (rare but possible on really stuck mounts), reboot the client. Yes, it's brute force, but it's faster than chasing ghosts.

Why This Happens

The NFS file handle is a unique identifier the server gives to each file or directory when the mount happens. Think of it like a ticket. When the server re-exports the share (maybe you ran exportfs -r or rebooted the server), those old tickets become invalid. The client still holds them, so any access fails with ESTALE.

Common triggers:

Server reboot or NFS service restart
Export config changes (like adding fsid=0 or changing path)
Network timeout that makes the client lose sync
Using hard mount option with no timeout—client keeps retrying with a stale handle

Less Common Variations

Variant 1: Only Some Files Are Stale

If ls /mountpoint works but accessing a subdirectory gives ESTALE, it's a handle issue on that specific directory. Still, the fix is the same—remount the whole thing. No need to cherry-pick.

Variant 2: Multiple Clients Show Same Error

This screams server side. Check the server's exports:

exportfs -v

Look for mismatches. For example, if you changed /srv/data to /srv/data2 and forgot to update the export file, all clients will get stale handles. On the server, run exportfs -r to reload exports, then remount clients.

Variant 3: NFSv4 Pseudo Filesystem Issues

NFSv4 uses a single export per server (the 'pseudo filesystem'). If you have multiple exports, they must share a common root. Break that rule, and you'll get stale handles on some mounts. Check /etc/exports on the server—each export path must be a subtree of the pseudo root. If not, use fsid=0 on one export to set the root.

Variant 4: Firewall or Network Reset

Sometimes a firewall change or router reboot drops the NFS connection. The client's TCP session dies, but the mount state lingers. Remount solves it. If it keeps happening, switch to soft mount (at the cost of potential data loss) or add retrans=3 to give the client a chance to reconnect.

Prevention Tips

Always use exportfs -r after changing exports—this avoids mismatches. Don't just edit the file and hope.
Use consistent mount options across all clients. Options like vers=4.2 or proto=tcp should match your server config.
Set timeo=600 (10 seconds) and retrans=2 on client mounts. This gives the server time to recover without keeping the client stuck forever.
Monitor server reboots—automate remounting clients with a script or systemd unit. Stale handles after a server restart are common and predictable.
If you use NFSv4 with multiple exports, double-check the pseudo filesystem. A wrong fsid setting causes intermittent stale handles.

That's the long and short of it. Unmount, remount, fix the server config if needed. You won't need to touch this again unless someone changes the exports.