Study guide

12.1 Mount File Systems at Boot by UUID or Label

Red Hat Certified System Administrator RHCSA

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Lab Setup & Performance-Based Study Strategy

2 Essential Tools: Shell, Redirection & Text Analysis

2.1 Shell Prompt and Command Syntax 2.2 Input-Output Redirection and Pipes 2.3 grep and Regular Expressions for Text Analysis

3 Essential Tools: Remote Access, Users & Text Editing

3.1 Access Remote Systems Using SSH 3.2 Log In and Switch Users in Multiuser Targets 3.3 Create and Edit Text Files

4 Essential Tools: Files, Links & Archives

4.1 Create, Delete, Copy, and Move Files and Directories 4.2 Hard and Soft Links 4.3 Archive and Compress with tar, gzip, and bzip2

5 Essential Tools: Permissions & System Documentation

5.1 List, Set, and Change Standard ugo/rwx Permissions 5.2 System Documentation: man, info, and /usr/share/doc

6 Manage Software: RPM and Flatpak

6.1 Configure Access to RPM Repositories 6.2 Install and Remove RPM Software Packages 6.3 Configure Access to Flatpak Repositories 6.4 Install and Remove Flatpak Software Packages

7 Create Simple Shell Scripts

7.1 Conditional Execution: if, test, and [] 7.2 Looping Constructs for Files and Input 7.3 Process Script Inputs ($1, $2, and Beyond) 7.4 Process Shell Command Output in Scripts

8 Operate Running Systems: Boot and Recovery

8.1 Boot, Reboot, and Shut Down a System Normally 8.2 Boot Systems into Different Targets Manually 8.3 Interrupt the Boot Process to Gain Access

9 Operate Running Systems: Processes and Tuning

9.1 Identify and Kill CPU/Memory Intensive Processes 9.2 Adjust Process Scheduling 9.3 Manage Tuning Profiles

10 Operate Running Systems: Logs, Services & File Transfer

10.1 Locate and Interpret System Log Files and Journals 10.2 Preserve System Journals 10.3 Start, Stop, and Check Status of Network Services 10.4 Securely Transfer Files Between Systems

11 Configure Local Storage: Partitions and LVM

11.1 List, Create, and Delete Partitions on GPT Disks 11.2 Create and Remove Physical Volumes 11.3 Assign Physical Volumes to Volume Groups 11.4 Create and Delete Logical Volumes

12 Configure Local Storage: Mounting and Expansion

12.1 Mount File Systems at Boot by UUID or Label 12.2 Add Partitions, Logical Volumes, and Swap Non-Destructively

13 Create and Configure File Systems: Local FS and Permissions

13.1 Create, Mount, and Use VFAT, ext4, and XFS File Systems 13.2 Extend Existing Logical Volumes 13.3 Diagnose and Correct File Permission Problems

14 Create and Configure File Systems: NFS and autofs

14.1 Mount and Unmount Network File Systems Using NFS 14.2 Configure autofs

15 Deploy and Maintain: Scheduling, Services & Targets

15.1 Schedule Tasks with at, cron, and systemd Timers 15.2 Start, Stop, and Enable Services at Boot 15.3 Configure Systems to Boot into a Specific Target

16 Deploy and Maintain: Time, Software Updates & Bootloader

16.1 Configure Time Service Clients 16.2 Install and Update Software from CDN, Remote Repos, and Local Files 16.3 Modify the System Bootloader

17 Manage Basic Networking

17.1 Configure IPv4 and IPv6 Addresses 17.2 Configure Hostname Resolution 17.3 Configure Network Services to Start Automatically at Boot 17.4 Restrict Network Access Using firewalld and firewall-cmd

18 Manage Users and Groups

18.1 Create, Delete, and Modify Local User Accounts 18.2 Change Passwords and Adjust Password Aging 18.3 Create, Delete, and Modify Local Groups and Memberships 18.4 Configure Privileged Access

19 Manage Security: Firewall, umask & SSH Keys

19.1 Configure Firewall Settings with firewall-cmd and firewalld 19.2 Manage Default File Permissions 19.3 Configure Key-Based Authentication for SSH

20 Manage Security: SELinux Modes and Contexts

20.1 Set Enforcing and Permissive Modes for SELinux 20.2 List and Identify SELinux File and Process Contexts 20.3 Restore Default File Contexts

21 Manage Security: SELinux Ports and Booleans

21.1 Manage SELinux Port Labels 21.2 Use Boolean Settings to Modify SELinux Settings

12.1 Mount File Systems at Boot by UUID or Label

Key Takeaways Explain This Topic AI

Prefer UUID= or LABEL= in /etc/fstab so mounts survive disk rename after reboot; avoid raw /dev/sdX names on EX200 when the task allows identifiers.

Discover identifiers with blkid (and lsblk -f); set labels with e2label for ext* and xfs_admin -L for XFS, or tune2fs -L when appropriate.

After editing fstab, validate with mount -a and inspect the live tree with findmnt before you assume the next reboot will succeed.

fstab fields are device, mountpoint, type, options, dump, pass—wrong type, missing directory, or a bad UUID breaks boot until fixed.

