fstab explained with examples: 12 Linux entries 2026

/etc/fstab is a plain-text file that tells Linux which filesystems to mount automatically at boot, where to mount them, and with which options. Every non-comment line has six space-separated fields, and this guide walks through each one with working lines you can copy. If you have ever added a drive, lost a machine to emergency mode after a bad edit, or just wanted to know what the numbers at the end of a line mean, you are in the right place.

A mount made by hand with the mount command disappears on reboot. An entry in /etc/fstab is permanent, and on a systemd system it becomes a real mount unit that gets mounted, checked and reported on like everything else. The catch is that the file is parsed very early in boot, which is why a single wrong line can stop your machine dead.

Here is fstab explained with examples, in the order you actually need them: what the file is, what the six fields mean, which options matter, twelve real entries covering the situations most people run into, and how to test and repair an entry without guessing.

Table of Contents

• What Is fstab and Why Does Linux Need It?
• fstab Syntax: The Six Fields Explained
• Essential fstab Options and Their Effects
• fstab Explained with Examples for Everyday Scenarios
• One fstab explained with examples file, annotated
• How to Use UUIDs and Filesystem Labels Safely
• How to Create a Mount Point and Set Permissions
• How to Test and Reload fstab Without Rebooting
• fstab Troubleshooting: Fixing Filesystem and Permission Problems
• Frequently Asked Questions
• What is the difference between /etc/fstab and the mount command?
• Should I use UUID or /dev/sda in fstab?
• How do I find the UUID of a filesystem?
• What does nofail mean in an fstab entry?
• Can I edit fstab and apply changes without rebooting?
• How do I mount a network share in fstab?
• Start With a Backup and mount -a

What Is fstab and Why Does Linux Need It?

The name is a contraction of filesystem table, and that is exactly what the file is: a table, one row per filesystem, describing how each one should be attached to the filesystem tree. It normally lives at /etc/fstab and is owned by root with permissions 644. Any line starting with # is a comment, and blank lines are ignored, which is how you park a line you are not sure about instead of deleting it.

Three things happen at boot. The init system reads the file, mounts every entry marked for automatic mounting, and runs a filesystem consistency check on entries whose pass number is not zero. On systemd distributions, each fstab line is turned into a systemd.mount unit named after its mount point, so /srv/data becomes srv-data.mount under /etc/systemd/system/. Entries carrying _netdev or x-systemd.automount are handled differently, and get tied to the network and automount targets.

Two concepts get confused early, so it is worth separating them. A temporary mount happens when you run mount /dev/sdb1 /mnt/data yourself: it lasts until reboot or until you unmount it. A permanent mount is an entry in fstab that the system applies for you at every boot, and that is the only kind that survives a power cycle.

You can also mount something without putting it in fstab at all. A udisks2 or udisksctl mount, a GNOME Disks action, or a Docker volume mount all work without touching the file, and on a desktop those are usually the better choice for USB sticks you plug in occasionally.

One more thing worth knowing: fstab is not a historical relic that systemd threw away. Entries still drive every automatic mount on a modern system, they are simply translated into units and managed by systemctl instead of an init script. That translation is also why systemctl daemon-reload is the right command after an edit.

fstab Syntax: The Six Fields Explained

Every valid line has exactly six fields, separated by spaces or tabs, in a fixed order. Here is a real entry with each field labeled underneath:

UUID=6a3c1f9e-2b77-4d1a-9f30-8c5e21b4d7aa  /srv/data  ext4  defaults,noatime,nofail,x-systemd.device-timeout=30  0  2
 _________________________________/    _______/  ___/  _____________________________________________/  ^  ^
   field 1: filesystem spec              field 2    field 3            field 4: options            5  6
                                                                    dump          fsck pass number

Field	What it holds	Example values	Notes
1. Filesystem spec	The block device, or how to find it	UUID=…, LABEL=data, PARTUUID=…, /dev/sdb1, //server/share	Use UUID= in almost every case
2. Mount point	Existing directory where the filesystem appears	/, /home, /srv/data, none	The directory must already exist; none for swap
3. Filesystem type	Driver the kernel should use	ext4, xfs, btrfs, vfat, ntfs3, tmpfs, nfs4, cifs, swap	Must match how the filesystem was formatted
4. Options	Comma-separated mount behaviour	defaults, noatime, nofail, user, ro	The longest field; defaults alone is valid
5. Dump	Whether the old dump backup utility touches this filesystem	0 or 1	Leave at 0 on any modern system
6. Pass number	Order in which fsck checks filesystems	0, 1, 2	Root is 1, everything else checked is 2, 0 skips checking

