Unmount a Linux Filesystem Safely with umount

umount detaches one mounted filesystem by its mountpoint, cleanly and with a check that it actually worked. The examples follow the local umount(8) manual from util-linux 2.39.3. The installed executable reports util-linux 2.42.4 on this machine, so check umount --help or umount --version if you need to reconcile a different host.

Allow about ten minutes for a normal unmount, longer if you need to hunt down a process holding the filesystem open. You need a shell, an existing mount that is safe to detach, and normally root privileges. Unmounting can interrupt a service or make files temporarily unavailable, so do not experiment on a production mount or a path holding data you care about.

Warning: umount only detaches a filesystem from the file hierarchy. It does not copy data elsewhere, stop every service using the path, or repair an unhealthy filesystem.

1. Identify the exact mountpoint

Use the directory where the filesystem is mounted, not the device name. The manual says a device is accepted too, but that form is obsolete and ambiguous when one device is mounted in more than one place. Replace the example below with an existing, non-critical mountpoint.

$ MOUNTPOINT='/mnt/example'
$ findmnt --target "$MOUNTPOINT"

The output should describe the filesystem covering that path. If findmnt reports nothing, stop: the path is not a mounted filesystem target for this task. A path below a mountpoint can look like an ordinary directory, so keep the exact mountpoint in the variable.

Checkpoint: confirm the command you are about to run and the privilege boundary:

$ printf 'about to unmount: %s\n' "$MOUNTPOINT"
$ command -v umount
$ umount --version

2. Check for an obvious user or service dependency

A filesystem counts as busy when a process has an open file on it, has its working directory there, or is using a swap file on it. Your own shell is a common culprit: do not run the shell from inside the mount you are about to detach.

$ cd /
$ pwd
/

For a service-owned mount, identify the service and arrange a maintenance window before stopping it. A read-only investigation, if you have the usual process tools, can include:

$ sudo fuser -vm "$MOUNTPOINT"

• Treat the output as evidence. The exact diagnostic format depends on the installed fuser, and the listed processes are something to investigate, not a list to kill blindly.
• Do not stop processes casually. That can lose work, and it is outside the unmount operation itself.

3. Unmount the mountpoint

This is the state-changing step. Ask an administrator to run it, or use sudo if your account is authorised:

$ sudo umount "$MOUNTPOINT"

Success normally produces no output and returns status 0. Verify it immediately:

$ printf 'umount status: %s\n' "$?"
umount status: 0
$ findmnt --target "$MOUNTPOINT"

After a successful unmount, the second command should print no matching mount. The directory itself may still exist as an empty ordinary directory; unmounting does not remove it. Undoing the operation is simply mounting the filesystem again using the same command or service configuration that created it in the first place.

Warning: do not assume an empty result proves the right target was detached. Check the mount table against the path you recorded. When several layers are mounted at one path, an ordinary check can expose another layer rather than the underlying directory.

4. Handle a busy filesystem without guessing

If umount says the target is busy, go back to step 2. Check every terminal, shell, service, container and scheduled job that might be using the path: a process can keep a filesystem busy even when its visible file is not obvious. Add diagnostic output for more detail:

$ sudo umount --verbose "$MOUNTPOINT"

Do not jump straight to --force. In this version it is meant for an unreachable NFS system, and the manual warns it does not guarantee the command will not hang. It is not a general-purpose way to override local file handles.

5. Choose recovery options deliberately

--lazy detaches the filesystem from the file hierarchy right away and cleans up references once it is no longer busy:

$ sudo umount --lazy "$MOUNTPOINT"

• Know why it exists. The manual recommends it mainly to prevent shutdown hangs caused by an unreachable network share.
• Know the trade-off. Remounting the share will not be possible, and a reboot is expected soon for network filesystems or local filesystems with submounts.
• There is no reverse. No command undoes a lazy unmount while old references are still being cleaned up; remount later using the original configuration if that is safe.

--read-only is different. If the unmount fails, it asks the system to try remounting the filesystem read-only instead. It is a damage-limitation move, not a successful unmount and not a substitute for finding the process using the filesystem:

$ sudo umount --read-only "$MOUNTPOINT"

Check the exit status and mount table after this attempt. If the filesystem is still mounted, treat it as mounted, and confirm whether it is now read-only before relying on that.

6. Know the batch and loop-device traps

umount --all tries to unmount filesystems recorded in the kernel mount table, with several system filesystems excluded. It is a broad, service-disrupting action, not a cleanup shortcut. If you genuinely need a constrained batch action, combine it with --types or --test-opts, and only after reviewing the mounts it can match.

For a filesystem mounted over a loop device, umount normally handles loop devices that mount created through the kernel's autoclear feature. --detach-loop explicitly frees the loop device when you need that. Do not detach a loop device separately until you have confirmed which mount owns it.

Done means

• Confirmed the mountpoint. You recorded it and checked that it was actually mounted.
• Cleared out first. Your shell was outside the filesystem before the state-changing command ran.
• Checked the exit status. umount returned status 0, or you recorded and investigated the failure.
• Verified it is gone. findmnt --target "$MOUNTPOINT" shows no remaining matching mount after an ordinary unmount.
• Kept the way back. You have the original mount command or service configuration ready if the filesystem needs remounting.