Exam credit is the persistent end state: the file system is mounted at the required path after boot (and after mount -a), not a one-time mount command alone.

Last updated: August 2026

12.1 Mount File Systems at Boot by UUID or Label

Quick Answer: Identify a file system with blkid , put UUID=... or LABEL=... in /etc/fstab , create the mountpoint, then prove it with mount -a and findmnt . Do not rely on /dev/sdb1 alone—device letters can change. On EX200, graders care that the mount survives reboot .

Official skill and why it matters

Under Configure local storage , Red Hat expects you to configure systems to mount file systems at boot by universally unique ID (UUID) or label . That skill sits next to creating partitions and LVs: once storage exists and has a file system, you must attach it persistently so applications and users still see the data after reboot.

Typical lab wording:

  • “Mount the XFS file system on the new partition at /data using its UUID; ensure it mounts at boot.”
  • “Label the volume APPDATA and mount it by label at /opt/appdata .”
  • “Configure persistent mount for the LV; use UUID in fstab.”

A successful mount /dev/... /mnt in your shell is not enough if /etc/fstab is missing or wrong. Persistence is the objective.

Why UUID and label beat raw device names

Identifier Example Stability

Kernel name /dev/sdb1 , /dev/nvme0n1p2 Can change when disks are added, order changes, or firmware enumeration differs

  • By-path / by-id under /dev/disk/by-* More stable, longer paths; UUID/label still preferred in fstab teaching
  • UUID UUID=a1b2c3d4-... Stored in the file system superblock; stays with the FS when moved
  • LABEL LABEL=APPDATA Human-readable name you set; must be unique among mounted systems

If /dev/sdb becomes /dev/sdc after hardware change, an fstab line using /dev/sdb1 fails or mounts the wrong disk. UUID and LABEL follow the file system , which is what you care about.

LVM note: Paths like /dev/mapper/vg-lv or /dev/vg/lv are more stable than sdX , but EX200 wording often still wants UUID (or label) in fstab. When the task says “by UUID or label,” obey that literally.

  • Discover identifiers: blkid and friends blkid
  • blkid /dev/sdb1
  • blkid -s UUID -o value /dev/sdb1
  • blkid -s LABEL -o value /dev/sdb1
  • lsblk -f
  • lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
  • findmnt
  • findmnt /data

blkid prints TYPE, UUID, LABEL, PARTUUID (partition table UUID—different from FS UUID). For fstab file-system mounts you want the file system UUID from blkid on the partition, LV, or whole-disk FS device—not PARTUUID unless a task specifically uses PARTUUID= (rare on RHCSA; stick to UUID= for FS). # Useful filters

  • blkid -t TYPE=xfs
  • blkid -t LABEL=APPDATA

lsblk -f is excellent under time pressure: one table for FSTYPE, LABEL, UUID, and current mountpoints.

findmnt shows the live mount table in a tree (or JSON/list). Prefer it over scraping /proc/mounts by hand during verification.

Set or change a label

Labels are optional but convenient when the task requires LABEL= in fstab.

  • ext2/ext3/ext4 e2label /dev/sdb1
  • e2label /dev/sdb1 APPDATA
  • # or
  • tune2fs -L APPDATA /dev/sdb1
  • blkid /dev/sdb1
  • XFS xfs_admin -L APPDATA /dev/sdb1

# clear a label if needed:

  • xfs_admin -L -- /dev/sdb1
  • blkid /dev/sdb1

Rules of thumb:

Keep labels short, unique, and without spaces (use underscores if needed).

For XFS, the device is often best unmounted when changing the label with xfs_admin (follow what the man page and error messages require on the exam host).

After labeling, always re-check with blkid before writing fstab.

You can also set a label at mkfs time ( mkfs.xfs -L , mkfs.ext4 -L ) when you create the FS in a related objective—same end state: LABEL appears in blkid .

  • /etc/fstab anatomy
  • Each non-comment line has six fields : # <file system> <mount point> <type> <options> <dump> <pass>
  • UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 /data xfs defaults 0 0
  • LABEL=APPDATA /opt/appdata ext4 defaults 0 2
  • Field Meaning
  • 1 device UUID=... , LABEL=... , or device path
  • 2 mountpoint Absolute path; directory must exist

3 type xfs , ext4 , vfat , swap , nfs , etc.

  • 4 options defaults , or comma-separated list ( defaults,noatime )
  • 5 dump Legacy dump(8) flag; almost always 0 on modern servers
  • 6 pass fsck order: 0 skip, 1 root, 2 other local FS
  • Common option tokens
  • Option Use
  • defaults rw, suid, dev, exec, auto, nouser, async (classic bundle)
  • auto / noauto Mount at boot / only manual mount
  • ro / rw Read-only / read-write
  • user / nouser Allow non-root mount (special cases)
  • nofail Do not fail boot if this mount fails (useful for optional disks)
  • _netdev Wait for network (network FS; less common for pure local UUID tasks)

For a normal local data disk on EX200, defaults 0 0 or defaults 0 2 is typical. Root’s pass is 1; extra data volumes often use 0 or 2 depending on policy—match the task if it specifies fsck behavior; otherwise 0 0 is a common safe lab choice for non-root data mounts when you are not told to enable fsck.

