101-350 · Question #111
After running the command umount /mnt, the following error message is displayed: umount: /mnt: device is busy. What is a common reason for this message?
The correct answer is B. A user has a file open in the /mnt directory. See the full explanation below for the reasoning.
Question
Options
- AThe kernel has not finished flushing disk writes to the mounted device.
- BA user has a file open in the /mnt directory.
- CThe previous rm command has not finished.
- DThe files in /mnt have been scanned and added to the locate database.
- EThe kernel thinks that a process is about to open a file in /mnt for reading.
How the community answered
(38 responses)- B82% (31)
- C5% (2)
- D3% (1)
- E11% (4)
Community Discussion
5
Imani T.Oct 8, 2025B is correct. The "device is busy" error means the kernel sees an active reference to that filesystem, and the most common cause is a process with an open file handle or a shell session sitting inside /mnt, so the kernel refuses to unmount it until that process closes out or you kill it.
Mei-Ling H.Oct 10, 2025Good point on the open file handle, but do not overlook bind mounts or loop devices still attached to the filesystem, because those kernel references also block umount without any visible process holding a file open.
Mei-Ling H.Oct 5, 2025Does "busy" mean writes pending, or that a process holds the mount open?
Hiroshi T.Oct 16, 2025I keep coming back to D on this one and here is my reasoning. The updatedb process that feeds the locate database does a full directory traversal and holds open file descriptors across the mounted filesystem while it indexes, and if that job is running or has recently run and its handles have not been released, the kernel will still see /mnt as active. The man page for umount explicitly states that the filesystem cannot be unmounted while any process holds a file descriptor pointing into it, and updatedb is one of those background processes that runs silently via cron and catches people off guard. B sounds plausible on the surface but a single user closing a file takes a fraction of a second and most people would notice that before running umount, whereas updatedb runs in the background without any terminal feedback to warn you. My advice is to run lsof +D /mnt to confirm which process is holding the mount open, and on a typical system after a cron-triggered updatedb you will see exactly this situation.
Mei-Ling H.Oct 18, 2025Hiroshi, your technical reasoning about updatedb is solid in real life, but the exam is testing the most direct and common cause of a "device is busy" error, which is B, a user having a file or working directory open on that filesystem. The updatedb scenario is a valid edge case but it is not what the question is pointing to, and on these exams "most likely" always pulls you toward the everyday user-action answer, not the background-process exception.