Mount Concepts

A file system existing on a disk does not mean its files automatically show up in the / tree. Linux attaches a file system to a specific directory, and only then can processes reach it through that directory's path. This attaching operation is called a mount, and the directory where it happens is the mount point.

A mount does not move or copy files. It attaches a new view onto the VFS tree introduced in Disk and File System Basics. Paths and File Types, also in this module, shows in practice how path resolution continues once it reaches a mount boundary. This article covers the source, file system type, mount point, and options that make up a mount; how to read findmnt, mountpoint, lsblk, and /proc/self/mountinfo; why content under an existing directory temporarily disappears once something else is mounted there; the difference between the kernel's current state and the persistent plan in /etc/fstab; why UUID= is preferred over a device name; the main mount options and their limits; and finally, on a disposable VM, safely mounting and unmounting a tmpfs while investigating a "the disk is attached, but the application is writing somewhere else" problem.

The Four Parts of a Mount

A basic mount ties these concepts together:

source + file system type + options ──> mount point

• source: a block device, UUID=..., a network export, a source like tmpfs, or an existing directory for a bind mount.
• file system type: the kernel driver, such as ext4, xfs, tmpfs, or nfs.
• mount point: an existing directory, or in some cases a file.
• options: ro, rw, nosuid, nodev, noexec, and file-system-specific settings.

For example:

sudo mount -t ext4 -o ro UUID=<file-system-uuid> /mnt/data

This asks the kernel to mount the ext4 file system identified by that UUID at /mnt/data, read-only. sudo is required because changing the system's mount table normally requires the CAP_SYS_ADMIN capability.

One Tree, Many File Systems

A user sees /, /boot, /var/lib/data, and /proc as a single directory tree. Behind that tree, different sources can be at work:

/                     the root file system
├── boot              possibly its own disk partition
├── proc              the proc file system the kernel provides
└── var/lib/data      possibly a separate ext4/XFS file system, or a network file system

The VFS presents these different implementations through the same generic open, read, write, and stat operations. That is why an application simply opens the path /var/lib/data/orders.db; whether it sits on an NVMe partition, an LVM volume, or a network file system is decided by the mount table, not by the application.

Old Content Hidden Under a Mount

Suppose /mnt/data already contains a file named old.txt. If another file system is mounted directly on top of that directory, old.txt is not deleted, but it becomes unreachable through that path until the mount is removed.

before the mount: /mnt/data/old.txt
after the mount:  /mnt/data/<content of the mounted file system>

Once the mount is removed, the previous directory's content reappears. A non-empty mount point is a risk in production: if the mount fails to come up, an application can end up writing into the hidden directory on the root file system instead, and once the mount returns, it can look like data has "disappeared."

Checking a mount point is empty before mounting:

find <mount-point> -mindepth 1 -maxdepth 1 -print

Replace <mount-point> with the actual directory. No output means the directory is empty; a permission error should not be read as "empty."

Reading the Current Mount State

The kernel is the authoritative source for current mount state. On a modern Linux system, findmnt typically reads /proc/self/mountinfo and presents it in a convenient form.

Which File System Does a Given Path Belong To?

findmnt -T /var/log

A representative result:

TARGET SOURCE         FSTYPE OPTIONS
/      /dev/mapper/ubuntu--vg-ubuntu--lv
                       ext4   rw,relatime

In this example, the nearest mount for /var/log is /, its source is an LVM device, its type is ext4, and it is writable (rw). Lines can wrap depending on the terminal width.

For scripting, name the columns explicitly:

findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS -T /var/log

findmnt's default columns can change between versions, so naming the columns with -o matters for automation.

Is a Path Exactly a Mount Point?

mountpoint /var/log
printf 'exit=%s\n' "$?"

0 means it is exactly a mount point; 1 means it is not. This does not imply /var/log is outside any file system — only that it is not itself a separate attachment boundary.

A quiet check for scripts:

if mountpoint -q /var/log; then
    printf '/var/log is a separate mount point\n'
else
    printf '/var/log is not a separate mount point\n'
fi

The Relationship Between Devices and Mounts

lsblk -o NAME,TYPE,FSTYPE,UUID,SIZE,MOUNTPOINTS

lsblk shows the block device tree. It does not fully describe mounts that are not tied directly to a block device, such as tmpfs, NFS, or a bind mount. Use findmnt for the complete mount picture, and lsblk for disk topology.

/proc/self/mountinfo

head -n 3 /proc/self/mountinfo

A simplified layout of one line:

mount-id parent-id major:minor root mount-point mount-options ... - fstype source super-options

Before the - separator comes information about the mount tree and this specific attachment; after it comes the file system type, source, and superblock options. Characters such as spaces in paths can appear as octal escapes. Parsing this by hand is rarely necessary — findmnt is normally the better tool.

