Mount File Systems
by UUID or Label

Configure systems to mount file systems at boot by UUID or label

CIS126RH | RHEL System Administration 1
Mesa Community College

Device names like /dev/sda1 are not stable — add a second disk and the device that was sda1 may become sdb1. Using a filesystem's UUID (universally unique identifier) or label in /etc/fstab ensures the system always mounts the right filesystem regardless of how the hardware is ordered. This module covers discovering UUIDs and labels, setting labels, and writing correct fstab entries. These skills are tested on the RHCSA exam.

Learning Objectives

Explain why UUID and label are preferred over device paths — Describe the problem with device name instability and how UUID and label solve it
Discover filesystem UUIDs and labels — Use blkid and lsblk -f to find the UUID and label of any filesystem
Set filesystem labels — Use e2label, tune2fs, and xfs_admin to assign labels to ext4 and XFS filesystems
Write fstab entries using UUID and label — Configure /etc/fstab with UUID and LABEL= entries and verify they work with mount -a

Why Device Paths are Unreliable

Linux assigns device names like /dev/sda in the order disks are detected at boot. This order can change when hardware is added, removed, or reordered.

A USB drive inserted before boot might take /dev/sda, pushing the internal disk to /dev/sdb
Adding a second internal disk can shift partition numbers
Replacing a disk with a new one preserves the data (restored from backup) but the UUID changes
SAN and iSCSI environments have non-deterministic device ordering

Identifier	Stable?	Uniqueness	Best for
`/dev/sda1`	No — changes with hardware order	Not unique across systems	Interactive one-time mounts only
`UUID=...`	Yes — tied to the filesystem, not the device	Globally unique (128-bit random)	All persistent fstab entries
`LABEL=...`	Yes — set by administrator	Should be unique; not enforced	Readable fstab entries; administrator-named filesystems

Discovering UUIDs and Labels: blkid

blkid queries filesystem metadata and reports the UUID, label, and filesystem type for every block device it can read.

# Show UUID, label, and type for all block devices
$ sudo blkid
/dev/sda1: UUID="abc123-de45-fg67-hi89-jk012345lmno" TYPE="xfs" PARTUUID="..."
/dev/sda2: UUID="def456-gh78-ij90-kl12-mn345678opqr" TYPE="swap"
/dev/sda3: UUID="ghi789-jk01-lm23-no45-pq678901rstu" TYPE="xfs"
/dev/sdb1: UUID="jkl012-mn34-op56-qr78-st901234uvwx" LABEL="datafs" TYPE="xfs"

# Show UUID and type for one specific device
$ sudo blkid /dev/sdb1
/dev/sdb1: UUID="jkl012-mn34-op56-qr78-st901234uvwx" LABEL="datafs" TYPE="xfs"

# Show just the UUID in a script-friendly format
$ sudo blkid -s UUID -o value /dev/sdb1
jkl012-mn34-op56-qr78-st901234uvwx

blkid -s UUID -o value for scripting

The -s UUID -o value flags extract only the UUID value with no surrounding text — ideal for capturing the UUID into a variable for use in scripts that write fstab entries automatically.

Discovering UUIDs with lsblk

lsblk -f provides a tree view that combines the block device hierarchy with filesystem type, UUID, and current mount point.

# Show block devices with filesystem info (tree view)
$ lsblk -f
NAME   FSTYPE FSVER LABEL    UUID                                 MOUNTPOINTS
sda
├─sda1 xfs          boot     abc123-de45-fg67-hi89-jk012345lmno   /boot
├─sda2 swap   1              def456-gh78-ij90-kl12-mn345678opqr   [SWAP]
└─sda3 xfs          root     ghi789-jk01-lm23-no45-pq678901rstu   /
sdb
└─sdb1 xfs          datafs   jkl012-mn34-op56-qr78-st901234uvwx   /data