Writing UUID and LABEL correctly # Wrong — missing UUID= prefix, bare hex is not enough in modern fstab style teaching

# a1b2c3d4-... /data xfs defaults 0 0

  • # Right
  • UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 /data xfs defaults 0 0
  • LABEL=APPDATA /data xfs defaults 0 0

No quotes around the UUID in standard fstab. Copy-paste carefully from blkid ; a single wrong character fails the mount.

  • Mountpoint and SELinux awareness sudo mkdir -p /data
  • sudo mkdir -p /opt/appdata

The directory must exist before mount or mount -a . Empty mountpoint is fine; if the directory already has files, those files are hidden while the FS is mounted over them—usually unintentional.

SELinux: new data mounts may need context restore or mount options like context= only when a task demands it (covered more under security/file-system chapters). For pure “mount by UUID” objectives, correct fstab + mount is the focus; if services cannot write, check contexts later without abandoning UUID persistence.

  • Validate without rebooting first # Syntax/apply all fstab mounts that are not yet mounted
  • sudo mount -a

echo $?

# 0 is good; non-zero means read the error

  • findmnt /data
  • findmnt -s # fstab view via findmnt (when supported)
  • findmnt UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890
  • mount | grep /data
  • ls /data

mount -a is your primary pre-reboot check. If it errors, fix fstab before reboot —a bad fstab can drop you into emergency mode on real systems. On the exam, still treat mount -a as mandatory verification.

  • Manual one-shot mount (testing only): sudo mount UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 /data
  • sudo mount LABEL=APPDATA /data
  • sudo umount /data

After fstab is correct, prefer mount /data (uses fstab) or mount -a .

  • End-to-end exam workflows
  • Workflow A — Mount by UUID at /data
  • Task: Persistently mount the XFS file system on /dev/sdb1 at /data using UUID. lsblk -f
  • blkid /dev/sdb1
  • # UUID="...." TYPE="xfs"
  • sudo mkdir -p /data

# Edit /etc/fstab (vim/nano) — add:

  • # UUID=.... /data xfs defaults 0 0
  • sudo mount -a
  • findmnt /data
  • # Practice labs: reboot and re-check findmnt /data
  • Workflow B — Mount by label
  • Task: Label the ext4 FS BACKUP and mount by label at /backup . sudo e2label /dev/sdc1 BACKUP
  • blkid /dev/sdc1
  • sudo mkdir -p /backup
  • # LABEL=BACKUP /backup ext4 defaults 0 0
  • sudo mount -a
  • findmnt /backup
  • Workflow C — LV with UUID blkid /dev/mapper/vgdata-lvapp
  • sudo mkdir -p /srv/app
  • # UUID=... /srv/app xfs defaults 0 0
  • sudo mount -a
  • findmnt /srv/app
  • Workflow D — Fix a broken fstab line sudo mount -a

# mount: /data: can't find UUID=...

  • blkid # get the real UUID
  • sudo vim /etc/fstab # correct the line
  • sudo mount -a
  • findmnt /data
  • dump and pass (exam hygiene)

dump field: Keep 0 unless told otherwise; dump is rarely used on RHEL servers.

pass field: Root FS often 1 ; other local filesystems 2 if you want ordered fsck; 0 disables fsck at boot for that line. Wrong extra fields (only four columns) break parsing—always six fields.

  • swap lines (preview for 12.2)
  • Swap also uses fstab with type swap and mountpoint none (or swap ): UUID=... none swap defaults 0 0

Activation details ( mkswap , swapon ) are in the next section; the UUID principle is the same.

Common traps

Using /dev/sdb1 when the task required UUID/label — works until rename; may lose points if the grader checks fstab content.

Typo in UUID — mount -a fails; re-copy from blkid .

Missing mountpoint directory — create with mkdir -p .

Wrong TYPE — xfs vs ext4 must match blkid TYPE.

Duplicate LABEL — two file systems with the same label make LABEL= ambiguous.

Forgetting mount -a and only testing a manual mount — reboot then fails.

Mounting over a non-empty directory without noticing hidden files.

Confusing PARTUUID with UUID — use FS UUID from blkid on the FS device.

Spaces or quotes mangling the fstab line.

noauto left on when the task expects boot-time mount — remove noauto so auto behavior applies.

Relationship to other storage objectives

  • Skill Where
  • Create GPT partitions / PVs / VGs / LVs Prior storage chapter
  • mkfs, unmount, VFAT/ext4/XFS use File systems chapter
  • Persistent mount by UUID/label This section
  • Add storage/swap non-destructively Section 12.2
  • Extend existing LVs Later file-systems objective

Order on the exam is often: create storage → mkfs → fstab UUID → verify.

Section checkpoint

You should run blkid / lsblk -f , set labels with e2label or xfs_admin -L when required, write six-field /etc/fstab lines using UUID= or LABEL= , ensure the mountpoint exists, validate with mount -a and findmnt , and treat reboot survival as the real success criterion. That is the EX200 standard for mounting file systems at boot by UUID or label.