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.