Fields five and six are the ones people skip, then wonder about. dump is a leftover from dump, a backup tool nobody uses any more, and on a system that relies on snapshots or filesystem-level backup you leave it at 0. The pass number is the fsck order: 1 for your root filesystem, 2 for other checked filesystems, and 0 for anything you do not want checked, which covers swap, network mounts, and virtual filesystems like proc.

The pass-number table answers the question that comes up constantly in forums:

Filesystem	Dump	Pass	Reasoning
Root /	0	1	Checked first because other filesystems may need it clean
/home, /var, /srv/data	0	2	Checked after root, in the order lines appear
Swap	0	0	Nothing to check on a swap area
EFI system partition (vfat)	0	0	Filesystem drivers here are minimal by design
NFS, CIFS, tmpfs, proc	0	0	Not a local block filesystem, nothing for fsck to do

Two formatting rules catch people out. A # starts a comment, and a space inside a mount point or label must be written as 40, because the fields are split on whitespace. The exception to whitespace-as-separator is an exec option written in the older defaults order, but the single-line, six-field form is what every current system expects.

One field-1 detail is easy to miss: UUID= identifies the filesystem, while PARTUUID= identifies the partition table entry and refers to a whole disk. If you reformat a filesystem and keep the same partition, the PARTUUID stays the same and the UUID changes, which is why PARTUUID is a reasonable choice for an ESP but a poor one for a data disk you intend to reformat.

Essential fstab Options and Their Effects

Options are the field where most real-world mistakes live, because every option changes how the kernel handles the filesystem. The word defaults is not a mystery, it expands to rw,suid,dev,exec,auto,users,async, and you can see that full list with man 5 fstab, the page every serious reference points back to.

Option	What it does	When you want it
defaults	Expands to rw,suid,dev,exec,auto,users,async	Starting point for almost every entry
noatime	Stops the kernel updating access times on reads	Data disks, build caches, anything with heavy read traffic
relatime	Updates access time only when older than mtime or a day old	A gentler default on a root filesystem
nofail	Continue booting if this filesystem is missing	External drives, secondary disks, anything optional
noauto	Never mount at boot, only when asked	Disks you attach rarely, or mounts a service creates
ro / rw	Mount read-only or read-write	ro for recovery media and backup snapshots
noexec	Blocks executing binaries from the filesystem	Shared user data, untrusted removable media
nosuid / nodev	Ignore set-user-ID bits and device files	Hardening a filesystem holding untrusted files
user / users	Non-root users may mount and unmount it	USB sticks, so you can mount without sudo
uid= gid= umask=	Force an owner or permission mask on mount	FAT, NTFS and CIFS, which have no Unix permissions
x-systemd.automount	Mount on first access rather than at boot	Large network or slow disks you rarely touch
x-systemd.device-timeout=	Seconds to wait for the device before giving up	Always pair it with nofail on a flaky drive
_netdev	Marks the entry as needing the network first	Required for NFS and CIFS, harmless elsewhere
x-gvfs-show	Lists the mount in the desktop file manager sidebar	GUI users who want the drive visible in Files or Dolphin

nofail deserves its own warning because it is the most repeated fix in Linux forums. It says do not block the boot if the device is missing, which is exactly right for a drive that might be unplugged. The trap is what happens on the other side: if the drive is absent, the mount point directory still exists, and it now sits on your root filesystem, writable. Anything you save to that path during the gap goes to the root disk instead of nowhere. People have filled up a system partition this way. The fix is to accept that a missing mount is silent, and check with findmnt rather than assuming the path is live.

Users of r/linuxquestions described exactly that trap: adding nofail made the machine boot again, but the /mnt/disk1 folder became writable on the root filesystem, so writes had nowhere to go. The habit that prevents it is simple: after any reboot where a drive might have been missing, run findmnt /mnt/disk1 and confirm the source is the disk you expected.

noauto and nofail are often confused. noauto means never mount this at boot. nofail means do mount it at boot, but carry on if it fails. If you want a USB drive that appears only when you plug it in, noauto plus the user option is the pairing you want.

fstab Explained with Examples for Everyday Scenarios

Below are twelve entries that cover almost every real machine. Copy the one that matches your setup, then change the UUID and mount point. The numbered list gives the context each line needs, because the same filesystem behaves very differently in different roles.

