Create and configure file systems practice questions

The directory /mnt/backup is not empty.

Why it fails: A non-empty directory never blocks a mount operation; the Linux kernel will happily mount a filesystem over existing contents, hiding them until the filesystem is unmounted. The mount(8) utility does not check whether the mountpoint contains files, so the technician would see no error at all if this were the only issue. Therefore, a non-empty /mnt/backup would not explain a mount failure.

The device /dev/sdc1 does not exist.

Why it fails: If /dev/sdc1 were missing, the mount command would fail with an explicit error like 'mount: /dev/sdc1: can't read superblock' or 'no such device' because the device node or underlying device does not exist. This type of error points directly to the device, not to the mountpoint's security context. Since the error is device-specific, it would not be confused with a SELinux or directory-related denial.

The filesystem on /dev/sdc1 is not XFS.

Why it fails: If the filesystem on /dev/sdc1 were not XFS, mount would identify the mismatch after reading the superblock and return an error such as 'mount: /dev/sdc1: wrong fs type, bad option, bad superblock'. That message is recognizably about the filesystem type, not about the mountpoint's context or the device node's existence. Because the operation would fail before any SELinux mountpoint check, this cause is distinct from the correct answer.

mount -t nfs -o ro,root_squash nfs.example.com:/exports/app /mnt/app

Why it fails: root_squash explicitly enables the NFS default behavior in which the server maps the client root user (UID 0) to an unprivileged anonymous account such as nfsnobody. The task specifically calls for no_root_squash, so this command does the opposite of the required squash setting and would cause client-root operations to be attributed to nobody instead of root. Although the ro flag is correct, the squash policy makes this mount fail the requirement.

mount -t nfs -o ro,no_root_squash,nosuid nfs.example.com:/exports/app /mnt/app

Why it fails: This command adds nosuid, which disables setuid and setgid bit execution on the mounted filesystem. While nosuid is a legitimate hardening option and would not prevent the mount from working, it is an extra flag not specified in the requirement; the task asks for exactly ro and no_root_squash, and adding an unrequested mount option changes the mount's behavior. Therefore, in the context of this exam question, this variant is incorrect even though nosuid itself is not harmful.

mount -t nfs -o rw,no_root_squash nfs.example.com:/exports/app /mnt/app

Why it fails: It uses rw instead of ro, making the NFS share writable from the client. With rw, the client can create, delete, or modify files on /exports/app, which directly contradicts the requirement to mount the share read-only. Even though no_root_squash is correctly present, the rw flag is a fatal deviation, so the entire command must be rejected.

suid

Why it fails: suid is not a valid mount option for /etc/fstab because the corresponding option is nosuid (to disable setuid bit). Specifying suid would enable setuid, but it is not commonly used in fstab; instead, nosuid is the standard option.

nodev

Why it fails: nodev is technically a valid mount option that prevents the kernel from interpreting block or character device nodes on the mounted filesystem, which is a useful security hardening measure. In this particular question, however, it is not one of the three options that make up the correct answer set—noexec, noatime, and relatime are the intended choices. The exam is testing your ability to identify the exact set of correct mount options from the list, so even though nodev is a legitimate flag, selecting it here would be marked wrong.

The mount point is incorrect.

Why it fails: If the mount point were incorrect, df would show either a different filesystem or no entry at all for this logical volume. The LV is mounted at the correct path, so df is indeed showing the filesystem on that LV, but it reports the filesystem's size, not the block device's size. Since the filesystem was not grown after lvextend, the old capacity persists even though the underlying device has been enlarged.

The physical volume is full.

Why it fails: The physical volume is not full; the volume group still has roughly 250G of free space (VFree), and lvextend completed successfully. If the PV were truly full, lvextend would have failed, leaving the LV at its original size, in which case df would report that unchanged size and there would be no discrepancy. A full PV prevents extending the LV, but it does not explain why df shows a smaller size than the already-extended LV.

The logical volume extension failed.

