mount was one of the first commands that made me actually understand Linux’s storage model instead of just memorizing paths. Once I got comfortable with how mounting works — attaching a filesystem onto an existing directory in the tree — a lot of other things clicked too: why Docker containers look the way they do, why /proc and /sys “exist” without taking up disk space, why df -h shows exactly what it shows. This guide covers mount thoroughly, from basic usage to the mount option flags that actually matter for security and performance.
What mount Does
mount attaches a filesystem — whether it’s a physical disk partition, a network share, a virtual filesystem, or even part of another directory tree — to a specified location (the mount point) within the existing directory structure, making its contents accessible at that path.
Checking the version:
mount --version
mount from util-linux 2.39.3 (libmount 2.39.3: selinux, smack, btrfs, verity, namespaces, idmapping, statx, assert, debug)
Basic Syntax
mount [options] <source> <directory>
sudo mount /dev/sdb1 /mnt/data
This mounts the partition /dev/sdb1 at /mnt/data. After this, anything under /mnt/data reflects the contents of that partition; whatever was previously in that directory (on the underlying root filesystem) is temporarily hidden, not deleted, until it’s unmounted again.
Viewing Current Mounts
Running mount with no arguments lists everything currently mounted:
mount
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=2042076k,nr_inodes=510519,mode=755)
tmpfs on /dev/shm type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
tmpfs on /sys/fs/cgroup type tmpfs (rw,relatime)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu)
...
/dev/vda on / type ext4 (rw,relatime,resuid=65534,resgid=65534)
Each line reads as: <source> on <mount point> type <filesystem> (<options>). The equivalent, and generally cleaner, modern alternative for viewing mounts is findmnt, which presents them as an actual tree and supports filtering.
Full Option Reference (Key Flags)
From mount --help:
Options:
-a, --all mount all filesystems mentioned in fstab
-c, --no-canonicalize don't canonicalize paths
-f, --fake dry run; skip the mount(2) syscall
-F, --fork fork off for each device (use with -a)
-T, --fstab <path> alternative file to /etc/fstab
-i, --internal-only don't call the mount.<type> helpers
-l, --show-labels show also filesystem labels
-m, --mkdir[=<mode>] alias to '-o X-mount.mkdir[=<mode>]'
-n, --no-mtab don't write to /etc/mtab
-o, --options <list> comma-separated list of mount options
-O, --test-opts <list> limit the set of filesystems (use with -a)
-r, --read-only mount the filesystem read-only (same as -o ro)
(Additional flags like -t for filesystem type, -B/--bind for bind mounts, and -v for verbose output round out the rest of the interface.)
-t: Specifying Filesystem Type
sudo mount -t ext4 /dev/sdb1 /mnt/data
Usually optional, since mount can typically auto-detect the filesystem type by probing the device’s superblock signature — but explicitly specifying it is good practice in scripts, both for clarity and to avoid ambiguity on unusual or mixed-format devices.
-o: Mount Options
This is where most of the real customization happens:
sudo mount -o ro,noexec,nosuid /dev/sdb1 /mnt/data
Common options:
| Option | Effect |
|---|---|
ro | Mount read-only |
rw | Mount read-write (default) |
noexec | Prevent execution of any binaries from this filesystem |
nosuid | Ignore SUID/SGID bits on this filesystem, preventing privilege escalation via binaries here |
nodev | Don’t interpret character/block special devices on this filesystem |
noatime | Don’t update file access-time metadata on every read (performance benefit) |
relatime | Update access time only when it’s older than modify/change time (a common modern default balancing accuracy and performance) |
sync | All writes are performed synchronously, no write caching |
defaults | Shorthand for rw,suid,dev,exec,auto,nouser,async |
user | Allow a non-root user to mount this filesystem |
uid=, gid= | Force ownership on filesystems without native Unix permissions (like FAT/NTFS) |
Combining noexec,nosuid,nodev on any mount point that holds untrusted or user-uploaded data (like /tmp, a shared upload directory, or removable media) is a genuinely important, common hardening pattern.
-r: Read-Only Mount
sudo mount -r /dev/sdb1 /mnt/data
Equivalent to -o ro. Useful for inspecting a filesystem (like a suspect disk image during forensics, or a recovery scenario) without any risk of accidentally modifying it.
–bind: Bind Mounts
sudo mount --bind /var/www/html /srv/website
A bind mount makes an existing directory accessible at a second location, without duplicating the data — both paths point to the exact same underlying files. This is heavily used in container runtimes (Docker, LXC) to expose host directories inside a container’s filesystem namespace, and in chroot/jail setups to selectively expose specific host paths.
-a: Mount Everything in fstab
sudo mount -a
Mounts every entry in /etc/fstab that isn’t already mounted — this runs automatically during boot, but is also useful after editing /etc/fstab to test the new entries without a reboot.
/etc/fstab: Persistent Mount Configuration
For mounts that should be attached automatically at every boot, entries go in /etc/fstab, one line per mount:
<device> <mount point> <fs type> <options> <dump> <pass>
UUID=1234-5678 /data ext4 defaults 0 2
/swapfile none swap sw 0 0
//server/share /mnt/share cifs credentials=/etc/smbcreds,uid=1000 0 0
<dump>— legacy field for thedumpbackup utility; almost always0on modern systems.<pass>— controlsfsckorder at boot:0means don’t check,1for the root filesystem (checked first),2for other filesystems checked afterward.
Using UUID= instead of a raw device path (/dev/sdb1) is strongly recommended, since device naming (sdb, sdc, etc.) can shift between boots depending on detection order, especially with multiple removable or hot-pluggable devices — but a filesystem’s UUID stays fixed. Find UUIDs with:
sudo blkid
Always test a new /etc/fstab entry with sudo mount -a before rebooting — a broken entry in fstab can, in stricter configurations, leave a system unable to boot cleanly into a normal state, dropping to an emergency/rescue shell instead.
How mount Works Internally
At the system call level, mount (the command) is a wrapper around the mount(2) system call, which asks the kernel to attach a filesystem instance to a directory in the VFS (Virtual File System) namespace. The kernel’s VFS layer is what provides the unified interface — open(), read(), write() — regardless of what actual filesystem driver (ext4, xfs, nfs, overlay, etc.) is handling a given path underneath.
Since Linux kernel 2.4, mount namespaces have existed, which is the mechanism that lets different processes see entirely different mount trees simultaneously — this is foundational to how containers work: a container’s / can be an overlay filesystem entirely invisible to and independent from the host’s own mount namespace, even though both are running on the same kernel.
Mount Namespaces and Containers in More Depth
It’s worth expanding on mount namespaces a bit further, since they’re genuinely one of the more elegant pieces of the Linux storage model and directly explain why containers work the way they do. A mount namespace is a per-process (or per-process-group) view of the mount table — two processes can be running on the exact same kernel, at the exact same time, and see completely different sets of mounted filesystems at the same paths. Process A might see / as an ext4 partition; process B, in a different mount namespace, might see / as an entirely different overlay filesystem, layering a container image’s read-only base layers with a writable layer on top, with no visibility into process A’s actual root filesystem at all.
sudo unshare --mount --fork /bin/bash
Running this creates a new mount namespace and drops you into a shell inside it — mounting or unmounting anything from within that shell has zero effect on the original (host) mount namespace, and vice versa. This single primitive, combined with other namespace types (PID, network, UTS, and others), is the actual low-level foundation that container runtimes like Docker and Podman build on top of; there’s no special “container filesystem” magic beyond mount namespaces, overlay filesystems, and a handful of other kernel namespace features composed together.
OverlayFS specifically deserves a mention here, since it’s the default storage driver behind most container runtimes: it presents a single unified view built from multiple stacked directories — one or more read-only “lower” layers (the image’s baked-in filesystem contents) and a single writable “upper” layer (where any runtime changes actually land), merged together transparently.
sudo mount -t overlay overlay -o lowerdir=/base,upperdir=/changes,workdir=/work /merged
Anything written to /merged actually lands in /changes (the upper layer), while reads transparently fall through to /base (the lower layer) for anything not yet modified — this is precisely the mechanism that lets a container “modify” files from a shared, read-only base image without ever actually touching that base image on disk.
Practical Sysadmin Examples
Mounting a new disk and verifying it worked:
sudo mkdir /mnt/newdisk
sudo mount /dev/sdc1 /mnt/newdisk
df -h /mnt/newdisk
Remounting an already-mounted filesystem with different options (no unmount needed):
sudo mount -o remount,ro /
Useful for switching the root filesystem to read-only during recovery or maintenance without a full unmount (which usually isn’t even possible for a currently-in-use root filesystem).
Mounting an ISO image without burning it to physical media:
sudo mount -o loop,ro /path/to/image.iso /mnt/iso
Testing an fstab entry safely before reboot:
sudo mount -a
findmnt /data
Troubleshooting
- “mount: unknown filesystem type” → the required kernel module or filesystem driver may not be loaded/installed (e.g., trying to mount an
xfsfilesystem on a minimal kernel build withoutxfssupport compiled in). - “mount point does not exist” → create the target directory first with
mkdir, or use-m/--mkdiron newerutil-linuxversions to havemountcreate it automatically. - System won’t boot after editing
/etc/fstab→ boot into rescue/single-user mode, remount root as read-write if needed (mount -o remount,rw /), and fix the offending line. - “Permission denied” mounting as a regular user → normal, since mounting generally requires root, unless the specific entry in
/etc/fstabincludes theuseroption explicitly permitting it.
Security Implications
- Apply
noexec,nosuid, andnodevto any mount point holding data from untrusted sources — this is one of the most impactful, low-cost hardening steps available on a Linux system. - Be cautious with network filesystem mounts (
nfs,cifs) — credentials in/etc/fstabfor CIFS shares should reference a separate, permission-restricted credentials file (credentials=/etc/smbcredswithchmod 600), not be embedded directly infstab, which is often world-readable. - Bind mounts and container mount namespaces are powerful but require care — exposing more of the host filesystem into a container than intended is a common source of container escape or data exposure vulnerabilities.
mount vs Related Commands
| Command | Purpose |
|---|---|
mount | Attach a filesystem to a directory |
umount | Detach a mounted filesystem |
findmnt | Cleaner, tree-structured, filterable view of current mounts |
lsblk | Show block devices and their current mount points |
blkid | Show UUIDs and filesystem types of block devices |
df | Show space usage of mounted filesystems |
Compatibility Across Distributions
mount is part of util-linux and is essentially universal across Linux distributions — Debian, Ubuntu, RHEL, Fedora, CentOS, Arch, openSUSE all ship it with the same core behavior. Filesystem driver support varies more (e.g., btrfs or zfs tooling might need separate packages installed depending on distro), but the mount command’s own interface and option syntax stays consistent.
Summary
mount is the command that makes Linux’s single unified directory tree actually work — attaching disks, network shares, ISO images, and virtual filesystems onto ordinary-looking directories anywhere in that tree. Between understanding mount options (especially the security-relevant noexec/nosuid/nodev trio), knowing how to work confidently with /etc/fstab, and being comfortable with bind mounts, you cover the vast majority of real-world storage administration tasks on any Linux system.
References
man 8 mountman 5 fstabman 8 findmnt- Linux kernel documentation on the VFS layer:
Documentation/filesystems/vfs.rst