1. Root filesystem. Required on every Linux system, and the one line never to guess at. The pass number is 1 because fsck checks it first.
2. EFI system partition. A small FAT32 volume the firmware reads. Filesystem type is vfat and the pass number is 0, because the drivers built into firmware do not support a full fsck pass.
3. Separate /home. Keeps user data on its own filesystem so a root filesystem problem does not take your files with it. Pass 2.
4. Internal data disk. The classic server case, mounted at /srv/data with noatime for read-heavy workloads.
5. Swap partition or swap file. Mount point is none, the type is swap, and both numbers are zero.
6. NTFS partition from a dual-boot Windows install. Type is ntfs3 on current kernels, or ntfs-3g where the FUSE driver is in use, with uid= and gid= because NTFS has no Unix ownership.
7. tmpfs RAM disk. A directory that lives in memory, gone on reboot. Nothing to check, so all zeros.
8. Samba share over CIFS. Needs _netdev so the network comes up first, and credentials read from a file rather than typed into fstab.
9. NFS export. nfs4 is the modern type, and _netdev is not optional here.
10. External USB drive. This is the nofail plus x-systemd.automount plus device-timeout combination, and the line most likely to save a machine from an unbootable state.
11. Backup disk mounted read-only. A deliberate mistake, but a good one: ro means a stray script cannot write to the backup.
12. LUKS-encrypted volume. Once the device is opened by systemd-cryptsetup via /etc/crypttab, it appears as a normal filesystem and takes an ordinary entry, plus a timeout because the passphrase prompt can stall boot.

# 1. Root filesystem
UUID=11111111-2222-3333-4444-555555555555  /            ext4  errors=remount-ro  0  1

# 2. EFI system partition
UUID=AAAA-BBBB                          /boot/efi       vfat  umask=0077      0  0

# 3. Separate home
UUID=66666666-7777-8888-9999-000000000000  /home        ext4  defaults,noatime  0  2

# 4. Internal data disk
UUID=2f1a1f9e-2b77-4d1a-9f30-8c5e21b4d7aa  /srv/data    ext4  defaults,noatime  0  2

# 5. Swap
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee  none         swap  sw              0  0

# 6. NTFS volume from a dual-boot Windows install
UUID=1A2B3C4D5E6F7A8B  /mnt/windows  ntfs3  uid=1000,gid=1000,windows_names,nofail  0  0

# 7. RAM disk
tmpfs  /run/cache  tmpfs  size=512M,mode=1777  0  0

# 8. Samba share
//fileserver/projects  /mnt/projects  cifs  credentials=/etc/samba/creds,_netdev,vers=3.0,uid=1000,gid=1000,iocharset=utf8,uidgid  0  0

# 9. NFS export
192.168.1.50:/srv/media  /mnt/media  nfs4  ro,_netdev,vers=4.2  0  0

# 10. External USB drive
UUID=9e8d7c6b-5a49-4382-9170-6f5e4d3c2b1a  /mnt/backup  ext4  defaults,nofail,x-systemd.device-timeout=30,x-systemd.automount,x-gvfs-show  0  2

# 11. Backup disk, read-only on purpose
UUID=0c1d2e3f-4a5b-4c6d-8e9f-a0b1c2d3e4f5  /mnt/archives  ext4  ro,nofail,x-systemd.device-timeout=10  0  2

# 12. LUKS-encrypted volume opened via /etc/crypttab
UUID=7f6e5d4c-3b2a-4190-8877-665544332211  /mnt/secure  ext4  defaults,noatime,nofail,x-systemd.device-timeout=30  0  2

One fstab explained with examples file, annotated

Here is the same idea as a single annotated file, which is the shape most desktops actually ship with. The comments on the right are the explanation; in a real file they sit on their own lines or at the end of an entry.

# <file system spec>            <mount point>   <type>  <options>                    <dump>  <pass>
UUID=11111111-2222-3333-4444-555555555555  /              ext4    errors=remount-ro           0       1      # root
UUID=AAAA-BBBB                            /boot/efi      vfat    umask=0077                  0       0      # ESP
UUID=66666666-7777-8888-9999-000000000000  /home          ext4    defaults,noatime            0       2      # home
UUID=2f1a1f9e-2b77-4d1a-9f30-8c5e21b4d7aa  /srv/data      xfs     defaults,noatime            0       2      # data
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee  none           swap    sw                          0       0      # swap
UUID=1A2B3C4D5E6F7A8B                      /mnt/windows   ntfs3   uid=1000,gid=1000,nofail    0       0      # Windows
UUID=9e8d7c6b-5a49-4382-9170-6f5e4d3c2b1a  /mnt/backup    ext4    defaults,nofail,x-systemd.device-timeout=30,x-systemd.automount  0  2  # USB

