Mount Filesystems and Block Devices

What you will be able to do

• Explain the five core decisions involved in mount filesystems and block devices.
• Choose the narrow Linux command or method that matches a stated operational need.
• Interpret command output as evidence before deciding whether to change system state.
• Apply an observe, act, verify, and recover workflow to a realistic Linux task.

01

Build the Operating Model

Identify block devices and filesystems, mount them at deliberate paths, and validate persistent definitions without risking the wrong device.

Reliable Linux work separates observation, decision, action, and verification. That order keeps a command from becoming a guess and makes each result useful for the next decision.

Begin in a disposable lab or a recoverable environment. Record the active user, working directory, target, and baseline output before any command that can change system state.

02

Block device identity

Block devices represent storage endpoints, while partitions and filesystems add layers that must be identified separately. This distinction helps identify the smallest relevant part of the system before a change is attempted.

List names, sizes, types, filesystems, labels, and mount points before selecting a storage target. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: device names can change between boots. You should be able to verify this result: device layers and current use are visible.

03

Filesystem identity

A filesystem type and persistent UUID identify formatted content independently from a transient device path. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Read filesystem metadata without formatting and record the UUID before creating a persistent mount definition. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: formatting would destroy existing filesystem metadata. You should be able to verify this result: filesystem type and stable identifier confirmed.

04

Mount point

A mount attaches a filesystem to a directory so its tree becomes accessible at that path. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Create an empty intended directory, mount the verified filesystem, and inspect the resulting source-target mapping. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: existing mount-point contents become hidden while mounted. You should be able to verify this result: filesystem is reachable at the chosen directory.

05

Unmounting

Unmounting detaches a filesystem after active references and pending writes have been handled. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Leave the mounted directory, stop processes using it, unmount, and confirm the mapping disappeared. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: forced removal can risk incomplete writes. You should be able to verify this result: filesystem is detached cleanly from the tree.

06

Persistent mounts

The `/etc/fstab` file describes filesystems and options that may be mounted automatically or by simplified commands. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Use a UUID, create a backup, validate all entries, and test the specific mount before rebooting. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: a malformed entry can delay or disrupt boot. You should be able to verify this result: persistent mount definition passes validation.

07

Apply One Controlled Change

Start from the read-only commands that reveal identity, scope, and current state. Write the expected result before entering a modifying command, including which files, processes, accounts, or connections may be affected.

Make one narrow change and stop. If the output reports an error or an unexpected target, preserve that evidence and return to inspection instead of adding unrelated commands.

Repeat the original observation after the action. A successful command status is useful, but the real completion signal is the intended state plus the absence of an unintended side effect.

08

Complete the Evidence Loop

A good terminal record answers four questions: what was observed, why one action was selected, exactly what changed, and how the result was verified. A screenshot without command context answers fewer questions than saved text output.

Test both the expected success and one safe failure condition. This confirms that the procedure recognizes a wrong path, missing permission, invalid input, stopped service, or unavailable endpoint instead of silently continuing.

Finish by restoring the lab baseline when the task was experimental. For an operational change, record the final state and the reversal step so later work begins from a known boundary.

09

Recap Before Practice and Prove

The first decision concerns block device identity. List names, sizes, types, filesystems, labels, and mount points before selecting a storage target.

The second decision concerns filesystem identity. Read filesystem metadata without formatting and record the UUID before creating a persistent mount definition.

The third decision concerns mount point. Create an empty intended directory, mount the verified filesystem, and inspect the resulting source-target mapping.

The fourth decision concerns unmounting. Leave the mounted directory, stop processes using it, unmount, and confirm the mapping disappeared.

The final decision concerns persistent mounts. Use a UUID, create a backup, validate all entries, and test the specific mount before rebooting. Keep the final output as the baseline for the next task.