Types of Source

Block Devices and Stable Identifiers

/dev/sdb1 is convenient in interactive diagnostics, but a device name can change if hardware detection order changes. Persistent configuration should use the file system's UUID or label instead:

lsblk -f
blkid

A representative fstab source:

UUID=2b0d0a12-1111-4222-8333-abcdef123456

Do not guess a UUID. Check it exactly with lsblk -f, or with sudo blkid if root access is required. A cloned disk can retain the same UUID as its source — verify uniqueness on the system as well.

Pseudo File Systems

proc, sysfs, and tmpfs may not correspond to any disk partition at all:

findmnt -t proc,sysfs,tmpfs

• proc exposes process and kernel information through /proc.
• sysfs exposes devices and kernel objects through /sys.
• tmpfs stores data using memory and swap; content does not survive a reboot or an unmount.

"RAM only" is too simple a description of tmpfs — its pages can be swapped out, and its size limit is controlled through a mount option.

Network File Systems

An NFS source looks like server:/export; other network file systems use their own syntax. This kind of mount depends on DNS, the network, authentication, and the remote server's state, not just local disk. Boot-time policies such as _netdev, nofail, or a systemd automount unit are chosen based on the situation — none of them is a universal default.

Bind Mounts

A bind mount makes an existing directory tree visible again at another path:

sudo mount --bind <source-directory> <mount-point>

This is neither a copy nor a symbolic link. A bind mount adds a new entry to the VFS mount table; it is commonly used in containers and chroot environments to expose selected directories. Unlike a symbolic link, the result is affected by the process's mount namespace and by mount options.

Mount Options and Their Limits

Common options:

noexec, nodev, and nosuid are useful defense-in-depth measures, but they do not replace directory permissions, mandatory access control policy, container isolation, or application-level security.

Checking the actual options in effect:

findmnt -no TARGET,VFS-OPTIONS,FS-OPTIONS -T <path>

Newer util-linux versions can separate VFS-level options from file-system-specific ones. If an older version uses different column names, check findmnt --help's Available output columns list.

Current State versus /etc/fstab

Running mount changes the kernel's current state. For that attachment to be recreated after a reboot, persistent configuration is normally needed — usually /etc/fstab or a systemd mount unit.

/etc/fstab has six fields:

source  mount-point  fstype  options  dump  fsck-pass

Example:

UUID=<verified-uuid>  /srv/data  ext4  defaults,nosuid,nodev  0  2

1. source: a UUID, label, device, or network source.
2. mount-point: the directory to attach to.
3. fstype: the file system type.
4. options: comma-separated settings.
5. dump: a field for a legacy backup tool, usually 0.
6. fsck-pass: boot-time check order; the root file system is usually 1, other checked local file systems 2, and unchecked ones 0.

The fsck policy varies by distribution and file system. Do not copy the pass value from an ext-family example blindly onto XFS.

Checking the Real fstab Without Changing It

Viewing the current plan read-only:

findmnt --fstab --evaluate

For practice, create a separate file:

lab=$(mktemp -d)
printf 'tmpfs %s tmpfs size=8M,nosuid,nodev,noexec 0 0\n' "$lab/mnt" > "$lab/fstab.test"
mkdir "$lab/mnt"
findmnt --verify --tab-file "$lab/fstab.test"

This checks the test table without mounting anything. The expected result is close to Success, no errors or warnings detected; the exact wording depends on the util-linux version.

Cleanup:

printf 'directory to remove: %q\n' "$lab"
find "$lab" -maxdepth 2 -ls
rm -rI -- "$lab"

fsck: When the Kernel Checks a File System

The sixth /etc/fstab field shown above, fsck-pass, controls whether fsck (or the file-system-specific checker it dispatches to, such as e2fsck for ext4) runs automatically against that mount during boot, and in what order:

• 0: never check this file system at boot.
• 1: check first — reserved for the root file system.
• 2: check after the root file system, in parallel where the file systems live on different disks.

Beyond the boot-time pass number, ext-family file systems can trigger a check automatically based on two independent counters, both configurable with tune2fs:

sudo tune2fs -l /dev/nvme0n1p2 | grep -E 'Mount count|Maximum mount count|Last checked|Check interval'

• tune2fs -c <max-mounts> sets how many times a file system can be mounted before the kernel forces a check on the next boot.
• tune2fs -i <interval> (for example, 6m for six months) sets a maximum time between checks, regardless of mount count.