That is seven lines and covers most desktop and small server installs. Swap in your own UUIDs from blkid and nothing else needs to change. Note that x-systemd.automount on the last line means the backup disk is not touched during boot at all, it is mounted the first time something opens /mnt/backup, and the drive can be completely unplugged in the meantime.

How to Use UUIDs and Filesystem Labels Safely

Use UUIDs, because /dev/sda and /dev/sdb are assigned by discovery order and they change. On a laptop with two NVMe drives and an M.2 slot, adding a new SSD can renumber everything, and an entry that used /dev/sdb1 for your data disk will now point at the wrong device or at nothing. Forum threads on this are full of people whose external drive stopped being found after an unrelated hardware change.

Three commands give you what you need. lsblk -f shows a tree of block devices with their filesystem types, labels and UUIDs, which is the fastest way to identify a drive visually. blkid prints a compact list of UUID, type, label and mount point for every block device, and it is the command to quote in an fstab entry. findmnt answers a different question: what is mounted right now, and where.

$ lsblk -f
NAME   FSTYPE LABEL    UUID                                  FSTAB
sda
├─sda1 vfat   EFI      A1B2-C3D4                             /boot/efi
└─sda2 ext4   rootfs   11111111-2222-3333-4444-555555555555 /
sdb
└─sdb1 ext4   data     2f1a1f9e-2b77-4d1a-9f30-8c5e21b4d7aa /srv/data

$ blkid /dev/sdb1
/dev/sdb1: UUID="2f1a1f9e-2b77-4d1a-9f30-8c5e21b4d7aa" TYPE="ext4" PARTUUID="8c4b2a19-77de-4f31-b0a5-1c2d3e4f5a6b"

Labels are the readable alternative. LABEL=data stays valid across a reformat of the same partition, which is why people use it for removable drives they reuse for backup media. Set or change one with e2label /dev/sdb1 data on ext filesystems, or xfs_admin -L data /dev/sdb1 on XFS, and read it back with blkid. Keep it short and without spaces, or escape them as 40.

The decision in one line: UUID= for most filesystems, PARTUUID= for the ESP and other boot-critical volumes, LABEL= for removable media you reformat often, and /dev/sdX only when you fully control the hardware and know the enumeration cannot change.

How to Create a Mount Point and Set Permissions

A mount point is just a directory, and it has to exist before the filesystem is mounted there. If it does not exist, the mount fails with a plain mount: mount point /srv/data does not exist, which is a much friendlier failure than the alternative people hit, where a mistyped path silently creates a directory that then swallows files meant for the disk.

sudo mkdir -p /srv/data
sudo chown $USER:$USER /srv/data      # takes effect once the filesystem is mounted
sudo chmod 755 /srv/data

The ownership command looks redundant and is not. The chown runs on the mount point directory itself, which lives on the root filesystem, and once the new filesystem is mounted on top of it that ownership is hidden. The fix that people actually need is to set ownership on the mounted filesystem: mount first, then run chown, and every file on it changes at once.

sudo mount /dev/sdb1 /srv/data
sudo chown $USER:$USER /srv/data

This is the single most common real-world complaint after adding a drive: the mount succeeds, ls shows the right size, and writing anything returns Permission denied. A freshly formatted ext4 volume is owned by root, and no amount of changing your entry fixes it until the ownership is corrected on the mounted filesystem.

For filesystems with no Unix permissions, ownership comes from the mount options instead. uid=1000,gid=1000 forces your user onto every file on a FAT, NTFS or CIFS mount, and umask=0022 sets the permissions mask applied to new files. The uidgid option on CIFS entries is shorthand for the pair, and file_mode= or dir_mode= set the actual permission bits on a share. Pick these by looking up your own numeric IDs with id rather than assuming 1000 is right on every machine.

How to Test and Reload fstab Without Rebooting

Never reboot to find out whether your edit works. The whole verification loop takes seconds, and this is the workflow that keeps a typo from becoming downtime.

# 1. Back up first
sudo cp -a /etc/fstab /etc/fstab.bak

# 2. Check for syntax problems without mounting anything
sudo findmnt --verify

# 3. Mount everything in the file that is not already mounted
sudo mount -a

