/etc/fstab

/etc/fstab, the filesystem table, declares filesystems, swap areas, bind mounts, network sources, and other attachments that system tools may mount or activate. Entries can participate in boot, but options such as noauto, automount integration, and service-manager policy affect when or whether that happens.

The Six Fields

A conventional entry has six whitespace-separated fields:

UUID=130b882f-7d79-436d-a096-1e594c92bb76 /data ext4 defaults,nosuid,nodev 0 2

1. Source: a device path, UUID=, LABEL=, network source, or another supported specification.
2. Target: mount point, or none for uses such as swap where appropriate.
3. Type: filesystem type, swap, none, or an accepted automatic type.
4. Options: a comma-separated list interpreted by mount helpers and integration layers.
5. Dump field: historically controls the dump backup utility; 0 commonly disables participation.
6. Pass field: controls boot-time fsck ordering where applicable; 0 disables automatic checking through this mechanism.

Whitespace inside a field must be escaped using fstab syntax such as \040 for a space. A # begins a comment outside a field.

Stable Source Identifiers

For local filesystems, a filesystem UUID is often more stable than /dev/sdX enumeration:

$ lsblk -f
$ sudo blkid

Use UUID=... only after confirming the identifier belongs to the intended filesystem. Reformatting creates a new UUID, and block-level clones can duplicate one. PARTUUID= instead identifies a partition-table entry and has different semantics.

Mount Options and Check Fields

defaults expands to an implementation-defined conventional option set; it is not necessarily the safest policy for every mount. Add options based on trust and workload, such as read-only access or restrictions on device nodes and setuid behavior. Network and removable filesystems can need timeout, dependency, or failure-tolerance policy so boot does not stall unexpectedly.

For filesystems supported by fsck, the root filesystem conventionally uses pass 1 and other checked local filesystems pass 2. Filesystem-specific practice can differ—for example, some types do not use generic boot-time fsck—so follow the installed filesystem and distribution documentation rather than assigning 2 mechanically.

Editing with a Recovery Path

An invalid root, boot, or required network entry can interrupt startup. Before editing:

1. Confirm a current backup and console or rescue access.
2. Copy the existing file while preserving permissions.
3. Verify source identity and create the intended mount point.
4. Make one scoped change.
5. Validate and test before rebooting.

Do not put credentials directly in a world-readable fstab entry. Use the relevant mount helper's protected credential mechanism.

Validating Without Assuming Success

Start with a static check where supported:

$ sudo findmnt --verify --verbose

Then test the specific new entry under controlled conditions, confirm it with findmnt, and unmount if the test was temporary. mount -a attempts many eligible entries and can contact networks or attach unintended sources; it also skips already mounted and noauto entries, so it is neither a harmless syntax checker nor complete proof.

On systemd-based systems, reload manager configuration after editing fstab so generated mount units are refreshed, then verify dependencies and boot behavior according to local documentation.

Practice in Manage Linux Partitions and Filesystems with the lab's recovery-safe secondary storage.

Summary

You can now read and validate a persistent filesystem-table entry.

1. Parse source, target, type, options, dump, and pass fields.
2. Select a verified identifier with the intended identity semantics.
3. Choose mount and checking policy for the actual filesystem.
4. Preserve rescue access and make one scoped edit.
5. Combine static validation, targeted mounting, and boot-policy checks.