Skip to content

How to Unmount a Busy Device in Linux (Force Unmount Guide)

Problem

When I run umount /mnt/samba-share, I get this error:

Terminal output
umount: /mnt/samba-share: target is busy.

Or sometimes this variant:

Terminal output
umount: /mnt/samba-share: device is busy.

No matter how many times I try, the kernel refuses to unmount the filesystem. This happens with Samba mounts, NFS exports, USB drives, and even loopback devices.

Environment

  • Linux kernel 5.x / 6.x (any modern distribution)
  • Filesystem types: ext4, XFS, Samba/CIFS, NFS
  • Typical scenario: managing Samba drives mounted from a SQL database, needing to take them offline reliably

What happened?

The Linux kernel prevents unmounting any filesystem that still has open file handles, active processes, or a process whose current working directory is inside the mount point. The kernel treats this as a safety measure — unmounting while files are in use could corrupt data.

I had a set of Samba shares mounted from a SQL-driven configuration system. When I needed to rotate or remove a share, umount always failed with “target is busy”. The naive approach of adding -f (force) did not help on local filesystems.

Here is the typical output when I check what is going on:

Checking current directory
$ pwd
/mnt/samba-share

That is problem number one — I was standing inside the mount point.

How to solve it?

There are three approaches, ordered from safest to most aggressive.

Diagram showing three types of processes — a shell cd'd into the mount point, a file manager browsing a directory, and a backup daemon — each with a file handle arrow pointing to a mount point labeled /mnt/samba-share, with the kernel showing a locked icon

Approach A: Find and kill the blocking process (safest)

First, check what is holding the mount point open:

Find blocking processes
fuser -muv /mnt/samba-shop

The output looks like this:

fuser output
USER PID ACCESS COMMAND
/mnt/samba-shop: cowrie 12345 F.... dolphin
cowrie 12346 F.... dolphin

In this case, Dolphin (the KDE file manager) had the mount directory open. After closing Dolphin or killing those processes:

Kill blocking processes and unmount
fuser -km /mnt/samba-shop
umount /mnt/samba-shop

The -k flag sends SIGKILL to all processes using the mount point. Use -k -TERM first if you want a graceful kill.

The most common blockers I have seen:

  • A shell cd’d into the mount point — just cd / and try again
  • A file manager (Dolphin, Nautilus) browsing the directory
  • An IDE or editor with a file open on the mount
  • A background process like updatedb or a backup script

Approach B: Lazy unmount (immediate detach)

When you cannot find or kill the blocking process, or when you need the filesystem gone now:

Lazy unmount
umount -l /mnt/samba-shop

The -l flag tells the kernel to detach the filesystem from the mount tree immediately. Cleanup of remaining references happens behind the scenes once all file handles are naturally closed.

Before and after diagram of the Linux mount tree: before shows /mnt/samba-share attached to the tree with active processes; after shows the directory removed from the tree while a ghosted filesystem icon floats away with open processes still attached, labeled 'cleanup happens later'

Important caveats:

  • Data written by processes that keep running after the lazy unmount is silently lost — the writes go nowhere.
  • Always run sync before a lazy unmount to flush pending writes.
  • The mount point directory becomes inaccessible to new processes immediately.

Approach C: Force unmount (NFS only)

Force unmount for NFS
umount -f /mnt/nfs-share

The -f flag only works reliably on NFS mounts where the NFS server has become unreachable. On local filesystems like ext4 or XFS, umount -f silently does nothing — it returns success without actually unmounting.

Quick one-liner

Find, kill, and unmount in one command
fuser -km /mnt/share && umount /mnt/share

The reason

I think the key reason for this error is that the Linux VFS layer tracks every open file descriptor and every process working directory. When umount runs, the kernel walks the in-use list and refuses to detach if any reference exists. This is intentional — an unmounted filesystem with open file handles would cause segmentation faults and data corruption in running processes.

The “target is busy” message is the kernel telling you: “something is still using this, I will not let you shoot yourself in the foot.”

Summary

In this post, I showed three ways to unmount a busy Linux device. The safest approach is fuser -muv to find the blocking process, then kill it and unmount normally. For emergencies, umount -l detaches immediately but risks data loss. The -f flag only works on NFS mounts. Always check your current working directory first — most of the time, you are standing on the mount point.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments