Mount Linux Filesystems with UUID and Labels

A mount /dev/sdb1 /data command lasts until reboot. To keep /data after every boot, you register the filesystem in /etc/fstab with a stable identifier—usually UUID=—so the mount survives when the kernel reorders disks. The walkthrough below uses a spare data disk on the lab host; if you still need partitioning or mkfs, start with create and mount filesystems first.

How Persistent Filesystem Mounting Works

Linux separates three ideas beginners often conflate:

A temporary mount runs mount once. The kernel attaches the filesystem until you umount or reboot. A persistent mount adds a line to /etc/fstab so boot tools and mount -a know which source, type, and options to apply at /data every time.

Device paths like /dev/sdb1 are not stable identifiers. BIOS order, new disks, or USB insertions can shift names so yesterday's /dev/sdb1 becomes /dev/sdc1. UUID and LABEL identify the filesystem (or swap area) itself, which is why Anaconda writes UUID lines on RHEL installs.

On the lab host, Anaconda already registered root, boot, and swap by UUID:

head -15 /etc/fstab

Sample output:

#
# /etc/fstab
# Created by anaconda on Mon Aug  3 05:57:29 2026
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=96b3becc-49da-4746-89b4-6b44cc1daf47 /                       xfs     defaults        0 0
UUID=cbd838ad-a342-4b56-b65f-da022e195971 /boot                   xfs     defaults        0 0
UUID=78531da6-a389-46e8-9bad-267572940826 none                    swap    defaults        0 0

Those comments remind you that stable symlinks live under /dev/disk/ and that systemd reads the same file.

/etc/fstab Quick Reference

Keep this table nearby while you edit. Field meanings are expanded in the next section.

Example line shapes:

UUID=<uuid>  /data   xfs   defaults  0  0
LABEL=backup /backup ext4  defaults  0  2

Understand the Six /etc/fstab Fields

Each non-comment line has six fields separated by whitespace or tabs:

<identifier>  <mount point>  <type>  <options>  <dump>  <fsck>

1. Device or filesystem identifier — UUID=…, LABEL=…, /dev/mapper/…, or a device path. Prefer UUID for local data disks.
2. Mount point — Directory path where the filesystem attaches (or none for swap). Existing files in the directory are hidden while another filesystem is mounted on that path.
3. Filesystem type — xfs, ext4, swap, vfat, and so on. Use auto only when you understand the risk.
4. Mount options — Comma-separated flags such as defaults or rw,noatime.
5. dump — 0 skips the legacy dump backup tool; 1 includes the filesystem. Almost always 0 today.
6. fsck order — 0 skips boot-time fsck for this filesystem. 1 is traditionally the root filesystem on ext4. 2 checks other ext4 filesystems after root. On RHEL, XFS fstab lines use 0 in this column—fsck.xfs is only a compatibility stub and XFS does not perform a traditional boot-time fsck. The lab's XFS root, boot, and data examples all use 0 0.

Device Name vs UUID vs LABEL

PARTUUID identifies the partition slot, not the filesystem inside it. After reformatting the partition, the PARTUUID may stay while the filesystem UUID changes.

Stable symlinks on the lab host map UUIDs to block devices:

ls -la /dev/disk/by-uuid/ | head -6

Sample output:

total 0
drwxr-xr-x. 2 root root 100 Aug  8 15:08 .
drwxr-xr-x. 7 root root 140 Aug  8 15:08 ..
lrwxrwxrwx. 1 root root  10 Aug  8 15:08 78531da6-a389-46e8-9bad-267572940826 -> ../../dm-1
lrwxrwxrwx. 1 root root  10 Aug  8 15:08 96b3becc-49da-4746-89b4-6b44cc1daf47 -> ../../dm-0
lrwxrwxrwx. 1 root root  10 Aug  8 15:08 cbd838ad-a342-4b56-b65f-da022e195971 -> ../../sda2

Before any labeled filesystem existed, /dev/disk/by-label/ was absent on this VM—labels appear only after you set them on a formatted filesystem.

Find a Filesystem UUID

List friendly columns for every block device:

lsblk -f

Sample output (lab host, trimmed):

