mediumMultiple Choice

XK0-006 Practice Question: Refer to the exhibit

Exhibit

$ cat /etc/fstab
# /etc/fstab: static file system information.
UUID=abc123 /               ext4    errors=remount-ro 0       1
UUID=def456 /home           ext4    defaults         0       2
UUID=ghi789 none            swap    sw               0       0
UUID=jkl012 /data           xfs     defaults         0       2
$ mount | grep /data
/dev/sdb1 on /data type xfs (rw,relatime,attr2,inode64,noquota)
$ df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       100G   95G  5.2G  95% /data

Refer to the exhibit. A user reports that they cannot write to /data, receiving a 'No space left on device' error. However, the df output shows 5.2G available. What is the most likely cause?

⚠ Common exam trap

XK0-006 often tests the distinction between block exhaustion and inode exhaustion, so candidates who only check df (blocks) and not df -i (inodes) misdiagnose the problem as a mount or permission issue.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The filesystem is out of inodes.

'No space left on device' despite df showing free space is the classic symptom of inode exhaustion. Each file and directory consumes an inode, and a filesystem can run out of inodes even when blocks (space) remain available. This commonly happens with directories containing millions of tiny files, such as mail queues, session files, or cache directories.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The /data entry in fstab is incorrect, causing the mount to fail.
Why it's wrong here
An incorrect fstab entry would prevent /data mounting entirely, so df would not report it with 5.2G available; the error indicates inode exhaustion or reserved blocks on a mounted filesystem. fstab errors are the cause when a filesystem is absent from df output after boot.
✗
The partition is mounted read-only.
Why it's wrong here
A read-only mount returns EROFS ('Read-only file system'), not ENOSPC, so the error text contradicts this cause. It is tempting because read-only remounts after I/O errors do block writes, but the kernel reports the specific errno, and df would still show free space for a different reason.
✓
The filesystem is out of inodes.
Why this is correct
df reports block usage, not inode consumption. A filesystem can have free blocks yet exhaust its inode table through many tiny files, so creating any new file fails with 'No space left on device' despite the 5.2G shown.
✗
The UUID for /data has changed.
Why it's wrong here
A changed UUID would prevent the filesystem mounting at all, not produce ENOSPC while df reports free blocks. It is tempting because UUID mismatches in /etc/fstab are a common boot failure, but that scenario yields a mount error or emergency shell, not a write failure on an already-mounted volume.

Go deeper

XK0-006 Practice Question: Refer to the exhibit

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question