umount(2)

👑 umount, umount2 — the "ok bye bestie" syscalls

welcome to the umount(2) page, aka the system calls manual entry you're reading at 2am because something is stuck and won't let go. it's giving "we need to talk". no cap, this one's shorter than most, so we're gonna get through it together 🫶

---

🏷️ NAME

umount, umount2 — unmount filesystem

📚 LIBRARY

Standard C library (libc, -lc)

🧚 SYNOPSIS

#include <sys/mount.h>

int umount(const char *target);
int umount2(const char *target, int flags);

🌸 DESCRIPTION

okay so real talk: umount() and umount2() remove the attachment of the (topmost) filesystem mounted on target. that's the whole job. it's the breakup text of filesystems.

heads up: you need appropriate privilege to unmount filesystems. on Linux that means the CAP_SYS_ADMIN capability. so like... you can't just do this as a lil guy. 💀

Linux 2.1.116 added the umount2() system call, and it does exactly what umount() does — unmounts a target — but it also lets you pass extra flags that control how the operation behaves. and bestie, those flags are where the drama lives:

• MNT_FORCE (since Linux 2.1.116) — asks the filesystem to abort pending requests before it even attempts the unmount. this can let the unmount finish without waiting around for some inaccessible server, but it could cause data loss. 😭 and even after aborting requests, if some processes still hold active references to the filesystem, the unmount will still fail. as at Linux 4.12, MNT_FORCE is supported only on these filesystems: 9p (since Linux 2.6.16), ceph (since Linux 2.6.34), cifs (since Linux 2.6.12), fuse (since Linux 2.6.16), lustre (since Linux 3.11), and NFS (since Linux 2.1.116). very "only these girls are invited to the party" of it.
• MNT_DETACH (since Linux 2.4.11) — does a lazy unmount. it makes the mount unavailable for new accesses, immediately disconnects the filesystem and all filesystems mounted below it from each other and from the mount table, and then actually performs the unmount when the mount stops being busy. it's the "i'm not dealing with this right now, i'll deal with it later" of unmounting. iconic.
• MNT_EXPIRE (since Linux 2.6.8) — marks the mount as expired. here's the tea: if a mount isn't currently in use, an initial call to umount2() with this flag fails with the error EAGAIN, but it marks the mount as expired. the mount stays expired as long as no process accesses it. then a second umount2() call specifying MNT_EXPIRE unmounts an expired mount. two-step verification but for breaks. also this flag cannot be specified with either MNT_FORCE or MNT_DETACH — pick a lane.
• UMOUNT_NOFOLLOW (since Linux 2.6.34) — don't dereference target if it's a symbolic link. this flag lets set-user-ID-root programs that let unprivileged users unmount filesystems avoid security problems. so it's the safety goggles flag. wear it.

---

💫 RETURN VALUE

on success, zero is returned. on error, -1 is returned, and errno is set to indicate the error. classic.

🚨 ERRORS

the error values below are the filesystem-type-independent ones. every filesystem type may have its own special errors and its own special behavior — check the Linux kernel source code for the details, bestie, i can't read that for you.

• EAGAIN — a call to umount2() specifying MNT_EXPIRE successfully marked an unbusy filesystem as expired. yes, this is technically the "success" of the expire dance and it's weird, we know.
• EBUSY — target could not be unmounted because it is busy. it's not you, it's the processes.
• EFAULT — target points outside the user address space.
• EINVAL — target is not a mount point.
• EINVAL — target is locked; see mount_namespaces(7).
• EINVAL — umount2() was called with MNT_EXPIRE and either MNT_DETACH or MNT_FORCE.
• EINVAL (since Linux 2.6.34) — umount2() was called with an invalid flag value in flags.
• ENAMETOOLONG — a pathname was longer than MAXPATHLEN.
• ENOENT — a pathname was empty or had a nonexistent component.
• ENOMEM — the kernel could not allocate a free page to copy filenames or data into. memory said no 💀
• EPERM — the caller does not have the required privileges. (it's the CAP_SYS_ADMIN thing again. we told you.)

📜 STANDARDS

Linux. that's it. that's the whole section. periodt.

🕰️ HISTORY

MNT_DETACH and MNT_EXPIRE are available since glibc 2.11.

the original umount() function was called as umount(device) and would return ENOTBLK when you called it with something that wasn't a block device. then in Linux 0.98p4, a call umount(dir) was added, in order to support anonymous devices. and then in Linux 2.3.99-pre7, the umount(device) call was removed, leaving only umount(dir) — because now devices can be mounted in more than one place, so specifying the device doesn't suffice. character development arc fr fr ✨

🗒️ NOTES

🦋 umount() and shared mounts

shared mounts cause any mount activity on a mount — including umount() operations — to be forwarded to every shared mount in the peer group and every slave mount of that peer group. which means umount() of any peer in a set of shared mounts will cause all of its peers to be unmounted, and all of their slaves to be unmounted as well. it's giving group chat: one person leaves, everyone leaves. 😭

this propagation of unmount activity can be particularly surprising on systems where every mount is shared by default. on such systems, recursively bind mounting the root directory of the filesystem onto a subdirectory and then later unmounting that subdirectory with MNT_DETACH will cause every mount in the mount namespace to be lazily unmounted. yeah. all of them. no cap.

to make sure umount() doesn't propagate like that, you can remount the mount using a mount(2) call with a mount_flags argument that includes both MS_REC and MS_PRIVATE before umount() gets called. do the remount first, bestie. trust.

---

👀 SEE ALSO

mount(2), mount_namespaces(7), path_resolution(7), mount(8), umount(8)

---

and that's the whole page, gorgeous 💖 this one came from Linux man-pages 6.20, dated 2026-02-08, and it's the umount(2) entry. now go unmount something responsibly. mwah 🎀