Mounting and File Systems Table

A formatted filesystem from the last chapter still isn’t usable until it’s attached somewhere in the directory tree you’ve been navigating. Mounting is that attachment step — and this chapter covers both doing it by hand and making it stick permanently, since those turn out to be two genuinely separate problems.

What Mounting Actually Means

Recall /mnt and /media from the Filesystem Hierarchy Standard lesson, described there as “attachment points” without much elaboration. This is where that finally gets explained properly: mounting takes a filesystem — whether it’s the partition you just formatted, a USB drive, or even a network share — and makes its contents appear at a specific directory, called the mount point, as if they’d been there all along.

Before mounting, /mnt/project-data (or wherever you choose) is just an ordinary, empty directory. After mounting your /dev/sdb1 filesystem there, every file you create inside /mnt/project-data is actually being written to that separate filesystem — even though, to every command you’ve learned so far (ls, cd, cp), it looks and behaves like an ordinary part of the tree.

Mounting By Hand: mount

First, the mount point needs to exist — mount won’t create a directory for you:

sudo mkdir -p /mnt/project-data

Then mount the filesystem onto it:

sudo mount /dev/sdb1 /mnt/project-data

Confirm it worked:

lsblk -f

You’ll see /mnt/project-data now listed in the MOUNTPOINTS column next to sdb1, exactly the kind of output shown back in the very first chapter of this section, now with a real value in that column instead of being empty.

Run mount on its own, with no arguments, and it lists every currently mounted filesystem on the system — genuinely dense output, but useful for confirming what’s attached where at any given moment.

Unmounting: umount

sudo umount /mnt/project-data

Note the spelling — it’s umount, not “unmount.” This detaches the filesystem from that mount point; the data itself is completely unaffected, it’s simply no longer accessible through that directory until mounted again.

You’ll sometimes hit a “target is busy” error here — this is exactly the situation the lsof/fuser chapter back in Processes & Job Control was building toward. Some process still has an open file somewhere under that mount point, and the kernel refuses to unmount out from under it:

fuser -vm /mnt/project-data

This identifies exactly what’s still using it, letting you deal with that process deliberately rather than forcing an unmount blind.

The Problem: Mounts Don’t Survive A Reboot

Everything above is genuinely temporary. Reboot the system, and /mnt/project-data goes back to being an empty, ordinary directory — the mount itself isn’t remembered anywhere. For anything you want available permanently, that’s what /etc/fstab is for.

/etc/fstab: Making Mounts Permanent

/etc/fstab (“filesystem table”) is a plain text file — readable with everything you already know, cat /etc/fstab — listing every filesystem that should be mounted automatically, every time the system boots. Each line follows a fixed six-field format:

UUID=4a2b1c3d-5e6f-7890-abcd-ef1234567890  /mnt/project-data  ext4  defaults  0  2

Why UUID Instead Of A Device Path

This is exactly the payoff from generating that UUID back in the mkfs chapter. Recall from the very first chapter of this section: /dev/sdb isn’t a fixed, guaranteed identity — it’s assigned based on detection order at boot, which can shift if disks are added, removed, or simply detected in a different sequence. An /etc/fstab entry pointing at /dev/sdb1 can silently end up pointing at the wrong disk after a hardware change, mounting the wrong filesystem at that mount point with no error at all. A UUID is generated once, tied to the filesystem itself, and doesn’t change no matter how disks get reordered — which is exactly why every practical /etc/fstab guide, this one included, pushes toward UUID over device path.

Find the UUID for any filesystem the same way covered in the last chapter:

sudo blkid

Testing Before You Trust It

This is the single most important habit in this file: never edit /etc/fstab and then simply reboot to see if it worked. A malformed entry can cause the system to drop into an emergency recovery shell during boot, rather than starting normally — a genuinely stressful situation to debug on a remote server with no physical access.

Instead, test your edit immediately, without rebooting at all:

sudo mount -a

-a tells mount to mount everything listed in /etc/fstab that isn’t already mounted — effectively simulating exactly what boot would do, right now, while you’re still safely logged in and able to fix a mistake immediately if something’s wrong.

A Full Example, Start To Finish

Putting the whole thing together, continuing directly from the mkfs chapter’s /dev/sdb1:

sudo blkid

Note the UUID it prints for /dev/sdb1, then:

sudo mkdir -p /mnt/project-data
sudo nano /etc/fstab

Add a line at the end, using the UUID you just noted:

UUID=4a2b1c3d-5e6f-7890-abcd-ef1234567890  /mnt/project-data  ext4  defaults  0  2

Save and exit, then test immediately:

sudo mount -a
lsblk -f

If /mnt/project-data shows up correctly mounted with no errors from mount -a, the entry is safe — it’ll now mount automatically on every future boot without you needing to do anything by hand again.

What’s Next

You can now format, mount, and permanently register storage with the system. Everything so far has assumed a straightforward, single-partition-to-single-filesystem relationship. The next two files introduce a more flexible layer that sits between partitions and filesystems entirely — Logical Volume Management, starting with why it exists before touching any of its commands.