Red Hat Certified System Administrator (RHCSA) #7 File systems: XFS, ext4, mount/fstab, NFS, AutoFS

Infrastructure Linux RHEL Red Hat Certification

Thursday, May 28, 2026

10 min read

If #5 and #6 had you building and growing block devices with partitions and LVM, this post is about putting a file system on top of them and mounting it. RHCSA doesn’t stop at creating an empty block device. Making XFS or ext4 on it, mounting it on a directory, and registering it permanently in fstab so it reattaches in the same place after a reboot — all of that is a single task.

On top of that, we’ll cover two RHCSA regulars: NFS client mounts and AutoFS on-demand mounts. Both share the idea of “attaching external storage to my system,” but NFS stays mounted all the time via fstab, while AutoFS attaches automatically only when accessed and detaches afterward.

Creating a file system #

To store data on a block device (a partition or an LV), you first have to create a file system. RHEL 9’s default file system is XFS, and ext4 is supported alongside it.

XFS: mkfs.xfs #

XFS is RHEL’s default file system and is strong with large capacity and parallel I/O. The command to make XFS on the LV /dev/vg01/lv01 is as follows.

sudo mkfs.xfs /dev/vg01/lv01

If you try to recreate one on a device that already has a file system, it’s refused. To really overwrite it, add -f (force).

sudo mkfs.xfs -f /dev/vg01/lv01

ext4: mkfs.ext4 #

If a task calls for ext4, use mkfs.ext4.

sudo mkfs.ext4 /dev/vg01/lv02

You can do the same thing in the mkfs -t xfs or mkfs -t ext4 form. On the exam, either one is fine as long as the result is correct.

sudo mkfs -t xfs /dev/vg01/lv01
sudo mkfs -t ext4 /dev/vg01/lv02

Checking the created file system #

lsblk -f shows each device’s file system type, UUID, and LABEL at a glance. It’s the starting command for mount and fstab work.

lsblk -f

NAME            FSTYPE      FSVER  LABEL  UUID                                 MOUNTPOINTS
vda
├─vda1          xfs                       a1b2c3d4-...                         /boot
└─vda2          LVM2_member        ...
  └─...
vg01-lv01       xfs                       1f2e3d4c-5b6a-7980-1234-567890abcdef
vg01-lv02       ext4        1.0           9876fedc-ba98-7654-3210-abcdef012345

You can also check the UUID and type with blkid.

sudo blkid /dev/vg01/lv01

Mounting and unmounting #

Once you’ve made a file system, you have to attach it (mount it) on a directory before you can actually use it.

Mounting on a directory: mount #

First make the directory that will be the mount point, then attach the device on top of it.

sudo mkdir -p /data
sudo mount /dev/vg01/lv01 /data

Unmounting: umount #

To detach a mount, give umount either the device or the mount point.

sudo umount /data

If you get a “target is busy” error, it’s because you’re inside that directory or some process has a file in it open. Use lsof or fuser to check who’s using it.

sudo lsof /data
sudo fuser -vm /data

Checking mount status: findmnt #

findmnt shows the current mount tree cleanly. To see only a specific point, pass it as an argument.

findmnt
findmnt /data

You can also see the mount situation by running mount with no arguments or using df -h, but findmnt lays out the options clearly too, which is good for verification.

df -h /data

The mount up to this point is a temporary mount that lives only in memory. It disappears on reboot. To avoid losing points on RHCSA, you must go all the way to the next step — permanent registration in fstab.

Persistent mounts with fstab #

Registering one line in /etc/fstab mounts it automatically on every boot. fstab is made up of six whitespace-separated columns.

<device>  <mount point>  <type>  <options>  <dump>  <fsck order>

Column	Meaning
device	One of UUID, LABEL, or a device path. UUID is recommended
mount point	The directory to attach it to
type	xfs, ext4, nfs, etc.
options	Mount options such as `defaults` or `nofail`
dump	Backup marker. Usually 0
fsck order	Check order at boot. Root is 1, the rest are 0 or 2

Why use a UUID instead of a device path #

A device path like /dev/sdb1 can change as disks are added or removed. A UUID is fixed to the file system and doesn’t change, so it’s safer to use a UUID in fstab. Check the UUID with lsblk -f or blkid.

sudo blkid /dev/vg01/lv01

/dev/vg01/lv01: UUID="1f2e3d4c-5b6a-7980-1234-567890abcdef" TYPE="xfs"

Add a line to fstab with the UUID you found.

UUID=1f2e3d4c-5b6a-7980-1234-567890abcdef  /data  xfs  defaults  0 0

When the name is stable, as with an LV, it’s fine to use the device-mapper path directly.

/dev/vg01/lv01  /data  xfs  defaults  0 0

Registering by LABEL #

If you put a label on a file system, you can reference it in fstab with LABEL=. Set the label with xfs_admin -L for XFS and e2label for ext4.

sudo xfs_admin -L data /dev/vg01/lv01
sudo e2label /dev/vg01/lv02 logs

LABEL=data  /data  xfs   defaults  0 0
LABEL=logs  /logs  ext4  defaults  0 0

Verifying with mount -a #

After editing fstab, you must verify it before rebooting. mount -a mounts every entry in fstab that isn’t already mounted. If it finishes without errors and the mount shows up in findmnt, you’ve succeeded.

sudo mount -a
findmnt /data

If you get an error, there’s a typo on that line of fstab, or the device or options are wrong. Catching it right here is what prevents a boot failure.

What the defaults option means #

defaults is a standard option set bundling rw,suid,dev,exec,auto,nouser,async. For most ordinary mounts, defaults alone is enough. If you need to, append extra options with commas.

LABEL=data  /data  xfs  defaults,noexec  0 0