# Show all columns including size
$ lsblk -fo NAME,FSTYPE,LABEL,UUID,SIZE,MOUNTPOINTS

lsblk -f vs blkid

lsblk -f shows the tree structure of disks and their partitions alongside filesystem identifiers — best for a visual overview. blkid shows the complete attribute set for each device including PARTUUID — best when you need the exact UUID string to copy into fstab.

Setting Filesystem Labels

A label is a human-readable name embedded in the filesystem. It supplements the UUID as an alternative identifier for fstab entries.

XFS labels

# Set a label on an unmounted XFS filesystem
$ sudo xfs_admin -L datafs /dev/sdb1
Writing all SBs
new label = "datafs"

# View the current XFS label
$ sudo xfs_admin -l /dev/sdb1
label = "datafs"

ext4 labels

# Set a label on an ext4 filesystem (can be mounted or unmounted)
$ sudo tune2fs -L datafs /dev/sdb1
tune2fs 1.46.5 (30-Dec-2021)

# Shorthand for ext4 only
$ sudo e2label /dev/sdb1 datafs

# Verify the label was set
$ sudo blkid /dev/sdb1
/dev/sdb1: LABEL="datafs" UUID="jkl012-..." TYPE="xfs"

Setting Labels at Format Time

The most efficient approach is to set the label when the filesystem is created — no separate labelling step is needed.

# Format XFS with a label at creation time (-L flag)
$ sudo mkfs.xfs -L datafs /dev/sdb1
meta-data=/dev/sdb1      isize=512  agcount=4, agsize=655360 blks
...
label = "datafs"

# Format ext4 with a label at creation time (-L flag)
$ sudo mkfs.ext4 -L datafs /dev/sdb1
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with ...
Filesystem label=datafs

# Confirm the label is embedded
$ sudo blkid /dev/sdb1
/dev/sdb1: LABEL="datafs" UUID="jkl012-..." TYPE="xfs"

RHCSA Tip: Set label at mkfs time

On the exam, if you need a label for fstab and you are creating a new filesystem, use mkfs.xfs -L LABELNAME /dev/device to set it in one step. Then use LABEL=LABELNAME in the fstab entry.

The /etc/fstab File Structure

/etc/fstab is read at boot time and by mount -a. Each non-comment line configures one filesystem mount.

# /etc/fstab — six fields, whitespace-separated
# DEVICE  MOUNTPOINT  FSTYPE  OPTIONS  DUMP  FSCKORDER

# Example entries from a typical RHEL 9 system
UUID=abc123-de45-fg67  /boot      xfs   defaults        0 2
UUID=def456-gh78-ij90  none       swap  defaults        0 0
UUID=ghi789-jk01-lm23  /          xfs   defaults        0 1
UUID=jkl012-mn34-op56  /data      xfs   defaults        0 2
LABEL=datafs            /data      xfs   defaults        0 2
/dev/datavg/data        /data      xfs   defaults        0 0

Field	Position	Description
Device	1	`UUID=`, `LABEL=`, or device path
Mount point	2	Directory to mount on; `none` for swap
Filesystem type	3	`xfs`, `ext4`, `swap`, `tmpfs`
Options	4	`defaults` for most cases
Dump	5	`0` = do not back up with dump
Fsck order	6	`0`=skip, `1`=root first, `2`=other fs

Writing fstab Entries with UUID

Using UUID= is the recommended method for all non-LVM partitions in /etc/fstab.

# Step 1: Find the UUID of the new filesystem
$ sudo blkid /dev/sdb1
/dev/sdb1: UUID="jkl012-mn34-op56-qr78-st901234uvwx" TYPE="xfs"

# Step 2: Create the mount point
$ sudo mkdir -p /data

# Step 3: Add the fstab entry
$ sudo vim /etc/fstab
# Add this line (use the actual UUID from blkid):
UUID=jkl012-mn34-op56-qr78-st901234uvwx  /data  xfs  defaults  0 2

