Mount and unmount safely

A mount hides any files already present under its mount point until the filesystem is unmounted.

This surprises people. If a service writes to /srv/data before the data volume gets mounted there, those files land on the root filesystem. Mount the volume and they vanish from view — still consuming root disk space, invisible until you unmount again. Mount points should be dedicated, empty directories for exactly this reason.

Mounting

Create a dedicated directory, mount by device for the first test, and verify with findmnt:

sudo mkdir -p /mnt/lab
sudo mount /dev/sdb1 /mnt/lab
findmnt /mnt/lab

TARGET   SOURCE     FSTYPE OPTIONS
/mnt/lab /dev/sdb1  ext4   rw,relatime

TARGET is where the filesystem appears, SOURCE is the device behind it, and OPTIONS shows how it was mounted — rw here, so writes are allowed. If findmnt prints nothing, the mount didn’t happen.

A manual mount lasts until reboot. Persistent mounts belong in /etc/fstab, which gets its own lesson because a typo there can break boot.

Unmounting

Before unmounting, stop writers and check nothing still holds the filesystem open:

sudo umount /mnt/lab
# umount: /mnt/lab: target is busy.

target is busy means some process still has a file open there, or its working directory inside it. Use fuser or lsof to find processes holding paths open:

sudo fuser -vm /mnt/lab

                     USER    PID ACCESS COMMAND
/mnt/lab:            flavio  4211 ..c.. bash

The c under ACCESS means that process’s current directory is inside the mount. The most common offender is your own shell — you cd’d into the mount earlier. cd out, stop any services that write there, and retry the umount.

Never unplug or detach a mounted device without unmounting. Cached writes that haven’t reached the disk yet are lost, and the filesystem can be left needing repair.

Mount a disposable filesystem under /mnt/lab. Create a file, inspect the mount, leave the directory, unmount it, and verify the original mount point is visible again.