Mounting and /etc/fstab

Mounting attaches a filesystem to a directory in the single tree that starts at /. Linux has no drive letters: a disk, a partition, an NFS export, or a tmpfs in RAM all become visible only after you mount them onto a directory called a mount point. After the mount, paths beneath that directory resolve to the attached filesystem; before it, they resolve to whatever was on the parent filesystem at that location.

The operational consequence lives in /etc/fstab, the table the system reads at boot to mount everything automatically. A single bad line — a wrong UUID, a missing filesystem, or a typo in the options — can drop the machine into an emergency shell instead of a login prompt. On a remote server with no console, a broken fstab means a trip to the provider's recovery mode. This is the most common way a healthy server fails to come back from a reboot.

Mount mechanics and the mount table

A mount binds a block device or remote source to a mount point and a filesystem driver. The kernel tracks every active mount in a table you read through /proc/self/mountinfo; the findmnt command renders that table as a tree and is the right tool for inspecting it. The legacy mount with no arguments and the /etc/mtab file still work, but findmnt shows propagation flags and source UUIDs that the old output hides.

A manual mount needs the source, the target, and usually the type. The kernel can often autodetect the type, but naming it avoids surprises with ambiguous superblocks.

findmnt /home              # where is /home mounted from, and how
mount -t ext4 /dev/sdb1 /mnt   # attach a device to a target
umount /mnt                  # detach; fails if a process holds it open
lsof +D /mnt                 # find what is blocking the umount

Mounting onto a non-empty directory does not delete the existing contents; it hides them until you unmount. This is a frequent source of "my files vanished" reports: a disk mounted over /var/log shadows whatever was already there, and the original files reappear the moment the mount goes away. A umount fails with target is busy while any process has an open file or a working directory inside it, which is why you reach for lsof +D or fuser -m before forcing it.

/etc/fstab fields and syntax

Each non-comment line in /etc/fstab has six whitespace-separated fields: the source, the mount point, the filesystem type, the options, a dump flag, and the fsck pass number. The dump field is a relic and is almost always 0. The pass field controls fsck order at boot: 1 for the root filesystem, 2 for other local filesystems, and 0 to skip the check entirely, which is correct for network and pseudo filesystems.

# <source>                                  <mount point>  <type>  <options>              <dump> <pass>
UUID=7c3a...e1                              /              ext4    defaults               0      1
UUID=9f21...44                              /home          ext4    defaults,nosuid        0      2
192.168.1.10:/export/data                  /data          nfs     defaults,_netdev       0      0
tmpfs                                      /tmp           tmpfs   defaults,size=2G      0      0

Identify the source by UUID or filesystem label, not by the kernel device name. Device names like /dev/sdb1 are assigned in the order the kernel enumerates disks, which can change when you add a controller, reorder cables, or move the disk to another machine. A UUID is written into the filesystem superblock and travels with the data; read it with blkid or lsblk -f. On Debian and Ubuntu the installer writes UUID-based entries by default for this reason.

After editing the file, validate it before you trust it to a reboot. mount -a attempts every entry not already mounted and reports failures; on a systemd host systemctl daemon-reload followed by findmnt --verify catches malformed lines and unreachable sources. Skipping this step is the difference between catching a typo now and discovering it during the next maintenance window.

Mount options that matter

The options field is a comma-separated list passed to the filesystem driver, and several of them are security and reliability controls rather than conveniences. nosuid stops set-user-ID bits from granting privilege on that mount, nodev stops device nodes from being interpreted, and noexec blocks execution of binaries. The standard hardening pattern applies all three to filesystems that should only ever hold data, such as /tmp, /var/tmp, and any user-writable upload directory.

Option	Effect	Typical use
nosuid	Ignore set-UID / set-GID bits	/tmp, /home, removable media
nodev	Ignore device special files	Any non-system data mount
noexec	Block execution of binaries	/tmp, upload directories
ro	Mount read-only	Reference data, recovery
noatime	Skip access-time writes	Busy data and log volumes
nofail	Boot even if the mount fails	Optional and removable disks

Two options change boot behavior and are easy to get wrong. nofail tells systemd to continue booting if the device is missing instead of dropping to an emergency shell, which is what you want for a backup disk that is not always present and what you must not use for the root or /var filesystem. _netdev marks a mount as depending on the network so systemd waits for connectivity before attempting it. systemd already classifies NFS and CIFS as network mounts from their filesystem type, so _netdev is the override for cases the type does not reveal, such as an iSCSI volume or another network block device, which can otherwise hang the boot or fail because the network is not up yet.

noatime is the cheapest performance win on a busy filesystem. By default Linux updates a file's access time on every read (the relatime compromise limits this to roughly once a day), which turns reads into writes. Setting noatime eliminates those writes; the cost is that tools relying on access time, which are rare on a server, stop seeing accurate values.

systemd mount units and automount

On any modern Debian, Ubuntu, or Red Hat system, systemd is the thing that actually performs the mounts. At boot, systemd-fstab-generator reads /etc/fstab and converts each line into a transient .mount unit, named after the mount point with slashes turned into dashes — /data becomes data.mount. This means fstab and native unit files are the same mechanism underneath, and you inspect a failed mount with systemctl status data.mount and journalctl -u data.mount like any other unit.

For a mount you want deferred until first access, use an automount instead of mounting at boot. Adding x-systemd.automount to an fstab entry creates a matching .automount unit: systemd watches the mount point and performs the real mount only when a process touches it. This keeps boot fast and avoids hanging on a slow NFS server until something actually needs it. Pair it with x-systemd.idle-timeout=600 to unmount after ten minutes of inactivity.

# lazy-mount an NFS share on first access, unmount when idle
nas:/export/media  /mnt/media  nfs  _netdev,x-systemd.automount,x-systemd.idle-timeout=600,noauto  0  0
# bind mount: make an existing directory visible at a second path
/srv/app/data  /var/www/data  none  bind  0  0

Two special mount kinds round this out. A bind mount, declared with the bind option and a source that is a directory rather than a device, makes an existing part of the tree appear at a second path without copying data — the standard way to expose one directory inside a chroot or a service's working tree. A tmpfs is a filesystem that lives entirely in RAM and swap, used for /tmp or /run where speed matters and persistence does not; size it explicitly, because an unbounded tmpfs can consume all of memory and trigger the OOM killer.

The systemd path replaces the older autofs daemon for most cases, but the trade-off is coupling: your mount logic now lives in the init system, and debugging it means reading journal logs rather than a standalone config. On a host that runs autofs for dynamically generated home directories from a directory service, that purpose-built daemon is still the better fit.