# 4. Confirm what actually landed
findmnt -t ext4,xfs,vfat,nfs4,cifs
findmnt /srv/data

findmnt --verify is the one to run first. It parses the file and reports unreachable mount points, bad option combinations and stray characters, and it changes nothing on disk. mount -a then attempts every remaining entry and prints an error for the ones that fail, which is where a wrong filesystem type or a bad UUID shows itself.

After an edit on a running systemd system, tell the init system to reread the configuration:

sudo systemctl daemon-reload
sudo systemctl restart remote-fs.target
sudo mount /srv/data        # or: systemctl start srv-data.mount
sudo umount /srv/data        # or: systemctl stop srv-data.mount

Here is a specific gotcha, and it is standard advice that almost no reference page mentions. Without daemon-reload, a systemd system can carry on using the unit definitions it generated at the last boot, so your edit appears to be ignored even though the file is correct. The generated unit for /srv/data is srv-data.mount, which is also how you inspect its state: systemctl status srv-data.mount. Entries with _netdev or x-systemd.automount are handled by remote-fs.target and the remote-fs-pre.target ordering, so restarting remote-fs.target is what pulls network shares back in.

Undo an experiment with umount /srv/data or, if something is holding the mount busy, fuser -vm /srv/data to find the process. And if an edit goes badly, sudo cp /etc/fstab.bak /etc/fstab puts it back instantly. People on r/Bazzite described clobbering a whole fstab with a command they thought appended a line, which is exactly why a copy on disk is worth the three seconds.

fstab Troubleshooting: Fixing Filesystem and Permission Problems

Most fstab problems fall into five buckets, and the error message usually names the bucket for you. Start by reading the message carefully, then confirm with dmesg | tail, which reports what the kernel itself said.

What you see	Cause	Fix
mount: /srv/data: bad option 'defalts'	Typo in the options field	Correct the spelling; the same line usually also triggers a boot delay
wrong fs type, bad option, bad superblock	Filesystem type does not match how the device was formatted	Check lsblk -f /dev/sdb1 and use the type it reports, for example ntfs3 rather than ntfs
special device /dev/sdb1 does not exist	Device name changed, or the drive is not present	Replace with UUID= from blkid; add nofail if the drive is optional
mount point /srv/data does not exist	Directory never created	sudo mkdir -p /srv/data
Machine hangs at boot then drops to emergency mode	System waiting on a missing or slow device	Add nofail and x-systemd.device-timeout=10 to that entry
Drive mounts but every write fails	Root-owned filesystem, or a read-only remount after an error	Mount, then chown; check mount | grep /srv/data for ro
Files appear on the root disk instead of the new drive	nofail mount did not happen, mount point is writable on root	Check findmnt /mnt/disk1 before writing anything there

If the machine already drops into emergency mode, the fix takes under a minute. Log in with the root password, remount the root filesystem read-write, comment out the offending line with #, and reboot. On a live environment, mount -o remount,rw / is the command; some emergency prompts mount it for you, so check with mount | grep ' / ' first.

mount -o remount,rw /
nano /etc/fstab          # add # at the start of the bad line
systemctl reboot

If the machine will not boot far enough to give you a prompt, the same repair works from a live USB or ISO. Boot the installer environment, choose Try rather than Install, and open a terminal. From there you can inspect the broken entries with sudo blkid and findmnt --verify, and edit the file on the installed system directly:

sudo mount /dev/sdb2 /mnt
sudo nano /mnt/etc/fstab
sudo umount /mnt
sudo reboot

One more symptom deserves a mention because it looks like a hardware failure and is not: a filesystem that mounted ro and stayed that way. The usual cause is an unclean shutdown, and the fix is almost always the same: unmount, then run sudo fsck -y /dev/sdb1 while the filesystem is not mounted, and mount it again. Setting errors=remount-ro on the root line, as in the example file above, makes the kernel do this automatically on the next boot. A filesystem is never repaired while it is mounted, which is the rule people break when they panic and run fsck on a live volume.

Frequently Asked Questions

Start With a Backup and mount -a

If you only remember three things from this fstab explained with examples guide, make them these: copy /etc/fstab to /etc/fstab.bak before you touch it, identify every device with UUID= instead of /dev/sdX, and run findmnt --verify followed by mount -a before you reboot.

Add nofail to anything that might not be connected at boot, and remember to check with findmnt afterwards so you know whether the data you just wrote actually landed on the drive. Everything else in the file is a variation on those habits.