nofail: don’t block boot even if the device is absent #

If a device registered in fstab is absent at boot time, the default behavior is to halt boot and drop into emergency mode. For devices that aren’t guaranteed to be present at boot, such as NFS or USB, add nofail so the system quietly skips them when they are absent.

LABEL=backup  /backup  xfs  defaults,nofail  0 0

nofail is a safeguard meaning “even if this mount fails, the system boot continues.” It’s good to attach it to external-storage entries.

NFS client mounts #

NFS mounts a remote directory onto your system so you can use it like a local directory. RHCSA mostly asks about the client-side mount — not server configuration, but the task of attaching a given NFS server’s share to your system.

The client package #

The NFS client tools are provided by the nfs-utils package. It’s usually installed by default, but install it if it’s missing.

sudo dnf install -y nfs-utils

Checking shares with showmount #

Check which directories the server exports with showmount -e.

showmount -e nfs.example.com

Export list for nfs.example.com:
/exports/shared  *
/exports/home    192.168.0.0/24

Temporary mount #

Make the mount point and attach it with mount -t nfs.

sudo mkdir -p /mnt/shared
sudo mount -t nfs nfs.example.com:/exports/shared /mnt/shared

Check the result with findmnt.

findmnt /mnt/shared

Persistent mount with fstab #

NFS can also be registered in fstab to mount automatically at boot. The type is nfs, and you put server:path in the device column. Because the mount can fail due to network or server conditions, it’s safer to add nofail as well.

nfs.example.com:/exports/shared  /mnt/shared  nfs  defaults,_netdev,nofail  0 0

The _netdev option marks “attempt this mount after the network is up.” Attach it to mounts that depend on the network, like NFS. After registering, verify with mount -a.

sudo mount -a
findmnt /mnt/shared

AutoFS on-demand mounts #

An fstab mount stays attached at all times from boot. AutoFS, by contrast, mounts automatically the moment you access that directory, and detaches again after a period of disuse. Use it where mounting only on demand is advantageous, such as an environment that serves user home directories over NFS.

Installing and enabling autofs #

sudo dnf install -y autofs
sudo systemctl enable --now autofs

The master map: /etc/auto.master #

AutoFS configuration is made up of two stages: the master map and the map file. The master map (/etc/auto.master, or a file under /etc/auto.master.d/) defines “which directory is managed by which map file.”

Create the file /etc/auto.master.d/shared.autofs and put this one line in it.

/shares  /etc/auto.shared

This line means “mounts under /shares are managed by the /etc/auto.shared map file.”

The map file: /etc/auto.shared #

The map file defines “the mount point name, options, and source.” Put this in /etc/auto.shared.

data  -rw,sync  nfs.example.com:/exports/shared

With this in place, the moment you access /shares/data, AutoFS mounts nfs.example.com:/exports/shared in that spot. You don’t need to create the /shares directory yourself. AutoFS manages it.

To reread the configuration, restart autofs.

sudo systemctl restart autofs

Verifying the behavior #

The key behavior of AutoFS is that no mount is visible before access — the moment you enter the directory it gets mounted.

ls /shares/data
findmnt /shares/data

Auto-mounting home directories #

The signature RHCSA scenario is auto-mounting NFS home directories with AutoFS. For example, if the server exports each user’s home in the form /exports/home/username, you handle it in one line with a wildcard map.

Put this in the master map /etc/auto.master.d/home.autofs.

/home/guests  /etc/auto.home

In the map file /etc/auto.home, use the wildcard * and the substitution variable &.

*  -rw,sync  nfs.example.com:/exports/home/&

* matches the name of the subdirectory being accessed, and & is substituted with that name. When the user jdoe accesses /home/guests/jdoe, AutoFS mounts nfs.example.com:/exports/home/jdoe in that spot.

sudo systemctl restart autofs
ls /home/guests/jdoe
findmnt /home/guests/jdoe

This pattern shows up often on the exam as “auto-mount user X’s home from an NFS server.” Get the structure — one line in the master map and one line in the wildcard map file — into your hands.

Exam points #

A typo in fstab leads to a boot failure. One wrong line can drop you into emergency mode on the next boot. After editing fstab, always verify with sudo mount -a before rebooting and confirm there are no errors.
Register local mounts by UUID or LABEL, and NFS by server:path. Device paths can change, so prefer the UUID.
Attach nofail (and _netdev for NFS) to external and network mounts, so boot doesn’t halt when the device or server is absent.
AutoFS is two stages: master map + map file. The master map links a directory to a map file, and the map file defines the mount options and source. After editing the configuration, apply it with systemctl restart autofs.
When you’re stuck on the man pages, the example files in /usr/share/doc/autofs (auto.master, auto.misc) are a big help.

Wrap-up #

What this post locked in:

Creating file systems. mkfs.xfs (the default) and mkfs.ext4, plus checking type and UUID with lsblk -f and blkid
Mounting and unmounting. Attach with mount, detach with umount, and verify status with findmnt. This mount is temporary
Persistent mounts with fstab. Register by UUID or LABEL, make use of the defaults and nofail options, and verify before reboot with mount -a
NFS client. Check shares with showmount -e, temporarily mount with mount -t nfs, and register permanently in fstab with nfs, _netdev, and nofail
AutoFS. Configure on-demand mounts with a master map and a map file, and auto-mount NFS home directories with a wildcard map

Next — Packages and repositories #

We’ve wrapped up the storage and file system area from #5 to here. Now we move into the area of getting software onto the system.

In #8 Packages and repositories: dnf, modules, AppStream, we’ll install, search for, and remove packages with dnf, register local and remote repositories, and handle multiple versions of the same software with RHEL 9’s AppStream and module streams, all typed out by hand.