Why it fails: The lvextend operation clearly succeeded, often printing a confirmation with the new size and showing 500G in lvs. If the extension had failed, the LV would still be at its original size, and df would match that size exactly. The observed mismatch—500G LV but a smaller df value—is only possible if the LV was extended while the filesystem resize step was skipped.

The entry in /etc/fstab is malformed.

Why it fails: Although a malformed line in /etc/fstab is a common cause of boot-time mount failures (e.g., missing colon separators, wrong number of fields, or invalid mount options), in this scenario the entry is syntactically correct; each field is properly separated and the option list is valid. Because the syntax parses fine, the mount error must be caused by something else, such as the server being unreachable or the NFS client tools not being installed. A malformed fstab entry would show a parsing or 'wrong fs type' error at mount time, but the provided error is network-related.

The filesystem type 'nfs4' is incorrect; should be 'nfs'.

Why it fails: The filesystem type 'nfs4' is not an error; it is a valid type that explicitly designates NFSv4, the current major version, and is supported on modern Red Hat systems. In fact, /etc/fstab entries using 'nfs' are auto-negotiated and may still mount as v4, but writing 'nfs4' is perfectly acceptable and will not cause a mount failure. If the mount were to fail because of an incorrect type, the error would be 'unknown filesystem type' rather than a connectivity error, which is not the case here.

The mount point /mnt/data does not exist.

Why it fails: A nonexistent mount point would produce a distinct error: 'mount point /mnt/data does not exist' or similar, and no attempt would be made to contact the server. In this scenario, however, /mnt/data exists and is in fact a valid directory (as confirmed by an ls listing), so a missing mount point cannot be the reason for the failure. Since the mount point check passes, the problem is downstream — during the actual NFS communication or client capability setup.

Run mkfs.xfs /dev/sdb directly; it will overwrite the partition table and create a file system.

Why it fails: Running mkfs.xfs /dev/sdb without -f will not overwrite anything; XFS detects the existing partition table and aborts with an error. Even if you added -f, it would obliterate the partition table and place the XFS superblock at the beginning of the raw disk, leaving no partition entry — a non-standard configuration that many systems won't recognize as a usable storage device. The correct procedure is to create a partition first.

Use pvcreate /dev/sdb, then vgcreate, lvcreate, and format the logical volume with mkfs.xfs.

Why it fails: This LVM approach is technically executable but completely unnecessary and fails the stated requirement: you would not create a filesystem on the whole disk, but rather on a logical volume carved from a volume group, adding PV/VG/LV layers of indirection. The question asks for a single filesystem on /dev/sdb, and the expected solution uses a standard partition, not LVM. In the exam scenario, LVM is not configured, and the logical volume device (/dev/vg0/lv0) is not a directly usable partition entry on the disk.

Save and exit the crontab file first, then edit it again to add the line '30 2 * * * /path/to/script'.

Why it fails: Saving and exiting before adding the entry means the crontab editor writes the unmodified cron table back, leaving the existing jobs (or nothing) exactly as they were. The new line '30 2 * * * /path/to/script' was never inserted, so the save cannot include it; a subsequent 'crontab -e' session is a separate operation, but starting it does not retroactively apply the earlier save. The correct action is to add the line within the same editing session, because the editor will only write what is present when you save. This option also creates a pointless two-step process where the first save contributes nothing.

Exit the crontab editor immediately, then edit the file again with 'crontab -e' and add the line '30 2 * * * /path/to/script'.

Why it fails: Exiting the crontab editor immediately, with no changes made, simply closes the editor and the crontab is unchanged; no job is scheduled. After that, opening 'crontab -e' a second time and adding the line would work, but the first exit was unnecessary and did not help create the job. The correct sequence is to remain in the initial editing session, insert the cron line, and then exit with a save — an early exit cannot be combined with later edits because each session starts from the currently stored crontab. This option mistakes the app-level edit operation for a shell command sequence, when in fact the line must exist in the buffer before save.

