Learn › Linux Foundations › Important Files and Paths
cat - a hands-on Linux lab on a real virtual machine.
Read the filesystem table that mounts every disk at boot. The comment header, the six whitespace-separated fields on each entry (file system, mount point, type, options, dump, pass), why UUIDs beat device names, and the mount -a habit that keeps a bad line from breaking a boot. fstab is structure-only: your UUIDs and device names vary, so the drills teach the shape and how to read it.
Every time a Linux machine powers on, something has to decide which disks get attached, and where. Your main drive has to land at /. A second disk has to know it belongs at /home. Swap space has to be switched on. Nobody types those commands by hand at every boot. A single file does it, automatically, for you.
That file is /etc/fstab. It is a plain text table, and each line is one standing instruction: mount THIS disk, at THIS place, THIS way, every single time we boot. Learn to read it and you can look at any Linux machine and know, at a glance, exactly which storage it uses and where each piece attaches.
The black boxes in this lesson are a practice terminal: a safe sandbox that only checks the one command each step teaches, so you cannot break anything. /etc/fstab describes YOUR machine's real disks, so its UUIDs, device names, and rows change from machine to machine. The file shown here is one representative example. On the live machine at the end of the module, you read your own /etc/fstab and see your own disks.
The name fstab is short for filesystem table. A filesystem is one formatted storage area the machine can read and write, like your main drive or a plugged-in disk. A mount is the act of attaching that storage to a place in the directory tree so you can use it. /etc/fstab is the table that says which filesystems to mount, and where, at boot.
Think of it as the machine's standing move-in orders. Without it, a fresh boot would come up with only the bare root disk attached and nothing else in place. With it, every disk, partition, and swap area lands exactly where it belongs, hands-free, in the same spot every time.
Because it is just a text file, you read it with the tool you already know for reading text: cat, which prints a file to the screen. Read the boot-time mount table now:
cat /etc/fstab
prompt: student@linuxcamp:~$ answer: cat /etc/fstab output:
#
UUID=a1b2c3d4-5678-90ab-cdef-1234567890ab / ext4 defaults 0 1 UUID=99887766-5544-3322-1100-aabbccddeeff /home ext4 defaults 0 2 UUID=deadbeef-0000-1111-2222-333344445555 none swap sw 0 0 hint: Type cat, a space, then the full path: cat /etc/fstab
Two kinds of lines. The lines that start with # are comments: notes for humans that the machine ignores completely. Here they act as a header, labelling the columns so you can read the rows below. Every other line is a real entry, one filesystem the machine mounts at boot. This example has three entries: the root disk, a separate home disk, and swap. Your machine may have more rows or fewer, and its comment header may be worded differently, but the pattern, comments on top and one entry per disk below, is the same everywhere.
The UUIDs, device names, mount points, and row count above belong to the example machine. Your own /etc/fstab will read differently: different UUIDs, maybe a /dev/vda1 style name, maybe just a single root line. That is expected. What never changes is the SHAPE, six fields per entry, and that shape is the whole lesson.
Every real entry in /etc/fstab is the same six pieces of information, separated by spaces or tabs, always in this order. Learn them once and you can read any machine's mount table:
That is the entire format. Six fields, always in that order, one entry per line. The rest of this lesson walks each field on a single real line so the shape sticks.
The first field says WHICH disk. You will almost always see it written as UUID= followed by a long string, like UUID=a1b2c3d4-.... A UUID (Universally Unique Identifier) is a permanent name burned into the filesystem when it is created. It never changes, no matter where the disk is plugged in.
You could instead name the disk by its device path, like /dev/sda1, and older systems did. The problem: device names are assigned in the order the machine happens to find disks at boot. Plug in a USB drive, and yesterday's /dev/sda might come up as /dev/sdb today. Point /etc/fstab at /dev/sda1 and the wrong disk, or no disk, mounts at /. A UUID= follows the actual filesystem around, so it always finds the right one. That is why every modern install uses UUIDs.
When you see a long UUID=a1b2c3d4-5678-... string in the first field, do not try to memorise or type it. It is just a fixed name. The lesson is knowing WHAT it is (a permanent disk label) and WHY it beats /dev/sda1 (device names can shuffle at boot).
Read the root entry from the example, field by field, and the second and third columns explain themselves.
UUID=a1b2c3d4-... / ext4 defaults 0 1
Field 2 is the mount point, the place in the tree where this disk attaches. Here it is /, the root of everything, so this is the main system disk. On the home entry it was /home. Swap is the special case: swap is not a place you browse into, so its mount point is the literal word none.
Field 3 is the type, the format the filesystem was made with. ext4 is the common Linux default. You may also meet xfs (another Linux format), vfat (used on USB sticks and boot partitions so Windows can read them), and swap (not a browsable filesystem at all, but reserve space the machine uses as overflow memory).
On your machine the mount points and types can differ. You might see only a / line and a swap line, or an xfs root instead of ext4, or a small vfat boot partition mounted at /boot/efi. All of that is normal variation. The rule that holds everywhere: field 2 is WHERE, field 3 is WHAT format, and swap uses none as its where.
The last three fields on the root line are defaults 0 1.
Field 4 is the options, a comma-joined list of HOW to mount. defaults is the sensible everyday set (read and write, allow programs to run, and so on). You might also see ro for read-only, noatime for a small speed gain, or sw on a swap line. Multiple options are joined by commas with no spaces, like defaults,noatime.
Field 5 is dump, a flag for a decades-old backup program almost nobody runs today. In practice it is 0 on virtually every line, meaning skip. Field 6 is the pass order: it tells the boot-time filesystem checker which disks to inspect and in what order. The rule is fixed and worth memorising: 1 for the root filesystem so it is checked first, 2 for other real disks so they are checked after, and 0 to skip the check entirely, which is what swap and memory-based filesystems use.
Do not overthink fields 5 and 6. In the wild you will see 0 for dump on nearly every line, and for pass you will see 1 on the root line, 2 on other data disks, and 0 on swap. Read them, do not sweat them.
Here is the real-world reason /etc/fstab exists. Say you plug a new data disk into a server and you want it to mount at /data at every boot, forever, without you being there. You add one line to /etc/fstab, six fields, describing that disk: its UUID=, the mount point /data, its type like ext4, defaults for options, and 0 2 for dump and pass. From the next boot on, the machine attaches it for you.
But there is a trap, and it is why engineers respect this file. /etc/fstab is read at boot. If you write a bad line, a wrong UUID, a typo in the type, a mount point that does not exist, the machine can fail to boot and drop you into a bare recovery prompt. You do not want to discover a typo by rebooting into a broken system.
The safe habit every engineer uses: after editing /etc/fstab, run mount -a BEFORE you reboot. mount -a tells the machine to mount everything in /etc/fstab right now, exactly as a boot would. If your new line is good, it mounts silently. If it is broken, mount -a prints the error while you are still safely logged in and can fix it. Test with mount -a first; never trust a fresh /etc/fstab line by rebooting blind.
Scaffolding off. No command is printed this time. You have every piece you need.
You have just logged in to an unfamiliar server and you want to know which disks it mounts at boot and where each one attaches. You know the file that holds that table, and you know it is plain text you can print to the screen.
prompt: student@linuxcamp:~$ answer: cat /etc/fstab output:
#
UUID=a1b2c3d4-5678-90ab-cdef-1234567890ab / ext4 defaults 0 1 UUID=99887766-5544-3322-1100-aabbccddeeff /home ext4 defaults 0 2 UUID=deadbeef-0000-1111-2222-333344445555 none swap sw 0 0 hint: The reading tool is cat, and the file lives at /etc/fstab. Put them together: cat /etc/fstab
That is the everyday move. cat printed the file, and now you can read the server's whole storage plan off those three entries: a root disk at /, a separate home disk at /home, and swap. Your own server's UUIDs, device names, and row count will differ, but the shape, a comment header then one six-field entry per disk, is what you will see on any machine, and the command is exactly what a working engineer types to inspect it.
You earned this cheat sheet. The command is simple; the value is knowing how to read what it prints.
When you meet a new machine and want to know its storage layout, cat /etc/fstab is the first command to type, and the six fields on each line are what you read.
/etc/fstab says what SHOULD mount at boot. To see what IS mounted right now, you use the mount and df commands (df comes later in the track). One is the plan; the other is the live state. When they disagree, that gap is often exactly the problem you are hunting.
The practice terminal has shown you the shape of /etc/fstab. You know it is the boot-time mount table, you can name all six fields on any line, you know why UUIDs beat device names, and you know the mount -a safety habit. You typed the reading command yourself.
The Important Files module ends with one real Linux machine, the Important Files capstone mission, and that is where you read a real /etc/fstab for yourself, alongside the other system files this module covered. A VM boots just for you, with its own disks and its own accounts. It hands you objectives that use exactly what you practiced: reading /etc/passwd, /etc/hosts, /etc/os-release, and this filesystem table. One difference from here: the mission shows no commands. You read the objective, you recall the command, you type it. That recall is what makes it stick.
Finish the other Important Files lessons, then go read a real machine's disks for yourself.
Practice /etc/fstab in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.