mount and umount

Swap Management covered how to prepare and enable virtual memory — like an ordinary filesystem, it first requires preparing the device (mkswap or mkfs), then "attaching" it to the system. For filesystems, this attachment step happens through the mount command: a newly created or existing filesystem's device stays inaccessible through an ordinary path until it's attached to a specific directory (a mount point). This article covers the mount and umount commands, their main options, and common problems. The next article, fstab, builds on this by making mounts persist across reboots.

What You Will Learn

By the end of this article you will be able to:

• use the basic syntax of mount and umount;
• explain what a bind mount is and when it's needed;
• change a mounted filesystem's parameters with mount -o remount without unmounting it;
• diagnose a "device is busy" error with lsof/fuser and know when umount -l (lazy umount) is appropriate;
• have a general understanding of the mount namespace concept;
• distinguish the purpose of virtual filesystems like proc, sysfs, and tmpfs.

mount: Basic Syntax

The simplest form:

sudo mount /dev/sdb1 /mnt/data

Here, /dev/sdb1 is the device (or partition) being mounted, and /mnt/data is the mount point — the directory under which the filesystem's contents will appear. The mount point must already exist as an empty directory:

sudo mkdir -p /mnt/data
sudo mount /dev/sdb1 /mnt/data

mount with no arguments lists every currently mounted filesystem:

mount

Explicitly specifying the filesystem type when needed (mount usually detects it automatically):

sudo mount -t ext4 /dev/sdb1 /mnt/data

Useful general mount options (combined with -o, comma-separated):

sudo mount -o ro /dev/sdb1 /mnt/data

Bind Mount: Showing One Directory at a Second Location

A bind mount doesn't mount a separate device — it "moves" an existing directory within a filesystem to another location, really pointing the second location at the first. No new disk or partition is needed:

sudo mkdir -p /srv/www /var/www/html
sudo mount --bind /srv/www /var/www/html

From then on, any change inside /var/www/html also shows up in /srv/www — they're really one place, viewed through two paths.

Bind mounts are commonly used for:

• exposing a single directory from the host system into a container or chroot environment;
• adapting a directory to a path another program expects, without physically moving it;
• opening a specific directory read-only through a read-only bind mount:

sudo mount --bind -o ro /srv/www /var/www/html

mount -o remount: Changing Options Without Unmounting

Some parameters of an already-mounted filesystem (for example, ro to rw) can be changed without unmounting and remounting:

sudo mount -o remount,rw /mnt/data

This is useful, for example, when a system boots read-only (the root filesystem mounted with ro for maintenance) and needs to be opened for writing:

sudo mount -o remount,rw /

remount works even while the filesystem is busy, since it doesn't replace the mount point — it only updates the flags on the existing mount.

umount: Detaching a Filesystem

sudo umount /mnt/data

or by device path:

sudo umount /dev/sdb1

Both produce the same result — the important thing is that the filesystem isn't in use by anyone at that moment.

The "device is busy" Error and Diagnosing It

If the filesystem has an open file, is the current working directory (cd) for some shell, or has a running process on it, umount refuses:

umount: /mnt/data: target is busy.

There are two main tools for finding out which process is holding the filesystem busy.

lsof — shows open files under a mount point:

sudo lsof +D /mnt/data

fuser — shows the processes using a mount point in a shorter format:

sudo fuser -vm /mnt/data

The result shows the matching process PID and name. Stopping that process properly (for example, closing the service with systemctl stop) is the safest fix. fuser can also forcibly terminate the processes:

sudo fuser -km /mnt/data

Lazy Umount (umount -l)

Sometimes a process can't be identified immediately, or stopping it is risky, but the filesystem still needs to be detached from its mount point quickly. umount -l (lazy) removes the mount point from the filesystem hierarchy immediately, but the actual detach happens only once the processes holding the device finish:

sudo umount -l /mnt/data

A Brief Word on Mount Namespaces

On a modern Linux kernel, mount information isn't global — each process can have its own mount namespace. This means a change made with mount/umount in one terminal usually applies to the whole system (or at least that user's session) unless a special namespace is in use, but containers (Docker, LXC) and tools like unshare/chroot can each have their own, isolated mount view.

