Fstab under Linux: adding an automatic mount without blocking boot
Débutant5 min de lecture
À retenirLinux n'est pas réservé aux experts. Le bon point de départ : une distribution accessible, une sauvegarde propre et quelques commandes comprises.
To modify /etc/fstab can make a server much more convenient. A data disk, a dedicated partition, a network share, or a volume added to the VPS can be mounted automatically at startup, without manual commands after each reboot.
But it’s also the kind of file I never edit lightly. A bad line in fstab can severely slow down startup, launch a rescue mode, or leave you facing a console you didn’t intend to open. Nothing insurmountable, but you have to perform the checks in the right order.
In this article, we’ll see how to add an automatic mount under Linux with a UUIDsave the file, use nofail when relevant, then test with mount -a before restarting.
An fstab mount should be tested with mount -a before rebooting, especially on a remote server.
Before modifying fstab, identify the correct disk
The first mistake is to write an fstab line from a name like /dev/sdb1It might work, but the name could change depending on the order in which the disks are detected. For a permanent setup, I prefer to use the UUID.
Start by displaying the disks and file systems:
lsblk -f
You can also retrieve the UUIDs with:
sudo blkid
Identify three pieces of information: the UUID, the file system type, and the desired mount point. For example, a disk in ext4 that you want to ride in /mnt/data.
If your need is simply to mount a USB drive occasionally, the article on Commands to mount a USB drive under Linux will be more suitable. Here, we are talking about automatic assembly at startup.
Back up /etc/fstab before adding a line
Before opening the editor, make a copy of the current file. It’s quick, and it avoids having to make last-minute changes if an option is incorrectly written.
I recommend adding the new line at the bottom of the file, with a comment just above it. No need to write a novel, but in six months you’ll be glad you understand why this setup exists.
Add an auto-mount with UUID
An fstab line follows this logic:
For a volume ext4 Locally, you can start with a line like this:
# Data disk
UUID=11111111-2222-3333-4444-555555555555 /mnt/data ext4 defaults,nofail,x-systemd.device-timeout=10 0 2
Obviously replace the UUID with the one obtained with lsblk -f Or blkidDo not copy this example as is.
The last two fields are often misunderstood. The zero disables the old mechanism dump, very rarely used today. The two indicates that the file system can be checked after the root partition. For a primary system partition, one would typically find oneFor certain network setups or special volumes, we will often put zero.
The man page fstab(5) It details the exact structure of the file. It’s austere, but useful when you have a doubt about a field.
Options that prevent the startup from being blocked
The option defaults This is sufficient for many simple cases. It includes classic options such as read/write, execution allowed, interpreted device, and automatic mounting.
I often add nofail for a non-critical data disk, a USB drive connected only occasionally, or a volume that may be missing at startup. With nofailThe machine should not remain blocked simply because this secondary assembly is not available.
On distributions with systemd, the following option also limits the wait time:
x-systemd.device-timeout=10
This is convenient for an external drive or a volume that might respond slowly. For truly essential storage, I would be stricter: no nofail Automatic setup, clear monitoring, and restart testing during a scheduled window.
For network setups, especially NFS or SMB, do not blindly copy a line found elsewhere. The options vary depending on the protocol, authentication method, network, and when the connection becomes available at boot.
Test fstab without rebooting
After saving the file, do not restart immediately. First, test the syntax and the setup with:
sudo mount -a
If the command returns nothing, it’s not a guarantee, but it’s still a good sign. If it displays an error, correct the line now, while your system is still running.
Next, check that the mount is active:
findmnt /mnt/data
df -h /mnt/data
mount | grep '/mnt/data'
If systemd tells you that it still has an old view of the mount units, reload its configuration:
sudo systemctl daemon-reload
You can then restart sudo mount -a. The page mount(8) remains the reference for classic mounting options, and the documentation systemd.mount explains the options specific to systemd.
If the edit fails, read the error before correcting it.
An fstab error is often quite telling: bad UUID, incorrect file system type, missing mount point, unknown option, insufficient rights or missing package for a network protocol.
If you have broken the boot process, use the hosting provider’s recovery console, a recovery mode, or a live USB. Mount the root partition, open /etc/fstabComment on the added line with #, or restore the backup created at the beginning.
sudo cp /etc/fstab.bak-YYYY-MM-DD-HHMM /etc/fstab
On a remote server, do not perform the initial test reboot immediately before leaving. Maintain console access, or at the very least, verify that your hosting provider offers an easily accessible rescue mode.
My check before validating the automatic assembly
For a simple data disk, my sequence looks like this:
identify the disk with lsblk -f and confirm the UUID with blkid ;
to safeguard /etc/fstab before any modification;
create the mount point with a clear name;
add a line based on the UUID, not on /dev/sdX ;
throw sudo mount -a and correct all errors before rebooting;
check with findmnt, df -h and the logs;
Restart only when the assembly is clean.
Fstab isn’t complicated, but it doesn’t always forgive approximations. A short line, a reliable UUID, nofail when volume is secondary, then a real test with mount -a : this is generally what avoids unpleasant surprises on the next startup.