quota

Why it fails: The generic quota option is not a valid mount flag for any major filesystem, including XFS. Mount helpers expect a type-specific option such as uquota for user quotas or gquota for group quotas on XFS. Specifying only 'quota' will be rejected by the kernel as an unknown mount option, so it has no effect in enabling per-user quotas.

usrquota

Why it fails: usrquota is a valid mount option for ext4, but it is not recognized by the XFS filesystem. XFS requires its own quota option names: uquota for user quotas, gquota for group quotas, and pquota for project quotas. Attempting to mount an XFS filesystem with usrquota will produce an 'unknown mount option' error, so it cannot enable per-user quotas on XFS.

user_quota

Why it fails: user_quota is not a recognized mount option for XFS or any other common filesystem. The underscore format is not used in Linux mount options; they are typically single, unbroken words like uquota or usrquota. Since the kernel has no handler for 'user_quota', it will be ignored or rejected, and per-user quota enforcement will not be activated.

Create a volume group

Why it fails: A volume group is an LVM abstraction that pools physical volumes into a single storage container from which logical volumes are allocated. It is a prerequisite for LVM-managed storage, but it does not directly participate in XFS filesystem creation because mkfs.xfs operates on a block device, not on a pool. Additionally, XFS can be created on a raw partition or loop device without any LVM involvement, so a volume group is not required for the filesystem itself.

Create a physical volume

Why it fails: A physical volume is a block device that has been initialized for LVM with pvcreate, marking it as available for inclusion in a volume group. This step is part of preparing storage for LVM, but it only makes raw capacity available to the LVM layer; it does not create or initialize any filesystem. Since XFS creation requires a formatted block device (typically a logical volume or partition) and not an LVM metadata structure, a physical volume is not a direct requirement for XFS.

Run xfs_admin on the LV

Why it fails: xfs_admin is a utility for inspecting and changing parameters of an existing XFS filesystem, such as setting a UUID, adjusting label, or toggling lazy-count behavior. It cannot initialize a logical volume because it expects a valid XFS superblock to already exist; running it on an unformatted LV fails with an error indicating no superblock was found. Filesystem creation is exclusively the job of mkfs.xfs, so running xfs_admin is neither a creative step nor a required one.

Edit /etc/fstab to add noexec and reboot

Why it fails: Editing /etc/fstab to add noexec is a persistent configuration change, but it does not affect the currently mounted filesystem. The noexec option will only take effect after a remount or a reboot, so rebooting is an unnecessarily disruptive way to apply it. For an immediate remount of /mnt/data, the correct command is mount -o remount,noexec /mnt/data, not a reboot.

mount -o remount,noexec /dev/sdb1 /mnt/data

Why it fails: The mount -o remount,noexec command is meant to modify the options of an existing mount, and the kernel identifies that mount by its mount point, not by the device file. Including /dev/sdb1 is redundant and non-standard; while it may succeed if the device path exactly matches the mounted device, it introduces a potential failure if the path is incorrect or the device name has changed. The correct syntax for a remount is simply mount -o remount,noexec /mnt/data, so this option is not the correct answer.

umount /mnt/data && mount -o noexec /dev/sdb1 /mnt/data

Why it fails: This command fails because it attempts to remount `/mnt/data` by specifying the device `/dev/sdb1`. While this would correctly apply the `noexec` option, the question implies the administrator wants to remount the *existing* filesystem at `/mnt/data`, not necessarily re-associating it with a specific block device. This option is tempting because it demonstrates the correct syntax for unmounting and then remounting with specific options, which is a common administrative task, and would be correct if the intention was to explicitly re-bind the mount point to `/dev/sdb1`.

The mount point /docs was deleted during reboot

Why it fails: A reboot does not delete mount point directories; filesystem entries persist unless explicitly removed with commands like `rm -rf`. Even if /docs were missing, the mount command would report 'mount point does not exist', not fail to activate the volume group. Thus, this does not explain the observed behavior.

