A stale NFS client mount can leave a Linux path attached to a server export after the server stops answering, the network drops, or old client state keeps blocking normal file access. Shells and applications may hang when they touch the mount point, and a normal unmount can fail because a local process or the unreachable server is still holding the filesystem.
Linux keeps the active mount list in the kernel mount table, so findmnt can identify the NFS source without listing files inside the hung directory. fuser shows local processes that still hold the mount, while umount provides separate normal, forced, and lazy detachment paths for different failure states.
Clean up the client mount from a local directory and use the exact absolute mount point, such as /mnt/projects. This removes the client-side mount entry only; if the server export path changed or applications report Stale file handle after a remount, repair the server-side export state before asking clients to use the share again.
$ findmnt --kernel --types nfs,nfs4 --output TARGET,SOURCE,FSTYPE,OPTIONS TARGET SOURCE FSTYPE OPTIONS /mnt/projects files.example.net:/srv/nfs/projects nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,proto=tcp,timeo=600,retrans=2,sec=sys
Replace /mnt/projects with the exact mount point that hangs. Avoid ls, df, shell completion, or application probes inside the stale path until the mount table entry is known.
$ cd /
A shell whose current directory is under the mount point can keep the target busy even when no application files are open.
$ sudo fuser --verbose --mount /mnt/projects
USER PID ACCESS COMMAND
/mnt/projects: appuser 4186 ..c.. backupd
root 4201 F.... rsync
ACCESS values such as c and F indicate a current directory or open file reference on that filesystem.
$ sudo systemctl stop backup-worker.service
Replace backup-worker.service with the real service that owns the listed process. Stop file-copy, backup, database, or application jobs through their own control path before using process-kill commands.
$ sudo umount /mnt/projects
No output usually means the mount detached cleanly. If the command reports target is busy, repeat the fuser check and close the remaining holders before forcing the unmount.
$ sudo umount --force --no-canonicalize /mnt/projects
umount –force is intended for unreachable NFS systems, but it still may hang if the path forces extra lookup work. Use the absolute mount point, not a symlink or a path under the stale filesystem.
$ sudo umount --lazy /mnt/projects
umount –lazy removes the mount from the visible file hierarchy immediately, but old references remain alive until processes release them. Plan a service restart or reboot before treating the client as cleanly remounted.
$ mountpoint /mnt/projects /mnt/projects is not a mountpoint
If an automounter or /etc/fstab entry recreates the mount immediately, fix the client mount definition or server reachability before opening the path again.
Related: How to mount an NFS export on Linux
Related: How to automount an NFS export with autofs