# Step 4: Test the entry
$ sudo mount -a
# If no errors appear, the entry is correct

# Step 5: Verify the mount
$ df -h /data
Filesystem             Size  Used Avail Use% Mounted on
/dev/sdb1               10G  104M  9.9G   2% /data

Writing fstab Entries with LABEL

Using LABEL= produces more readable fstab entries but requires that the filesystem has a label and the label is unique.

# Step 1: Format with a label (or set label with xfs_admin)
$ sudo mkfs.xfs -L datafs /dev/sdb1

# Step 2: Verify the label
$ sudo blkid /dev/sdb1
/dev/sdb1: LABEL="datafs" UUID="jkl012-..." TYPE="xfs"

# Step 3: Add the LABEL-based fstab entry
$ sudo vim /etc/fstab
LABEL=datafs  /data  xfs  defaults  0 2

# Step 4: Test and verify
$ sudo mount -a
$ df -h /data

# Mount directly by label from the command line
$ sudo mount LABEL=datafs /data

Labels must be unique

If two filesystems have the same label, the system mounts whichever it finds first — leading to unpredictable behaviour. Choose labels that are unique across all disks that may be attached simultaneously.

Testing fstab Without Rebooting

Always test a new fstab entry before rebooting. A broken fstab can prevent the system from booting or lock it into emergency mode.

# Test all new fstab entries without rebooting
$ sudo mount -a
# No output = success; error messages indicate problems

# Unmount and remount a specific entry to test it in isolation
$ sudo umount /data
$ sudo mount /data   # mount looks up the entry in fstab

# Check what is currently mounted
$ findmnt --verify
Success, no errors or warnings detected in /etc/fstab

# Show the complete mount table in a readable format
$ findmnt
TARGET      SOURCE                    FSTYPE  OPTIONS
/           /dev/mapper/rhel-root     xfs     rw,...
├─/boot     /dev/sda1                 xfs     rw,...
└─/data     /dev/sdb1                 xfs     rw,...

findmnt --verify is the definitive check

findmnt --verify parses /etc/fstab, checks that all mount points exist and all referenced devices or UUIDs can be found, and reports any problems. Run it after editing fstab and before rebooting.

Common fstab Mount Options

The options field in fstab controls how the filesystem is mounted. defaults covers most cases, but specific options are used for security, performance, and special filesystems.

Option	Meaning	Use case
`defaults`	rw, suid, dev, exec, auto, nouser, async	Standard data filesystems
`ro`	Mount read-only	ISO images, backup mounts
`noexec`	Prevent execution of binaries	`/tmp`, `/home` for security hardening
`nosuid`	Ignore setuid/setgid bits	Non-system partitions
`noatime`	Do not update access time on read	Performance improvement for busy filesystems
`nofail`	Do not fail boot if device is missing	Optional external drives, USB storage
`_netdev`	Wait for network before mounting	NFS, iSCSI, SMB mounts
`x-systemd.automount`	Mount on first access (lazy mount)	Slow or optional mounts

Fixing a Broken fstab

A misconfigured fstab can boot the system into emergency mode. Here is how to recover.

# If the system boots into emergency mode with a fstab error:
Welcome to emergency mode! After logging in, type "journalctl -xb" for details.
Give root password for maintenance (or press Control-D to continue):

# Log in as root and fix the fstab entry
emergency:~# mount -o remount,rw /   # ensure root is rw
emergency:~# vim /etc/fstab           # fix the error
emergency:~# mount -a               # test before rebooting
emergency:~# systemctl reboot      # reboot to verify

# The most common fstab mistakes that cause boot failure:
# 1. Wrong UUID (typo or copy-paste error)
# 2. Mount point directory does not exist
# 3. Wrong filesystem type
# 4. Missing required field (too few columns)

A broken fstab is recoverable — do not panic