NAME          FSTYPE      FSVER    LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda2        xfs                        cbd838ad-a342-4b56-b65f-da022e195971      1.4G    26% /boot
└─sda3        LVM2_member LVM2 001       kK0T8E-lrVU-PAkS-fdwT-wIlJ-S32a-VaNd7X
  ├─rhel-root xfs                        96b3becc-49da-4746-89b4-6b44cc1daf47     15.8G    37% /
  └─rhel-swap swap        1              78531da6-a389-46e8-9bad-267572940826                  [SWAP]
sdb

Read FSTYPE for the filesystem type, LABEL when set, UUID for fstab, and MOUNTPOINTS for where it is already attached.

For one partition, blkid prints the exact strings you paste into fstab:

blkid /dev/sda2

Sample output:

/dev/sda2: UUID="cbd838ad-a342-4b56-b65f-da022e195971" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="148448c7-94ed-4278-b445-c84cc78e4a22"

That UUID matches the /boot line in /etc/fstab and the findmnt source below.

Assign and Use Filesystem Labels

Labels are optional human-readable names stored in the filesystem superblock. They must be unique among filesystems on the same machine if you mount by LABEL=.

Brief tool reference:

On the lab data disk the XFS label was set during formatting with mkfs.xfs -L labdata. To read it later:

xfs_admin -l /dev/sdb1

Sample output:

label = "labdata"

Duplicate labels make LABEL= mounts ambiguous—always verify with blkid after changes.

Mount a Filesystem Temporarily by UUID

Before you edit fstab, confirm the UUID mounts cleanly. Create the mount point if it does not exist:

mkdir -p /data

Mount by UUID (use the value from blkid):

mount UUID=276aa1ee-3141-49fc-a2d3-8b631bbc281a /data

mount prints nothing on success. Confirm the attachment:

findmnt /data

Sample output:

TARGET SOURCE    FSTYPE OPTIONS
/data  /dev/sdb1 xfs    rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota

The source shows /dev/sdb1 even though you passed UUID—findmnt resolves the device node.

Create a Persistent Mount with UUID

This is the central workflow. The lab used /dev/sdb1 with XFS and label labdata on a spare 10 GiB disk—filesystem creation is out of scope here; see create and mount filesystems if you still need that step.

Capture the UUID you will paste into fstab:

blkid /dev/sdb1

Sample output:

/dev/sdb1: LABEL="labdata" UUID="276aa1ee-3141-49fc-a2d3-8b631bbc281a" BLOCK_SIZE="512" TYPE="xfs" PARTLABEL="primary" PARTUUID="7bbbdf4f-1690-4167-b852-f866a80a2ce5"

Back up fstab before every edit:

cp -a /etc/fstab /etc/fstab.bak

Add one line (tabs or spaces between fields):

UUID=276aa1ee-3141-49fc-a2d3-8b631bbc281a /data xfs defaults 0 0

Run systemctl daemon-reload so systemd regenerates .mount units from the edited fstab. That step updates generated unit definitions for the running manager—it does not perform the mount test.

mount -a is independent: the mount utility reads /etc/fstab itself and tries to attach every entry that is not already mounted. Run both after a normal fstab edit; they answer different questions (unit regeneration versus whether the lines actually mount).

systemctl daemon-reload

If /data was mounted manually during testing, unmount so mount -a exercises the fstab line:

umount /data

Apply every fstab entry that is not already mounted:

mount -a

mount -a exits silently when all entries succeed. Verify:

findmnt /data

Sample output:

TARGET SOURCE    FSTYPE OPTIONS
/data  /dev/sdb1 xfs    rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota

Run the fstab verifier:

findmnt --verify

Sample output:

Success, no errors or warnings detected

On a maintenance host, reboot once and run findmnt /data again to confirm the mount returns without manual mount. The shared lab skipped reboot to avoid disrupting other work; mount -a plus findmnt --verify is the minimum gate before you reboot production systems.

Create a Persistent Mount with LABEL

Replace only the first fstab field when the label is unique:

LABEL=labdata /data xfs defaults 0 0

Advantages: readable in findmnt and logs. Limitations: labels are user-assigned and can collide; UUIDs are globally unique by design. Many teams use UUID in fstab and labels only for operator notes.

Test LABEL mounts without fstab first:

umount /data

Mount by label to confirm the name resolves to the intended filesystem:

mount LABEL=labdata /data

Confirm:

findmnt /data

Sample output:

TARGET SOURCE    FSTYPE OPTIONS
/data  /dev/sdb1 xfs    rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota

After you trust the label, swap the fstab identifier field, run systemctl daemon-reload and mount -a on a booted system, then findmnt --verify.

Understand Common Mount Options

The fourth fstab field is a comma-separated list. defaults on RHEL is typically rw,suid,dev,exec,auto,nouser,async.

This article is not a hardening guide—pick options that match how the data is used. nofail is common for non-critical volumes so a missing USB disk does not drop the system into emergency mode.

Mount Only One /etc/fstab Entry

When the line exists in fstab, mount can take only the mount point:

umount /data

Pass only the mount point so fstab supplies the UUID, filesystem type, and options:

mount /data

Confirm the entry mounted from fstab:

findmnt /data

Sample output:

TARGET SOURCE    FSTYPE OPTIONS
/data  /dev/sdb1 xfs    rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota

The same pattern works for /boot on the lab system—fstab already maps UUID to mount point:

findmnt /boot

Sample output:

TARGET SOURCE    FSTYPE OPTIONS
/boot  /dev/sda2 xfs    rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota

Verify /etc/fstab Before Rebooting

Editing fstab and rebooting immediately is how administrators learn emergency mode. Validate first on a normally booted system:

1. systemctl daemon-reload — regenerate systemd .mount units from the saved fstab
2. mount -a — let the mount utility read fstab and surface UUID, type, or option errors
3. findmnt on each new mount point
4. findmnt --verify when available

daemon-reload does not mount filesystems; mount -a does not refresh systemd units. Both are worth running before reboot because they test different layers.

Skipping mount -a means the first boot attempt becomes the test. A wrong UUID or missing mount point can stall boot until you fix fstab from rescue or rd.break.

Change an Existing /etc/fstab Entry

Common edits and what they require:

LVM logical volumes keep the same /dev/mapper/rhel-root path and UUID when you extend the LV—see extend an LVM partition for growth without fstab changes.

Troubleshoot /etc/fstab Errors

Recover from a Bad /etc/fstab Entry

When boot hangs after an fstab edit, you need console access—not SSH.

1. Interrupt GRUB and boot with rd.break or select recovery media if the system does not reach login—see reset root password on RHEL for the GRUB edit pattern and systemd targets for rescue versus emergency semantics.
2. In rd.break: mount -o remount,rw /sysroot, then chroot /sysroot.
3. Comment the bad fstab line with # or fix the UUID, mount point, and type.
4. Inside the chroot, run mount -a to test the corrected file. Do not rely on systemctl daemon-reload here—you are not in the normally booted systemd environment.
5. Exit the chroot and initramfs shell, then reboot so the installed system boots with the fixed fstab.
6. After a normal boot, run systemctl daemon-reload and findmnt --verify, then confirm mounts with findmnt.

Keep a known-good fstab.bak on the system or in your change ticket so recovery is a copy operation under pressure.

UUID and Label Examples

Network filesystems and autofs use different configuration files—see NFS client setup and autofs guides when the mount is not a local block device. Temporary ISO, USB, and network mounts belong in Linux mount command rather than duplicated here.

References

• fstab(5) — static filesystem information
• mount(8) — mount a filesystem
• findmnt(8) — find a mount point
• blkid(8) — locate block device attributes
• Red Hat Enterprise Linux 10 — Managing file systems

Summary

Persistent mounts on Linux live in /etc/fstab, not in your shell history. A temporary mount /dev/sdb1 /data disappears at reboot; a UUID line tells the boot stack which filesystem to attach at /data every time. UUID is the usual choice for local disks because it follows the formatted filesystem when kernel device names shuffle.

The safe edit path on a running system is backup, add the line, systemctl daemon-reload (regenerate systemd mount units), mount -a (test fstab through the mount utility), findmnt, and findmnt --verify—then reboot when you have a maintenance window. LABEL mounts work the same way when labels are unique, but duplicate labels break mount in ways UUIDs avoid.

When mount -a fails or boot lands in emergency mode, fix or comment the offending line from console access before you reboot again. Partitioning and mkfs belong in create and mount filesystems; NFS, autofs, and one-off mount targets belong in their dedicated guides—not mixed into every fstab lesson.