Neither counter typically fires on a modern server running ext4 continuously for months, since both are commonly set to -1/0 (disabled) on cloud and server images precisely to avoid an unplanned, lengthy check delaying a boot. XFS does not use this mount-count/interval mechanism at all; its integrity checking model relies on xfs_repair run explicitly, not an automatic periodic fsck.

The other trigger is an unclean unmount — a crash, a power loss, or a forced shutdown that prevents the file system from recording that it was cleanly unmounted. On the next mount attempt, the kernel or mount helper detects the dirty flag and a check runs (or is required) before the file system is trusted again.

Running fsck by Hand

sudo fsck -n /dev/nvme0n1p2

• -n: answer "no" to every repair prompt and only report what it finds — the safe, read-only way to see whether a file system has problems, without changing anything.
• -f: force a full check even if the file system is marked clean, needed when you suspect corruption that the clean flag does not reflect.
• -y: answer "yes" to every prompt automatically and apply repairs without asking — appropriate for unattended recovery scripts, but only after -n has already shown you what will be changed.

Reading dmesg or journalctl -b after a suspicious boot is the first place to look for whether an automatic check ran and what it found:

journalctl -b | grep -i 'fsck\|clean\|forced'

Provisioning a fresh volume with LVM, as covered in Disk and File System Basics, and deciding when it needs an integrity check afterward, are related but separate concerns — LVM manages the block device beneath the file system, while fsck validates the file system's own metadata once it already exists on top.

Mount Namespaces: Not Every Process Sees the Same Tree

A mount namespace gives a group of processes its own view of the mount list. A process inside a container can use the same path names as the host while actually seeing a completely different mount tree.

The current shell's own view:

readlink /proc/self/ns/mnt
findmnt -N "$$"

Another process's mount information:

sudo head -n 3 /proc/<PID>/mountinfo

Replace <PID> with the process ID you are investigating. sudo is only needed when procfs permissions restrict reading it.

Mount propagation determines whether a later mount or unmount event in one namespace, or in a bind-mounted tree, spreads to another. The shared, slave, private, and unbindable states matter to container runtimes, but do not experiment with mount --make-* in production. Incorrect propagation can have unexpected effects on both the host and container views.

Lab: Mounting a tmpfs

This lab changes the mount table. Run it only on a disposable Ubuntu Server LTS VM, after taking a snapshot. If the container you are working in has not been granted CAP_SYS_ADMIN, the command will fail — use a VM instead of adding that capability.

Goal and Starting State

A temporary tmpfs, capped at 16 MiB, writable by an ordinary user, and mounted with nosuid,nodev,noexec, is created. A reboot or unmount destroys its content.

lab_mount=/mnt/fs-course-tmpfs
findmnt --mountpoint "$lab_mount"
test -e "$lab_mount" && find "$lab_mount" -mindepth 1 -maxdepth 1 -ls

findmnt should find nothing here. Do not proceed if the directory already exists and is not empty.

Preparing the Mount Point

sudo mkdir -p "$lab_mount"
sudo find "$lab_mount" -mindepth 1 -maxdepth 1 -ls

sudo is needed to create a directory under /mnt. No output from the second command means the directory is empty.

Mounting the tmpfs

The shell expands $(id -u) and $(id -g) to the current user's values before sudo runs:

sudo mount -t tmpfs \
  -o size=16M,nosuid,nodev,noexec,mode=0700,uid="$(id -u)",gid="$(id -g)" \
  tmpfs "$lab_mount"

Verify immediately:

mountpoint "$lab_mount"
findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS --mountpoint "$lab_mount"
df -hT "$lab_mount"

The result should show type tmpfs, a size around 16M, and nosuid, nodev, noexec among the options. The kernel may report additional options as well.

Writing and Checking Capacity

printf 'mount lab\n' > "$lab_mount/marker.txt"
stat "$lab_mount/marker.txt"
df -h "$lab_mount"

The file should belong to the current user. This step is not trying to "defeat" noexec — it only confirms the option's presence through findmnt.

Unmount and Rollback

First confirm the shell itself is not sitting inside the mount:

cd /
sudo fuser -vm "$lab_mount"

fuser can show which processes are using the mount; do not forcibly kill processes without reading the result first. Then:

sudo umount "$lab_mount"
mountpoint "$lab_mount"
sudo rmdir "$lab_mount"

After the unmount, mountpoint is expected to return exit status 1. marker.txt is not preserved. If you see umount: target is busy:

1. confirm with pwd -P that the shell itself is not inside the mount;
2. find the responsible processes with sudo fuser -vm "$lab_mount";
3. stop the relevant service or process the normal way;
4. run umount again.

umount -l (lazy unmount) can hide the underlying problem and detach the resource later instead; do not use it in production without understanding the cause first. The VM snapshot is your full rollback point before this lab.

Practical Scenario: The Application Is Writing to the Wrong Disk

