File Systems: Create, Mount, fstab, NFS, autofs, and Swap

A fresh disk or partition is just a featureless slab of blocks — the kernel can read and write bytes to it, but there are no files, no directories, no notion of "this region belongs to that file." A filesystem is the bookkeeping layer that turns those raw blocks into named files and folders.

Think of a brand-new disk as an empty warehouse: lots of square footage, but no shelving, no aisle labels, no inventory list. Running mkfs installs the shelving and the labelling scheme. Mounting then connects that organized warehouse to a door in your building — a directory like /data — so you can walk in and use it.

Three verbs carry this entire topic:

• make a filesystem on a device (mkfs.xfs, mkfs.ext4)
• mount it onto a directory so processes can use it
• persist that mount in /etc/fstab so it returns automatically at every boot

On RHEL the default filesystem is XFS; ext4 is the other one you must know. Both are journaling filesystems and either is acceptable unless the task names one. Formatting is destructive — mkfs lays down fresh metadata over whatever was there, so be certain of the device name before you run it.

Every filesystem gets a UUID (Universally Unique Identifier) baked into it at creation. This is the stable name you will mount by. Read it back with blkid:

/etc/fstab is the table the system reads at boot to decide what to mount where. Each line has six fields:

<what> <where> <type> <options> <dump> <fsck-pass>

First create the mount point and add the line. Mount by UUID, not by /dev/sdb1.

Now add the entry. The line you append looks like this (one line, fields separated by whitespace):

UUID=a1b2c3d4-5e6f-7081-92a3-b4c5d6e7f809 /data xfs defaults 0 0

Field by field: the UUID is what to mount; /data is where; xfs is the filesystem type; defaults is a sensible option bundle (read-write, auto-mount at boot, and more); the first 0 disables the legacy dump backup tool; the final 0 sets the boot-time fsck pass (0 = don't check — correct for XFS, which checks itself; data partitions on ext4 typically use 2).

Never trust a freshly edited /etc/fstab until you've tested it on the running system, where a mistake is a harmless error message instead of a failed boot. mount -a mounts everything in fstab that isn't already mounted — so it exercises your new line immediately.

Then confirm the mount actually landed where you expect. findmnt reads the live mount table; its --verify mode parses fstab and reports problems without mounting anything.

So far every fstab line in this lesson has used defaults in the fourth field — the options field — and _netdev for network mounts. That field is where a filesystem's behaviour is actually decided, and on any mount that holds user-supplied data it is a security control, not a formality.

defaults is shorthand for rw,suid,dev,exec,auto,nouser,async. Read that list again: it says the filesystem may contain executables, honour set-UID bits, and carry device nodes. For / that is correct. For an uploads or scratch volume that anyone can write to, all three are attack surface — and turning them off costs nothing.

You add them by appending to the existing options field, comma-separated with no spaces — never by replacing it, or you silently drop whatever was there:

LABEL=uploads /srv/uploads ext4 defaults,noexec,nosuid,nodev 0 2

A normal fstab mount is attached for the whole uptime of the machine, whether anyone uses it or not. autofs instead mounts a path the instant something touches it and unmounts it after a period of inactivity. The classic use case is NFS home directories: a server may export hundreds of users' homes, but any one machine should only mount the homes of people actually logged in.

The analogy is a motion-sensor light: the corridor stays dark (unmounted) until you walk into it, then switches on (mounts), and turns itself off again once you leave (idle unmount). You don't flip a switch; access is the switch.

autofs is driven by two files. The master map /etc/auto.master says "for this directory, use that map file." The map file it points to spells out the individual mounts. Install the package, then wire up the two maps.

Add one line to the master map /etc/auto.master:

/mnt/home /etc/auto.home

This means "manage mounts under /mnt/home using the rules in /etc/auto.home." Then create that map file /etc/auto.home with the mount rule:

* -rw 192.0.2.50:/exports/home/&

The * is a wildcard key and & substitutes it back: accessing /mnt/home/alice triggers a mount of 192.0.2.50:/exports/home/alice. The -rw field carries the mount options.

NFS lets a client mount a directory that physically lives on another server, so the share looks like a local folder. From the client side you only need the nfs-utils package and the right fstab line; the server's exports are someone else's job. The wrinkle is timing: a network share can't mount until the network is up, and at early boot it usually isn't.

The persistent fstab line for an NFS mount of /exports/data from server 192.0.2.50 onto /mnt/data:

192.0.2.50:/exports/data /mnt/data nfs _netdev 0 0

The what field is server:/export-path rather than a UUID (a remote share has no local UUID). The type is nfs. The key option is `_netdev`.

Swap is disk space the kernel uses as overflow when RAM fills — inactive memory pages get parked on disk to free real memory for active work. It's not a faster substitute for RAM; it's a pressure-relief valve that keeps the system from killing processes when memory runs short.

Swap has its own format, so you don't run mkfs — you run mkswap. Then swapon activates it for the running system, exactly the way mount attaches a filesystem.

Now make it persistent. The fstab line for swap uses the literal mount point `swap` and the type `swap`:

UUID=7f8e9d0c-1b2a-3948-5746-8392a1b0c9d8 none swap defaults 0 0

Swap has no directory, so the where field is none (the activation target is swap itself); the type field is swap. After adding it, run sudo swapon -a to test the swap lines in fstab — the swap-specific cousin of mount -a.

After a crash or an unclean power-off you check a filesystem for damage. fsck is only a front-end: it looks up the filesystem's TYPE (the same field blkid prints, or the type column in fstab) and hands the job to a type-specific checker named fsck.<type>. For ext2/3/4 that is fsck.ext4, another name for e2fsck. For XFS it is fsck.xfs, which, as you'll see, deliberately does almost nothing. So the first question before any check is always what type is it?

You can practise without a spare disk: a filesystem can live inside an ordinary file. Make one of each type and read their types back:

You have a real root shell to the right. Every command below is read-only — it inspects existing state and changes nothing. This is the verification half of the workflow you'd run after configuring storage: never reboot until these look right.