← RHCSA: RHEL 10 production administration
10 / 10 · 60 MIN

Mounts, startup, and support handover

Connect persistent configuration, service dependencies, and post-reboot evidence to prevent writes to the wrong source.

A directory does not prove a mount

/srv/ledger can exist on root even when its data volume is absent. findmnt -T /srv/ledger looks for the filesystem containing the path; it can return TARGET=/ and succeed. To ask about the exact mount, use -M and check expected source, type, and options. Also record context: the observation belongs to the queried namespace. An isolated service may have another view requiring its own check. A write test as root in the wrong directory does not demonstrate data availability. Compare results against an explicit contract: this path, this source, this identity, and this behavior.

Make the reference persistent and unambiguous

fstab describes persistent mounts, including source, target, type, and options. Obtain identity from the observed filesystem and relate it to approved inventory; do not copy a UUID from an example. Cloning can duplicate UUIDs, so the word “unique” does not remove the need to inspect copies attached to the system. A /dev/sdX name can also change with enumeration. After reviewing the entry, daemon-reload updates configuration used by the manager. Record the file version and change made. Reloading units does not mean the new mount occurred or that expected data is present.

Separate table checks from execution

findmnt --verify --verbose helps assess the table and its usability. Keep output and resolve identified issues. Then, in a lab environment with recovery prepared, test the intended mount and confirm observed state. Testing with mount on the configured point is an operation, not merely a read. Controlled reboot provides another check: configuration must reproduce state without manual intervention. Finally, test the functional action under the service identity. These steps answer different questions; a favorable first result does not allow the remaining steps to be recorded as executed in the acceptance report.

Express dependency and understand its limits

After defines ordering but does not itself pull in the referenced unit. For a correctly configured mount, RequiresMountsFor=/srv/ledger in the service Unit section adds requirements and ordering for units needed by the path. This relationship is useful but does not verify the UUID or data semantics. If the dedicated mount disappears from configuration, root may be sufficient to access the directory. Retain explicit validation of the expected source and rehearse failure of the configured mount. Do not treat the example as a universal isolation guarantee: namespaces, other dependencies, and application behavior require observation on the actual system.

Understand nofail and the overlaid view

nofail lets boot continue without the corresponding target requiring that mount to succeed. This can suit optional storage but does not make data optional for the service. In our case, the batch wrote into the root directory while the volume was absent. When the volume is mounted, underlying contents disappear from that view; do not conclude they were deleted or reconciled. Suspend producers and arrange controlled access to both sources before correcting results. Blind resumption can duplicate operations already recorded outside the filesystem. The application decision requires more evidence than mounted state.

Give APS repeatable evidence

Handover should let another operator explain how success and failure are recognized. Supply expected paths and identities, persistent configuration, dependencies, observation commands, logs, recovery procedure, and owners. In a disposable lab, rehearse normal startup and failure of the configured mount. Verify that the service does not start writing to root; then restore configuration and repeat normal acceptance. Do not induce this failure in production as part of the exercise. The platform provides decisions and interpretation models without claiming it executed systemd, created filesystems, or rebooted a RHEL VM. That practice remains necessary for an operational exam.

findmnt --verify --verbose
findmnt -T /srv/ledger -o SOURCE,TARGET,FSTYPE,OPTIONS
findmnt -M /srv/ledger -o SOURCE,TARGET,FSTYPE,OPTIONS
IN PRACTICE

findmnt -T /srv/ledger returns TARGET=/. The directory exists, but the expected dedicated mount has not been demonstrated. Compare with findmnt -M and the approved source before allowing the batch.

Common pitfalls

Treating nofail as application availability, After as a requirement, RequiresMountsFor as UUID proof, or an existing directory as a dedicated mount.

Related topics: systemd and services · Incident recovery

Take this idea with you

Persistence requires configuration and observation after reboot; acceptance also requires the correct source and service behavior.

Create account

Reference: RHEL 10 persistent filesystem mounts · EX200 based on Red Hat Enterprise Linux 10

Red Hat® and RHCSA are trademarks or registered trademarks of Red Hat, Inc. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by Red Hat. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.