Emergency mode is the intentional fallback when a critical mount fails at boot. The fix is always: log in as root, remount root read-write if needed, edit /etc/fstab to correct the error, and reboot.

Temporary vs Persistent Mounts

The difference between a temporary mount and a persistent boot-time mount is simply whether the entry exists in /etc/fstab.

Mount type	How to create	Survives reboot?	Use case
Temporary	`mount /dev/sdb1 /mnt`	No — lost at next reboot	Quick access, testing, one-time operations
Persistent (by device)	fstab entry with `/dev/sdb1`	Yes — but path may change if hardware changes	Simple single-disk servers with stable hardware
Persistent (by UUID)	fstab entry with `UUID=...`	Yes — stable regardless of device ordering	All production servers, multi-disk systems
Persistent (by label)	fstab entry with `LABEL=...`	Yes — stable if label is unique	Readable configs, administrator-named filesystems

RHCSA Exam: use UUID or LABEL in fstab

The exam objective specifically names UUID and label as the required methods. A fstab entry using /dev/sdb1 may be accepted but is not the preferred answer. Use UUID= or LABEL=.

UUID and Label Quick Reference

Task	Command
Show UUID and label of all block devices	`sudo blkid`
Show UUID and label of one device	`sudo blkid /dev/sdb1`
Extract UUID value only (for scripting)	`sudo blkid -s UUID -o value /dev/sdb1`
Show block device tree with UUIDs	`lsblk -f`
Set XFS label (unmounted)	`sudo xfs_admin -L LABEL /dev/sdb1`
View XFS label	`sudo xfs_admin -l /dev/sdb1`
Set ext4 label	`sudo tune2fs -L LABEL /dev/sdb1`
Set ext4 label (shorthand)	`sudo e2label /dev/sdb1 LABEL`
Format XFS with label	`sudo mkfs.xfs -L LABEL /dev/sdb1`
Format ext4 with label	`sudo mkfs.ext4 -L LABEL /dev/sdb1`
Test all fstab entries	`sudo mount -a`
Verify fstab is syntactically correct	`findmnt --verify`
Show current mount table (tree)	`findmnt`
Mount by label from command line	`sudo mount LABEL=name /mountpoint`

Common Mistakes

Mistake	What goes wrong	Correct approach
Typo in the UUID string	mount -a reports "can't find UUID=..." — boot may fail	Copy the UUID from `blkid` output; do not type it manually
Using device path in fstab instead of UUID or LABEL	Technically works but not what the exam requires	Use `UUID=` or `LABEL=` as the exam objective specifies
Not testing with `mount -a` before rebooting	Broken fstab entry only discovered at reboot — system may not boot	Always run `sudo mount -a` and check for errors before rebooting
Using a label that already exists on another filesystem	Duplicate label — unpredictable mount behaviour	Check existing labels with `blkid` before assigning a new label
Omitting the mount point directory	mount fails: "mount point /data does not exist"	Create the directory first: `sudo mkdir -p /data`
Wrong field count in fstab line	mount -a may fail to parse the entry or use wrong values	fstab requires exactly six whitespace-separated fields per line

Knowledge Check

Answer these before moving to the next slide.

Why is UUID= preferred over /dev/sdb1 in /etc/fstab for persistent mounts?
Write the command to find the UUID of the filesystem on /dev/sdb1.
You have formatted /dev/sdb1 with XFS and want to set the label webdata. Write the command, and write the alternative that sets the label at format time.
Write the complete fstab entry to mount the filesystem on /dev/sdb1 (UUID: abc123-de45-fg67-hi89-jk01) at /webdata with XFS and default options.
After adding the fstab entry from question 4, what command do you run to test it without rebooting, and what does no output indicate?
The system boots into emergency mode. You realise the fstab entry you added has a typo in the UUID. What do you do?

Knowledge Check — Answers