Practical consequence: mount/df output inside a container can differ from the host system — this isn't a bug, it's the natural result of mount namespace isolation. Studying this in depth belongs to a containerization module (Docker, for example); it's mentioned here only to explain why mount results can sometimes differ from what you'd expect.

Virtual Filesystems: proc, sysfs, tmpfs

Many lines in mount output belong not to a physical disk, but to virtual filesystems created by the kernel. They don't occupy disk space — instead they present kernel data in file form:

• proc (/proc) — presents information about running processes and kernel parameters as files. For example, /proc/cpuinfo, /proc/meminfo.
• sysfs (/sys) — structured information about devices, drivers, and kernel subsystems; device parameters can often be read from here, and (carefully) written to.
• tmpfs — a temporary filesystem living in RAM. /tmp or /run are often mounted as tmpfs — their contents disappear on reboot, but they're much faster than disk.

df -hT | grep -E 'proc|sysfs|tmpfs'

These filesystems normally don't need to be mounted/unmounted manually — they're prepared automatically at boot. Knowing about them matters because not every line that appears in mount/df output means "disk."

Practical Scenario: Safely Unmounting Before Replacing a Disk

Problem. An external USB disk mounted at /mnt/backup is no longer needed and needs to be physically unplugged, but umount fails with "target is busy."

Inspection.

sudo fuser -vm /mnt/backup

                     USER        PID ACCESS COMMAND
/mnt/backup:         root       2214 ..c..  rsync

This reveals an rsync process is still working on the filesystem — likely a backup task running in the background.

Action. Once the process is identified, rather than killing it forcibly, waiting for it to finish or stopping it properly makes more sense:

# watch the process's state
ps -p 2214 -o pid,etime,cmd

# if stopping the process is safe (e.g. it's a script that can be re-run)
sudo kill 2214
sleep 2
sudo umount /mnt/backup

If the process can't be stopped or there's no time, a lazy umount is used as an alternative, and the disk is detached physically later:

sudo umount -l /mnt/backup

Result.

mount | grep /mnt/backup

If the command returns nothing, the mount point has been removed from the hierarchy.

Conclusion. A "device is busy" error almost always means a process is using the filesystem. Proper diagnosis (lsof/fuser) solves the problem without hiding it; umount -l should only be used as a last resort when a process genuinely can't be stopped safely.

Common Mistakes

Using a Non-Empty Directory as a Mount Point

If the chosen mount point directory already contains files, they temporarily "disappear" once mounted (they're still there underneath the filesystem, but hidden because a new filesystem is now mounted on top). This isn't data loss, but it causes confusion — an empty directory should be used as a mount point.

Passing the Wrong Path to umount

umount /mnt/data/subdir only works if subdir is separately mounted. To detach the whole /mnt/data filesystem, its actual mount point or device name must be given.

Forgetting a Manually Mounted Filesystem Disappears After a Reboot

A change made with the mount command is temporary — it isn't preserved across a reboot. A permanent mount requires an entry in /etc/fstab.

Exercises

1. In a disposable VM, create an empty partition or loop device (dd + losetup, or an extra virtual disk), format it with mkfs.ext4, and mount it at /mnt/test.
2. Link two directories with --bind and confirm that writing a file to one shows up in the other.
3. cd into a mounted filesystem from one terminal and try umount from another — get the error, then find the cause with fuser -vm.
4. Switch a filesystem to read-only with mount -o remount,ro, try writing to it and see the error, then revert with remount,rw.

Verification criterion: given a "device is busy" error, you should be able to state the exact command that identifies the responsible process before attempting to force anything.

Summary

mount attaches a device (or, via --bind, an existing directory) to a specific point in the filesystem hierarchy, and umount detaches it. -o remount safely changes parameters even on a busy filesystem, while lsof/fuser pinpoint the cause of a "device is busy" error. All of these commands are temporary — nothing survives a reboot. The next article, fstab, solves exactly this problem, introducing a permanent file that applies the mount configuration automatically at every boot.

References

• man7.org: mount(8)
• man7.org: umount(8)
• man7.org: lsof(8)
• man7.org: fuser(1)
• man7.org: mount_namespaces(7)
• man7.org: proc(5)
• Red Hat: Mounting file systems