Something is using the mount: a process with open files, a shell cd'd into it, or a container with a bind mount. Find the holder with one command, close it, and the umount just works.
lsof +f -- /mnt/x or fuser -vm /mnt/x lists them. Editors, tail -f, and shells cd'd in are the usual suspects.
findmnt -R /mnt/x reveals submounts (including container bind mounts); docker ps with volume mounts pinning the path will block umount.
lsof +f -- /mnt/x 2>/dev/null || sudo fuser -vm /mnt/x # shows PIDs and users# close editors, cd out of the dir, stop the service: docker stop <ct> ; systemctl stop <svc>findmnt -R /mnt/x # unmount child mounts first (bottom-up)sudo umount -l /mnt/x # data is not at risk, but open handles persist until processes exitumount -l is not a 'kill the processes' — the device stays pinned until the last fd closes; it just frees the path. Loop mounts (ISOs/images): losetup -a shows which loop device; umount the loop, then losetup -d.
-l detaches the mountpoint but leaves open files on the device (safe-ish, until they close). True danger is force-umounting NFS with -f mid-write — data can be lost. Find the holders and stop them properly first.
NFS hangs block lsof itself. Use umount -l to detach the path, then process the stragglers. For recurring pinning, audit docker volumes and service WorkingDirectory settings.
Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.
Browse the template store →One-time. Yours to modify. Instant download from the NinjaOps template store.
One short email when new fixes and production templates drop. No spam, unsubscribe anytime.
Spin up a cloud server in 60 seconds and reproduce this fix yourself — pay by the hour.
Sentry — Free tier: see the exact line of code that broke, before users report it.
We earn a commission if you buy through our links — it never costs you extra. More vetted tools on our picks hub · comparing clouds? DigitalOcean vs Vultr and vs AWS · full deals: DigitalOcean · Vultr · NordLayer · Semrush