The XFS filesystem was corrupted during reboot

Why it fails: XFS is a journaling filesystem that can recover from crashes using its log, and a clean reboot does not induce corruption. Filesystem corruption would trigger XFS-specific errors during mount or require `xfs_repair`, but it would not prevent the volume group from becoming active. The LVM layer is independent of the filesystem state, so corruption cannot be the cause.

The logical volume name is misspelled in /etc/fstab

Why it fails: If the logical volume name were misspelled in /etc/fstab, the system would attempt to mount a nonexistent device and log a 'No such device' error during boot. However, the question states the configuration worked before the reboot, so a spelling error would only appear if the file had just been edited, which is not indicated. The real issue is that the LV never appears because the VG is inactive.

lvcreate -l 1.5G -n lv_new vg_data

Why it fails: This command is wrong because the lowercase -l option does not accept a size like 1.5G; it specifies the number of logical extents. When you use -l, you must provide an integer (or a percentage such as 50%FREE), and that integer is multiplied by the extent size to determine the volume size. Passing '1.5G' with -l is invalid syntax and would cause lvcreate to fail or misallocate the size.

lvcreate --size 1.5G --name lv_new vg_data

Why it fails: While lvcreate supports long options like --size and --name, the short options -L and -n are the standard syntax expected on the exam. Option C is syntactically correct but not the typical choice, so it is marked incorrect.

lvcreate -L 1500M -n lv_new vg_data

Why it fails: While -L 1500M may look equivalent, it is not exactly 1.5 GiB. The -L option with M uses mebibytes (MiB), so 1500M equals 1500 MiB, which is 1500/1024 = 1.46484375 GiB, slightly less than the required 1.5 GiB. To create exactly 1.5 GiB you would need -L 1536M, or simply use -L 1.5G as in the correct answer.

The client's IP is in the allowed subnet but the export entry for /export/restricted is missing from /etc/exports after a change and not re-exported

Why it fails: The client's IP 10.0.0.5 is within the allowed subnet 10.0.0.0/24, so the issue is not subnet mismatch. The correct reason is that the export entry for /export/restricted is missing from /etc/exports after a change and the NFS server has not been re-exported with `exportfs -ra`.

The export uses root_squash which maps root to nobody, causing permission issues

Why it fails: While root_squash does map root to the anonymous user 'nobody' for file operations, it has no effect on the NFS mount handshake itself. The 'Permission denied' error at mount time is generated by the server's MOUNT protocol (rpc.mountd) when it evaluates the client's IP against the export restrictions in /etc/exports, not by UID/GID mapping rules. root_squash only alters access after the share is successfully mounted, so it cannot cause a mount-time failure.

The export /export/restricted has ro (read-only) and the client might be trying to write

Why it fails: A read-only export option (ro) restricts write operations after the mount has been established, but the mount attempt itself does not perform any write operation. During the NFS mount, the client requests a file handle via the MOUNT protocol, and the server responds based on export permissions — the 'ro' flag is enforced later on read/write requests. If the client is denied at mount time, the reason must be an export-level restriction, not the read-only attribute, which would only produce errors like EROFS during post-mount writes.

mkfs.ext4 /dev/sdb1 && mount /dev/sdb1 /data

Why it fails: The command creates the ext4 filesystem but then attempts to mount it to /data without first creating that directory — mount(8) will fail with 'mount point /data does not exist'. Even if the directory existed, this sequence omits the /etc/fstab entry entirely, so the filesystem would not be mounted after a reboot. Persistence requires an fstab record, not just an immediate mount.

mkfs -t ext4 /dev/sdb1 && echo '/dev/sdb1 /data ext4 defaults 0 0' >> /etc/fstab && mount /data

Why it fails: This sequence writes the fstab entry before verifying that the mount point exists and then issues mount /data with no device argument, which relies on fstab lookup but fails because /data is absent. Creating a filesystem and adding an fstab line for a nonexistent directory is invalid; the mount attempt would report that /data does not exist. The missing mkdir prevents both the immediate mount and any future boot-time mount from succeeding.