An application's data is supposed to live at /srv/data, and that path is supposed to be mounted on a separate disk. The root file system is filling up.

1. Find the Path's Real Mount

findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS -T /srv/data
mountpoint /srv/data
df -hT /srv/data

If findmnt -T shows TARGET=/ and mountpoint returns exit status 1, then /srv/data is not a separate mount at all — the application has been writing into a plain directory on the root file system.

2. Check the Expected Configuration

findmnt --fstab --target /srv/data
lsblk -f

Interpretation:

• no matching fstab entry: a persistent mount may never have been configured.
• an entry exists, but the kernel shows no such mount: the mount attempt likely failed.
• the UUID cannot be found in lsblk -f: the device is not attached, the UUID is wrong, or you are looking at the wrong namespace.

3. Find the Source of the Failure

On Ubuntu and RHEL-family systems running systemd:

systemctl --failed
journalctl -b -p warning..alert

Instead of guessing the mount unit's name:

systemd-escape --path --suffix=mount /srv/data

The result is typically srv-data.mount. Then check that specific unit:

systemctl status srv-data.mount
journalctl -b -u srv-data.mount

4. Conclusion Before Changing Anything

Mounting the correct disk without first stopping the application can hide the existing /srv/data content and split writes across two locations. A sound recovery plan typically looks like this:

1. schedule a maintenance window;
2. stop the application in a controlled way;
3. back up the existing data currently sitting on the root file system;
4. verify the intended disk and file system read-only;
5. mount it onto the now-empty mount point;
6. migrate or restore the data through a verified process;
7. check ownership, permissions, and service status;
8. keep the old copy for rollback.

These steps require a runbook specific to the production environment; simply running mount -a is not a safe fix on its own.

Common Mistakes

Treating mount Output as a List of Disks

The mount table also includes pseudo, network, and bind mounts. lsblk shows block devices; findmnt shows VFS attachments.

Forgetting the Difference Between df and du

df accounts for a file system's allocated blocks; du sums files in a visible directory tree. A deleted-but-open file, or a directory hidden under a mount, can be the reason the two numbers diverge.

Not Checking Whether a Mount Point Is Empty

A mount does not erase existing content — it temporarily hides it. An application may have written to the root file system while the intended mount was not active.

Treating /dev/sdb1 as a Permanent Name

Device detection order can change. Use a verified UUID=, or LABEL= where appropriate, in fstab.

Treating noexec as a Complete Security Boundary

It blocks direct execution, but not every path through reading and interpreting a file. Permissions and other layers of defense are still necessary.

Assuming a Container and Its Host See the Same Mounts

A mount namespace means the same path string, such as /srv/data, can point at a different source for different processes. Check /proc/<PID>/mountinfo when it matters.

Exercises

1. Run findmnt -T for /, /proc, /sys, /run, and your home directory. Record each one's source, type, and nearest mount point.
2. Compare lsblk -f and findmnt output. Find at least two mounts visible in only one of them, and explain why.
3. Find the root mount's line in /proc/self/mountinfo. Identify its mount-id, parent-id, mount point, type, and source fields.
4. Create a temporary fstab.test, add an incorrect option, and find the error with findmnt --verify --tab-file. Do not touch the real /etc/fstab.
5. On a disposable, snapshotted VM, run the tmpfs lab. Record the mountpoint exit status before, during, and after the mount.
6. On a test host running one container, compare /proc/<PID>/mountinfo between the host shell and the container's PID. Do not change any propagation setting.

Verification criterion: for any given path, you should be able to answer "which source, which file system type, which mount point, and which namespace?" backed by actual command output.

References

• util-linux: mount(8): https://man7.org/linux/man-pages/man8/mount.8.html
• util-linux: findmnt(8): https://man7.org/linux/man-pages/man8/findmnt.8.html
• util-linux: mountpoint(1): https://man7.org/linux/man-pages/man1/mountpoint.1.html
• Linux man-pages: fstab(5): https://man7.org/linux/man-pages/man5/fstab.5.html
• Linux man-pages: mount namespaces: https://man7.org/linux/man-pages/man7/mount_namespaces.7.html
• Linux kernel documentation: Shared Subtrees: https://docs.kernel.org/filesystems/sharedsubtree.html
• Linux kernel documentation: Virtual File System: https://docs.kernel.org/filesystems/vfs.html
• Linux man-pages: fsck(8): https://man7.org/linux/man-pages/man8/fsck.8.html
• Linux man-pages: e2fsck(8): https://man7.org/linux/man-pages/man8/e2fsck.8.html
• Linux man-pages: tune2fs(8): https://man7.org/linux/man-pages/man8/tune2fs.8.html