Device names like /dev/sdb1 are assigned by the kernel in hardware detection order and can change when disks are added, removed, or reordered. A UUID is generated when the filesystem is created and is permanently embedded in the filesystem — it identifies the filesystem regardless of which physical device it is on.
sudo blkid /dev/sdb1 — the output includes the UUID= field. For just the UUID value: sudo blkid -s UUID -o value /dev/sdb1
On an already-formatted filesystem: sudo xfs_admin -L webdata /dev/sdb1 (filesystem should be unmounted).
At format time: sudo mkfs.xfs -L webdata /dev/sdb1 — the preferred approach that requires no separate labelling step.
UUID=abc123-de45-fg67-hi89-jk01 /webdata xfs defaults 0 2
Six fields: UUID, mount point, filesystem type, options, dump (0), fsck order (2).
Run sudo mount -a. No output (no error messages) means the entry was processed successfully and the filesystem is now mounted at /webdata. Confirm with df -h /webdata.
At the emergency mode root password prompt, log in as root. Remount root read-write if needed: mount -o remount,rw /. Edit the fstab file: vim /etc/fstab and correct the UUID. Test: mount -a. Reboot: systemctl reboot.

Key Takeaways

Use UUID or LABEL in fstab — never device paths for persistent mounts. Device paths change when hardware is reordered. UUID is embedded in the filesystem and is globally unique. LABEL is set by the administrator and must be unique. Find both with sudo blkid or lsblk -f.
Set labels at format time or with xfs_admin / tune2fs. mkfs.xfs -L LABEL or mkfs.ext4 -L LABEL sets the label when creating the filesystem. After creation: xfs_admin -L LABEL for XFS; tune2fs -L LABEL or e2label for ext4.
The fstab entry has six fields: device, mountpoint, type, options, dump, fsck. Use UUID=value or LABEL=name as the device field. Use defaults for options. Use 0 2 for data filesystems and 0 0 for swap and LVM volumes.
Always test with mount -a before rebooting. A broken fstab that is found via mount -a is fixed in seconds. A broken fstab found at reboot requires emergency mode recovery. Use findmnt --verify for a deeper syntax check.

Graded Lab

Run sudo blkid to display the UUID, label, and filesystem type of all block devices. Record the UUID of the /boot partition and locate its entry in /etc/fstab to confirm they match.
Format /dev/sdb1 with XFS, setting the label labdata at format time using mkfs.xfs -L labdata. Verify with sudo blkid /dev/sdb1 that both LABEL and UUID are shown.
Create /labdata and add a UUID-based fstab entry for the new filesystem. Test with sudo mount -a and confirm with df -h /labdata.
Unmount /labdata, edit fstab to change the entry from UUID-based to LABEL-based (LABEL=labdata), re-test with mount -a and df -h /labdata.
Run findmnt --verify to confirm fstab has no errors. Run findmnt to see the complete mount tree.
Deliberately introduce a UUID typo in the fstab entry and run sudo mount -a to observe the error. Fix the entry and re-test to confirm recovery.

RHCSA Objective

"Configure systems to mount file systems at boot by UUID or label." The exam task: format a filesystem, find its UUID with blkid, write a UUID= or LABEL= fstab entry, test with mount -a.

Next: Getting Help from Local Documentation

Mount File Systemsby UUID or Label

Configure systems to mount file systems at boot by UUID or label

Learning Objectives

Why Device Paths are Unreliable

Discovering UUIDs and Labels: blkid

Discovering UUIDs with lsblk

Setting Filesystem Labels

XFS labels

ext4 labels

Setting Labels at Format Time

The /etc/fstab File Structure

Writing fstab Entries with UUID

Writing fstab Entries with LABEL

Testing fstab Without Rebooting

Common fstab Mount Options

Fixing a Broken fstab

Temporary vs Persistent Mounts

UUID and Label Quick Reference

Common Mistakes

Knowledge Check

Knowledge Check — Answers

Key Takeaways

Graded Lab

Mount File Systems
by UUID or Label