mkfs.ext4 /dev/sdb1 && mkdir /data && mount /dev/sdb1 /data && blkid /dev/sdb1 >> /etc/fstab

Why it fails: Running blkid /dev/sdb1 outputs key=value data such as /dev/sdb1: UUID="..." TYPE="ext4", which is not a valid /etc/fstab line — fstab requires whitespace-separated fields: device (or UUID=), mount point, filesystem type, options, dump, and pass. Appending this raw output corrupts fstab and would cause mount -a to fail with a parsing error. The correct way to reference a filesystem by UUID in fstab is a line like UUID=... /data ext4 defaults 0 0.

df -i

Why it fails: df -i — Incorrect: -i switches the report to inode counts rather than block usage, showing used and free inodes on each filesystem. Inode exhaustion is a real failure mode, but it produces 'no space left on device' errors while block space remains; it does not reflect the free data blocks that govern write performance. A server with plenty of free inodes can still have a completely full disk, so this gives no useful signal about slow write throughput.

du -h --max-depth=1 /

Why it fails: du -h --max-depth=1 / — Incorrect: du sums the sizes of files and directories under the given path, so this shows how much space the root directory's immediate children consume, not how full the underlying filesystem is. By default du can cross mount points, meaning it mixes together usage from multiple partitions and misses the free-space report that df provides. Even if it reports directory sizes, it never shows available capacity or use percentage per filesystem.

du -sh /

Why it fails: du -sh / — Incorrect: du -sh / simply gives the cumulative apparent size of the entire root path in human-readable form, rolling all mounted filesystems into one number. It does not break down usage per partition, does not report free space, and does not indicate which filesystem's capacity might be throttling writes. Unlike df, du also counts files being written but not yet synced differently, so it is not a reliable indicator of actual on-disk availability.

mkswap /dev/sdd1 && echo '/dev/sdd1 swap swap defaults 0 0' >> /etc/fstab

Why it fails: This command initializes the swap area correctly with mkswap and writes an /etc/fstab entry so the swap will persist across reboots, but it never executes swapon to activate the swap immediately. Without running swapon (or rebooting), the system continues to run with no active swap space, so the administrator's request to 'add' swap is not fulfilled at runtime. The fstab entry is necessary for persistence, but activation must happen first in the current session.

mkfs.swap /dev/sdd1 && swapon /dev/sdd1

Why it fails: The command mkfs.swap is not a valid utility; the correct command-line tool for creating a swap signature on a partition is mkswap. Even if the intent were to use mkfs.swap as a synonym, the command would fail with 'command not found', and the subsequent swapon would never run because of the && short-circuit operator. Additionally, even a successful mkswap + swapon sequence would still lack an /etc/fstab entry, meaning the swap would not be available after a reboot.

mkswap /dev/sdd1 && swapon /dev/sdd1

Why it fails: This command correctly initializes the partition with mkswap and activates it with swapon, so swap becomes available immediately. However, it does not add an entry to /etc/fstab, so the swap space will not be automatically activated when the system reboots; the administrator would need to manually run swapon after every boot. It also assumes that /dev/sdd1 already exists as a partition, but the question requires creating a 1 GB swap partition, so partition creation (e.g., with fdisk) is a missing prerequisite.

fsck cannot fix errors on ext4 filesystems.

Why it fails: This statement is false. fsck is the standard filesystem check and repair tool for the ext2, ext3, and ext4 families; it can detect and fix a wide range of metadata inconsistencies such as incorrect inode counts, bad block bitmaps, and orphaned inodes. The question explicitly leads to an ext4 context only in this option, but fsck absolutely can repair ext4 filesystems, so it is not a valid explanation for why a filesystem would remain read-only.

The filesystem is still mounted; fsck cannot fix it while mounted.

