Fixing an NFS Mount That Hangs Instead of Failing on FreeBSD

An NFS mount that hangs a process indefinitely, rather than returning an error, is usually FreeBSD’s default “hard mount” behavior working exactly as designed — the fix is understanding that behavior and deciding whether it’s actually what you want for this specific mount.

Step 1: confirm the mount is actually the cause, not something else

ps aux | grep -i "D "

Processes stuck specifically in uninterruptible sleep (state D) waiting on I/O are the signature of a hanging NFS mount — a process in this state can’t even be killed with SIGKILL until the underlying I/O either completes or times out, which is itself useful confirmation this is NFS-related.

Step 2: check whether the mount is “hard” or “soft”

mount | grep nfs

By default, FreeBSD mounts NFS hard, meaning an operation against an unreachable NFS server retries indefinitely rather than ever returning an error — a deliberate design choice prioritizing data safety (never silently returning a spurious error that an application might mishandle) over responsiveness.

Step 3: check whether the NFS server is actually reachable

ping <nfs-server-ip>
showmount -e <nfs-server-ip>

Before changing any mount options, confirm the actual problem: is the NFS server down, is there a network partition between client and server, or has the specific export been removed or reconfigured on the server side?

Step 4: check for a firewall blocking NFS-related ports

rpcinfo -p <nfs-server-ip>

NFS depends on several supporting services (rpcbind, mountd, nfsd, statd, lockd) each potentially on different ports — a firewall change on either the client or server side that blocks one of these can produce exactly this kind of hang rather than a clean connection refusal.

Step 5: decide whether “soft” mount behavior is actually appropriate here

# in /etc/fstab, or as a mount option:
-o soft,retrans=3,timeo=30

A soft mount gives up and returns an I/O error after a bounded number of retries instead of hanging forever — appropriate for mounts where an application can sensibly handle an NFS error (retry logic of its own, non-critical data), but not appropriate for mounts backing something where a silent, corrupted write would be worse than an indefinite hang, which is exactly the scenario hard mounts are designed to prevent.

Step 6: use intr if you need mounts to remain interruptible

-o intr

Combined with a hard mount, intr allows a hung NFS operation to at least be interrupted by a signal (Ctrl-C) rather than being completely un-killable — a middle ground that keeps hard-mount data-safety guarantees while giving an administrator a way out of a truly stuck session.

Why hard mounts are the sensible default, not a bug to work around reflexively

A hard-mounted NFS client that simply returned an error the moment a server became briefly unreachable would risk applications treating a transient network blip as if the underlying data were genuinely gone or corrupted — a considerably worse outcome for many workloads than a process that hangs until connectivity returns. The right fix depends entirely on what’s actually mounted and what depends on it, which is why understanding why hard mounts hang, rather than reflexively switching every mount to soft, is the more important part of resolving this correctly.