A mount point is an existing directory in the filesystem tree where another filesystem is attached, so that the contents of that filesystem appear under the directory’s path. In Linux, there are no drive letters: every disk partition, network share and virtual filesystem becomes reachable by mounting it onto a directory of the single tree that starts at the root directory.
Mounting is what lets /home live on a separate disk, /boot sit on a small partition and /proc expose kernel data as files. The mount point itself is an ordinary directory; while a filesystem is mounted on it, its original contents are hidden until the filesystem is unmounted.
How mounting works in the Linux filesystem
When a filesystem is mounted, the kernel records a mount entry that links the directory’s path to the root of the new filesystem. Path lookup then crosses the mount boundary transparently: a program opening /home/user/notes.txt does not need to know that /home is on a different disk with a different filesystem type, such as ext4, XFS or Btrfs.
Each mount has three essential elements: a source, such as a block device, a network export or a pseudo-filesystem name; a filesystem type; and mount options that control behavior. The mount command or the mount system call creates the entry, and umount removes it.
The kernel lists active mounts in /proc/self/mountinfo, and the findmnt command presents them as a readable tree. Because inode numbers are unique only within one filesystem, hard links cannot cross a mount point, while symbolic links can point anywhere because they store a path.
Mounts can also be stacked: mounting a second filesystem on the same directory hides the first one until the top mount is removed. Only root, or a user permitted by the user or users option in fstab, may mount filesystems, which prevents ordinary users from replacing system directories with their own content.
Typical mount points and what they hold
The Filesystem Hierarchy Standard and common distribution practice define well-known mount points. Some are usually on separate partitions; others are virtual filesystems created by the kernel or systemd at boot.
| Mount point | Typical filesystem | Purpose |
|---|---|---|
| / | ext4, XFS or Btrfs | Root of the entire tree |
| /boot and /boot/efi | ext4 and FAT32 (ESP) | Kernels, initramfs and the bootloader |
| /home | ext4, XFS or Btrfs | User data, often on a separate volume |
| /var | ext4 or XFS | Logs, databases and caches that grow |
| /proc and /sys | proc and sysfs | Kernel and device information |
| /dev | devtmpfs | Device nodes |
| /tmp and /run | tmpfs | Temporary files held in memory |
| /mnt and /media | Varies | Manual and removable media mounts |
Separating fast-growing directories such as /var or /home onto their own filesystems prevents a full log directory or a large upload from filling the root filesystem and stopping the system.
Mount options and persistent configuration
Mount options change how the attached filesystem behaves and are an important hardening tool. They are given with -o on the command line or in the fourth field of /etc/fstab.
| Option | Effect | Typical use |
|---|---|---|
| ro | Mount read-only | Recovery, shared images, integrity |
| noexec | Forbid executing binaries | /tmp and upload directories |
| nosuid | Ignore setuid and setgid bits | Removable media and user-writable mounts |
| nodev | Ignore device files | Any filesystem that is not /dev |
| noatime | Skip access-time updates | Reducing write load on busy disks |
| nofail | Do not stop boot if missing | Optional disks and network shares |
Persistent mounts are defined in /etc/fstab, one line per filesystem with source, mount point, type, options, dump flag and check order. Sources should be referenced by UUID or filesystem label instead of device names such as /dev/sdb1, because device names can change between boots. On systemd-based systems, each fstab line is converted into a mount unit, which also allows ordering and on-demand automounting.
Network shares and rarely used disks often benefit from automounting. The fstab option x-systemd.automount creates a placeholder at the mount point and mounts the filesystem only on first access, optionally unmounting it again after an idle timeout. This shortens boot time and keeps a missing NFS or SMB server from delaying startup.
Mount point compared with related mechanisms
Several mechanisms make content appear at another path, but they work at different levels. Choosing the wrong one leads to backups that miss data or links that break across systems.
| Mechanism | Works at | Key difference from a mount point |
|---|---|---|
| Mount point | Kernel mount table | Attaches a whole filesystem |
| Bind mount | Kernel mount table | Shows an existing directory at a second path |
| Symbolic link | File inside a filesystem | Stores a path; resolved at access time |
| Hard link | Directory entry to an inode | Same filesystem only; no directories |
| Overlay mount | Union of several layers | Merges a read-only and a writable layer |
Bind mounts and mount namespaces are the basis of containers. Each container receives its own namespace with a private set of mounts, and host directories are exposed to it as bind mounts, which is why mount propagation settings such as shared, private and slave affect what a container sees.
Common mistakes with mount points
The classic mistake is writing data into a mount point directory while nothing is mounted there. The files land on the root filesystem and become invisible as soon as the real filesystem is mounted, which consumes space that tools such as du cannot explain.
- Target is busy errors on umount mean a process still has files or its working directory there;
fuserorlsofidentifies it. - A wrong fstab line can drop the system into emergency mode; nofail and testing with
mount -aprevent this. - Network mounts without timeouts can hang processes when the server disappears.
- Backups that do not cross mount points silently skip data stored on separate filesystems.
- Lazy unmounting detaches the path but leaves open files active, which can hide ongoing writes.
Understanding it simply
Picture a large office building with one main entrance. When a new wing is built, it is connected to an existing corridor, and from then on people walk into it through a door in that corridor.
A mount point is that door. Linux has one single tree of folders, and every disk, USB stick or network drive is attached to a chosen folder. Opening that folder takes you into the attached storage.
Applied in practice
A database server stores data on a 2 TB volume that is separate from the 50 GB system disk. The administrator formats the volume with XFS, creates the directory /var/lib/postgresql and adds an fstab entry that uses the volume’s UUID, the noatime option and nofail, then verifies it with mount -a and findmnt.
Months later, a failed disk controller prevents the volume from appearing at boot. Because of nofail, the system still boots, but the database service is configured to require the mount and stays stopped, instead of starting with an empty directory on the system disk. The team replaces the controller, the volume mounts again and no data is written to the wrong filesystem.