Why it fails: Incorrect. While fsck should not be run on a mounted filesystem, the presence of a 'clean' status and read-only mount suggests the filesystem is not actively mounted for writes; the issue is with the filesystem type.

fsck detected errors but did not fix them automatically.

Why it fails: This is incorrect. If fsck had detected real errors on a filesystem it supports, it would report them and request confirmation before patching, rather than silently leaving the device read-only; a 'clean' status from fsck explicitly means it found no errors to fix. In the XFS scenario described, fsck does not perform a thorough check at all, so it neither detects nor fixes XFS inconsistencies—the 'clean' output is misleading and not evidence that errors were skipped.

Run 'mdadm --manage /dev/md0 --add /dev/sdb'

Why it fails: The mdadm mirror is composed of partitions, not raw disks, so adding /dev/sdb as a whole disk would make it a non-conforming member and fail to integrate with /dev/sda1. You must first partition /dev/sdb with an identical layout (e.g., using sfdisk) and then add /dev/sdb1 to the array. Without a proper partition entry of type 'fd' (Linux RAID autodetect) or matching UUID, mdadm will reject the device.

Remove the failed disk with 'mdadm /dev/md0 --fail /dev/sdb1' then add new.

Why it fails: Since the original /dev/sdb1 is already marked as failed and removed from the array, executing '--fail' again is redundant and may even return an error. The recovery procedure should skip straight to copying the partition table from the surviving disk and then using '--add' to enroll the new /dev/sdb1. Failing a device that is no longer active does not help rebuild the mirror; it only wastes time.

Run 'mdadm --assemble --scan' to rebuild the array automatically.

Why it fails: 'mdadm --assemble --scan' only activates an existing array by reading superblocks from member disks; it cannot restore a failed disk or trigger a rebuild. If the array is already running (as implied by the failure of one mirror member), assembly is not needed at all. This command would not partition the new disk, and it would simply return the current array to active state without replacing the missing member.

mkfs.xfs -l data /dev/nvme0n1p1

Why it fails: The lowercase -l option in mkfs.xfs is reserved for log configuration suboptions (e.g., logdev=..., size=...), not for naming the filesystem. Supplying `data` as its argument is syntactically invalid and will be rejected; even if parsed, it would attempt to set log parameters rather than the volume label. Only uppercase -L assigns the label, so this command fails to produce a filesystem labeled `data`.

mkfs.xfs -f /dev/nvme0n1p1

Why it fails: The -f flag forces mkfs.xfs to overwrite any existing filesystem signature on the partition, which is useful when re-creating a filesystem. However, it controls neither the label nor any naming parameter: the resulting XFS volume will have no label unless an explicit label option (like -L) is given. Because the question requires a labeled filesystem, this command is incomplete.

mkfs.xfs -n data /dev/nvme0n1p1

Why it fails: The -n option configures XFS naming/version parameters such as ftype, not the filesystem label. In this context `data` is not a valid naming setup, and the option is only used to tune features like the version of the naming protocol or ftype values. Therefore the command would error out or set an unintended naming feature, not label the volume, making it wrong.

e2label /dev/sda1

Why it fails: e2label /dev/sda1 is a filesystem utility specifically for ext2/ext3/ext4 volume labels; it reads or sets the label stored in the superblock, not the UUID. The UUID is a separate 128-bit identifier in the same superblock, and e2label has no option to display it.

findmnt /dev/sda1

Why it fails: findmnt /dev/sda1 prints the mount relationship and defaults to columns like SOURCE, FSTYPE, MOUNTPOINT, and OPTIONS. It does not include UUID by default; you would have to explicitly add -o UUID, and even then it is a mount-aware wrapper, not the primary tool for querying raw device identifiers.

file -s /dev/sda1

Why it fails: file -s /dev/sda1 inspects the raw data on the device and identifies the filesystem type (for example, 'Linux rev 1.0 ext4 filesystem data'), but it is not designed to extract or display a UUID. Its purpose is file type magic detection, not filesystem attribute lookup.