Module 4: File Systems

RHCSA domain covered: Create and Configure File Systems (5).

Labs in this kit: Lab 05 (LVM-based file systems), Lab 06 (Stratis).

A *file system* is the on-disk structure that turns a raw block device into something that stores named files and directories. Partitioning and LVM (Module 3) give you a block device to work with; this module is about putting a usable file system on that device, mounting it where you need it, and — the part the exam actually scores — making the mount survive a reboot. Almost every storage task on the RHCSA ends with a reboot and a re-check, so "it worked once" is never enough; it has to be persistent.

File systems you must know

Why XFS is the default. Red Hat ships XFS as the default for RHEL because it scales cleanly to very large volumes and high parallel I/O, and it can be grown online while mounted. The one catch worth memorizing: XFS cannot be shrunk. If a task ever asks you to *reduce* a file system, that's your signal it's ext4 (or that you need to back up, recreate smaller, and restore). On the exam, picking the wrong filesystem early can make a later "shrink it" step impossible — so read the whole question before you mkfs.

Creating and mounting a file system — the core workflow

What you're doing: taking a block device (a partition like /dev/sdb1, or an LVM logical volume like /dev/vg01/lv01), writing a file system onto it, and attaching it to a directory in your tree so you can read and write files there.

Why it matters: this five-step pattern is the backbone of every storage task on the exam. Learn it as a single muscle-memory sequence and you can adapt it to LVM, Stratis, or a plain partition.

# 1. Put a filesystem on the device
mkfs.xfs /dev/vg01/lv01

# 2. Make a place to attach it
mkdir -p /srv/app

# 3. Get the UUID (stable identifier — never use /dev names in fstab)
blkid /dev/vg01/lv01

# 4. Add a persistent entry to /etc/fstab
echo "UUID=<uuid-from-step-3>  /srv/app  xfs  defaults  0 0" >> /etc/fstab

# 5. Test WITHOUT rebooting, then verify
mount -a          # mounts everything in fstab that isn't already mounted
findmnt /srv/app  # confirms it mounted with the options you intended

Step 3 matters more than it looks. Device names like /dev/sdb are assigned in the order the kernel discovers disks, so they can change between boots — add a second disk and yesterday's /dev/sdb might be today's /dev/sdc, and an fstab full of /dev/sd* names will mount the wrong volumes or fail. A UUID is written into the file system itself and never changes, which is why every persistent mount on the exam should use one.

Step 5 is the habit that saves you. Running mount -a after editing fstab re-reads the file and mounts anything new. If you made a typo, it fails *now*, at a shell prompt where you can fix it — instead of at next boot, where a bad fstab line drops the whole machine into emergency mode.

Persistent mounts and fstab options

What it is: /etc/fstab is the table systemd reads at boot to decide what to mount, where, and how. Each line is: *what* (UUID), *where* (mount point), *type* (xfs/ext4/nfs…), *options*, and two legacy numeric fields (dump and fsck order — almost always 0 0).

Why it matters: the options field is where you control real behavior, and the exam loves to test the ones that prevent a hung or unbootable system:

The single most common way to make a RHEL box unbootable on the exam is a bad fstab line — a wrong UUID, a missing _netdev on a network mount, or a Stratis volume without its x-systemd.requires. That's why mount -a after every edit is non-negotiable.

NFS client — mounting from the network

What it is: NFS lets a machine mount a directory that physically lives on another server, as if it were a local folder. On the RHCSA you're the *client* (mounting a share someone else exports), not the server.

Why it matters: network mounts have a timing problem — if the system tries to mount before the network is up, the boot hangs or fails. The options below exist specifically to solve that.

# Manual mount (test it works before making it persistent)
mount -t nfs server.lan:/data /mnt/data

# Persistent (in /etc/fstab)
server.lan:/data  /mnt/data  nfs  defaults,_netdev,nofail  0 0

_netdev tells systemd "this mount needs the network — wait for it." nofail adds a safety net: if the NFS server is unreachable at boot, the machine still comes up instead of hanging. Together they're the difference between a robust network mount and a box that won't boot when the file server is down.

Stratis — the modern pool/snapshot stack

What it is: Stratis is Red Hat's answer to ZFS/btrfs-style storage. Instead of "partition → filesystem," you create a pool from one or more disks, then carve file systems out of the pool. The pool is thin-provisioned (file systems grow as data is written) and supports cheap snapshots. Under the hood it's XFS on top of device-mapper, managed by the stratisd daemon.

Why it matters: it's explicitly on the RHEL 9 objectives, and it behaves differently enough from LVM that the exam can test whether you actually understand it — especially the boot-ordering gotcha below.

# One-time setup: install and start the daemon
dnf install -y stratisd stratis-cli
systemctl enable --now stratisd

# Build the stack
stratis pool create pool_lab /dev/sdb        # create a pool from a disk
stratis pool add-data pool_lab /dev/sdc      # grow the pool with another disk
stratis filesystem create pool_lab fs_app    # carve a filesystem out of the pool
stratis filesystem create pool_lab fs_data

# Mount persistently — use UUID AND require stratisd
UUID=$(blkid -s UUID -o value /dev/stratis/pool_lab/fs_app)
echo "UUID=$UUID /srv/app xfs defaults,x-systemd.requires=stratisd.service 0 0" >> /etc/fstab
mount -a

That last fstab option, x-systemd.requires=stratisd.service, is the whole exam trap in one string. A Stratis volume only exists once stratisd is running. If fstab tries to mount it during early boot — before stratisd starts — the mount fails and the system drops to emergency mode. The option forces systemd to start stratisd *first*. Leave it out and the machine works fine until the next reboot, then won't come up. (Note the filesystem *type* in fstab is xfs, not stratis, because XFS is what's actually on the volume.)

Snapshots (Stratis)

What it is: a snapshot is a point-in-time copy of a file system that costs almost nothing to create because it only stores what changes afterward (copy-on-write).

Why it matters: it's how you take a safe checkpoint before a risky change, or grab a consistent copy of data for backup, without unmounting or copying everything.

stratis filesystem snapshot pool_lab fs_app fs_app_snap1

# Mount the snapshot read-only to inspect or restore from it
mkdir /mnt/snap1
mount -o ro /dev/stratis/pool_lab/fs_app_snap1 /mnt/snap1

Set-GID directories (group-shared folders)

What it is: a directory with the *set-GID* bit set forces every new file created inside it to inherit the directory's group instead of the creator's primary group.

Why it matters: it's the standard pattern for a shared team folder — everyone in the engineering group should be able to work on files regardless of who created them. Without SGID, each person's files get their own primary group and the sharing breaks.

mkdir /srv/team
chown root:engineering /srv/team
chmod 2770 /srv/team        # the leading 2 is the SGID bit

# SGID handles the GROUP. For inheritable PERMISSIONS, add a default ACL:
setfacl -d -m g:engineering:rwx /srv/team

The chmod 2770 breaks down as: 2 = SGID, then 770 = owner and group get full access, everyone else gets nothing. SGID makes new files land in the right group; the *default ACL* (-d) makes them land with the right permissions too. You usually want both for a working shared directory — that's why this shows up in Module 2 (permissions) as well.

Repairing a file system

What it is: tools that check and fix file system metadata corruption (after an unclean shutdown, bad disk, etc.).

Why it matters: the exam may hand you a damaged volume, and the right tool depends on the file system — using the wrong one does nothing.

xfs_repair /dev/sdb1         # XFS — the device MUST be unmounted first
fsck.ext4 -y /dev/sdb1       # ext4 — the -y answers "yes" to all repairs

Note that fsck.xfs exists but is a do-nothing stub — XFS is repaired only with xfs_repair, and only while the volume is unmounted. Running a repair on a mounted file system either refuses or causes more damage, so unmount first.

Common pitfalls

• Mounting a Stratis filesystem without x-systemd.requires=stratisd.service → boot drops to emergency mode on the next reboot.
• Using /dev/sdX names in fstab instead of UUIDs → mounts break when disk ordering changes.
• Forgetting _netdev on NFS mounts → boot hangs waiting for a mount the network isn't ready for.
• Editing fstab and *not* running mount -a → the error surfaces at next boot instead of now, when it's easy to fix.
• Trying to xfs_growfs separately when extending an LVM volume → use lvextend -r to resize the LV and the filesystem in one safe step.
• Forgetting mkfs.xfs -f to overwrite an existing filesystem → without -f it refuses to clobber existing data.
• Expecting to shrink XFS → it can't be done; that's an ext4-only operation.

Exam tips

• After every storage change, reboot and re-verify with findmnt and df -h. The exam scores the state after a reboot, not the commands you typed.
• Build fstab UUID lines safely: blkid -s UUID -o value /dev/... prints just the bare UUID you can paste, with no quotes or extra text to mistype.
• If a box won't boot after an fstab edit, you'll land in emergency mode. Mount root read-write with mount -o remount,rw /, fix the offending fstab line, and reboot. Knowing this recovery is worth easy points.
• When a task says "shrink" or "reduce," reach for ext4, not XFS.
• mount -a is your proof-of-correctness command — run it after every fstab edit, before you move on.

Next: Module 5 — Deploying, configuring, and maintaining systems.