Mounting Drives Permanently With /etc/fstab

3 Aug 2026

Connecting an additional drive to a Linux computer is usually straightforward. The operating system detects it, and many desktop environments mount it automatically when you click the drive in the file manager.

That works well for occasional use, but servers, backup disks, shared storage and application data usually need something more reliable. The drive must be mounted automatically every time the machine starts, using the same location and the correct permissions.

That is where /etc/fstab comes in.

The fstab file tells Linux which filesystems should be mounted, where they should appear and which options should be used. A correct entry can make storage management predictable. A mistake, however, can cause boot delays, mount failures or even leave a system in emergency mode.

This guide explains how to identify a drive, create a mount point, add it safely to fstab and test the configuration before rebooting.

What Is

/etc/fstab

The name fstab stands for filesystem table.

It is a plain-text configuration file located at:

/etc/fstab

Each non-comment line describes a filesystem that Linux may mount. A typical entry looks like this:

UUID=5d82c312-1e11-4ad5-9982-a42dcb6a3740 /mnt/data ext4 defaults 0 2

This tells Linux:

Which filesystem to mount
Where to mount it
Which filesystem type it uses
Which mount options to apply
Whether it should be included in legacy dump backups
In which order it should be checked during startup

The file may already contain entries for the root filesystem, swap space, EFI partition and other system volumes. Avoid changing those unless you understand exactly what they do.

Why Use

fstab

A permanent mount is useful when a drive contains:

Business files
Backups
Virtual machines
Databases
Docker data
Media libraries
Shared folders
Application uploads
Log archives
Network storage

Without a permanent mount, the drive may appear at a different path after rebooting, or it may not mount until someone logs in and opens it manually.

Applications expect their data to remain in a consistent location. A database configured to use /srv/database, for example, cannot work correctly if its disk is mounted somewhere else after a restart.

Before You Begin

Take care when editing fstab, particularly on remote servers.

A malformed line can interrupt the boot process. Before making changes:

Confirm that you have administrative access.
Keep a second SSH session open when working remotely.
Make sure you have access to a hosting console, hypervisor console or physical keyboard.
Back up the current fstab file.
Test the configuration before rebooting.

Create a backup with:

sudo cp /etc/fstab /etc/fstab.backup

You can restore it later with:

sudo cp /etc/fstab.backup /etc/fstab

Do not reboot until the new entry has been tested successfully.

Step 1: Identify the Drive

Start by listing the block devices attached to the system:

lsblk

A more useful version includes filesystem information:

lsblk -f

Example output:

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS

sda

├─sda1 vfat FAT32 A12B-C34D 500M 3% /boot/efi

└─sda2 ext4 1.0 5a8f4d0b-83af-4d2b-98c7-31fcbf104111 42G 38% /

sdb

└─sdb1 ext4 1.0 DATA 5d82c312-1e11-4ad5-9982-a42dcb6a3740 820G 12%

In this example:

sda is the system disk.
sdb is the additional drive.
sdb1 is the partition that will be mounted.
The filesystem type is ext4.
The filesystem UUID is shown in the UUID column.

You can also inspect the devices with:

sudo blkid

Example:

/dev/sdb1: LABEL="DATA" UUID="5d82c312-1e11-4ad5-9982-a42dcb6a3740" TYPE="ext4"

Take care to identify the correct partition. Formatting or changing the wrong device can destroy data.

Step 2: Use a UUID Instead of a Device Name

It is possible to add a drive to fstab using a device path such as:

/dev/sdb1

This is not always reliable.

Device names can change depending on:

The order in which drives are detected
Newly connected storage
Changes to virtual hardware
Controller configuration
USB devices
Kernel behaviour

A disk currently called /dev/sdb1 could later become /dev/sdc1.

A filesystem UUID is designed to provide a more stable identifier:

UUID=5d82c312-1e11-4ad5-9982-a42dcb6a3740

For most permanent disk mounts, UUIDs are preferable to /dev/sdX names.

You can also use filesystem labels, but labels must be unique if they are being used as identifiers.

Step 3: Create a Mount Point

A mount point is an ordinary empty directory where the contents of the drive will appear.

Common locations include:

/mnt/data

/srv/storage

/media/archive

/backup

For a general data disk, create a directory such as:

sudo mkdir -p /mnt/data

The -p option creates any missing parent directories and does not fail if the directory already exists.

Choose a clear, permanent path. Avoid mounting important application storage inside temporary directories.

Step 4: Mount the Drive Manually First

Before editing fstab, test the drive manually:

sudo mount /dev/sdb1 /mnt/data

Check that it mounted:

findmnt /mnt/data

You can also use:

df -hT /mnt/data

Example:

Filesystem Type Size Used Avail Use% Mounted on

/dev/sdb1 ext4 916G 108G 762G 13% /mnt/data

Confirm that the expected files are visible:

ls -la /mnt/data

If the manual mount fails, resolve that issue before adding anything to fstab.

Possible causes include:

The filesystem is damaged.
The wrong partition was selected.
Required filesystem tools are missing.
The volume is encrypted.
The drive is already mounted elsewhere.
The filesystem type was detected incorrectly.

When the test is complete, unmount it before continuing:

sudo umount /mnt/data

The command is umount, without the letter n.

Step 5: Understand the Six

fstab

Fields

Each standard fstab entry contains six fields:

device mount-point filesystem-type options dump fsck-order

Using this example:

UUID=5d82c312-1e11-4ad5-9982-a42dcb6a3740 /mnt/data ext4 defaults 0 2

The fields mean:

1. Device or filesystem identifier

UUID=5d82c312-1e11-4ad5-9982-a42dcb6a3740

This identifies the filesystem.

Other possibilities include:

/dev/sdb1

LABEL=DATA

PARTUUID=...

UUID is usually the safest option for a normal filesystem.

2. Mount point

/mnt/data

This is the directory where the filesystem will appear.

The directory should exist before the mount is attempted.

3. Filesystem type

ext4

Common values include:

ext4

xfs

btrfs

ntfs

exfat

vfat

nfs

cifs

swap

Use lsblk -f or blkid to confirm the correct type.

4. Mount options

defaults

This controls how the filesystem is mounted.

The defaults option is a convenient starting point for many local Linux filesystems. It generally enables normal read/write behaviour and standard mounting settings.

Options are comma-separated with no spaces:

defaults,noatime

5. Dump setting

This field relates to the older dump backup utility.

A value of 0 means the filesystem is not included. Most modern systems use 0.

6. Filesystem-check order

This controls the order in which filesystems may be checked during startup.

Typical values are:

0 — do not check automatically
1 — check first, normally reserved for the root filesystem
2 — check after the root filesystem

For an additional ext4 data drive, 2 is common.

Some filesystem types use their own repair mechanisms and may conventionally use 0.

Step 6: Add the Entry to

/etc/fstab

Open the file using a text editor:

sudo nano /etc/fstab

Add a comment describing the drive:

# Business data drive

UUID=5d82c312-1e11-4ad5-9982-a42dcb6a3740 /mnt/data ext4 defaults 0 2

Comments begin with # and are ignored by the system.

In Nano:

Press Ctrl+O to save.
Press Enter to confirm.
Press Ctrl+X to exit.

Avoid copying the example UUID literally. Use the UUID shown by your own system.

Step 7: Test the

fstab

Entry

This is the most important safety step.

Run:

sudo mount -a

The -a option tells Linux to mount all appropriate filesystems listed in fstab that are not already mounted.

If the command returns no output, that generally indicates success.

Now confirm the mount:

findmnt /mnt/data

You can also check:

df -hT /mnt/data

Review recent messages if a problem occurs:

sudo dmesg | tail -50

On a systemd-based distribution, also check:

sudo journalctl -xe

Do not reboot merely to find out whether the entry is correct. mount -a allows you to test it safely while the system is still running.

Validating

fstab

With

findmnt

Many systems provide a dedicated validation command:

sudo findmnt --verify

This can detect issues such as:

Invalid options
Missing mount points
Duplicate entries
Unrecognised filesystems
Incorrect field formatting

A successful verification does not guarantee that the physical drive will always be available, but it is an excellent check before rebooting.

Use both:

sudo findmnt --verify

sudo mount -a

Then confirm the result with:

findmnt

Example: Permanent ext4 Data Drive

A straightforward ext4 drive might use:

UUID=5d82c312-1e11-4ad5-9982-a42dcb6a3740 /mnt/data ext4 defaults 0 2

This is suitable for many internal data drives.

Example: XFS Drive

An XFS filesystem might use:

UUID=0e84db71-3df4-45e3-b166-2e688e7cf610 /srv/storage xfs defaults 0 0

The final field is commonly 0 for XFS because its filesystem-check process differs from ext-family filesystems.

Example: NTFS Drive

For an NTFS drive shared with Windows:

UUID=42A8C77AA8C76A51 /mnt/windows ntfs3 defaults,uid=1000,gid=1000,umask=022 0 0

The exact NTFS driver may depend on the distribution and kernel. Modern systems may use ntfs3, while some installations use ntfs-3g.

The options in this example give ownership to user and group ID 1000.

Check the current user’s numeric IDs with:

Example:

uid=1000(carl) gid=1000(carl) groups=1000(carl)

Do not assume that every system uses 1000.

Example: exFAT Drive

An exFAT volume could use:

UUID=7A1B-2C3D /mnt/shared exfat defaults,uid=1000,gid=1000,umask=022 0 0

This can be useful for removable storage shared between Linux, Windows and macOS.

Example: Read-Only Mount

To mount a filesystem read-only:

UUID=5d82c312-1e11-4ad5-9982-a42dcb6a3740 /mnt/archive ext4 ro 0 2

This can help protect archival data from accidental modification.

It does not provide complete security against a user with sufficient administrative privileges, but it can prevent routine writes.

Useful Mount Options

defaults

A standard group of conventional mount settings:

defaults

Suitable for many ordinary local filesystems.

noatime

Prevents the filesystem from updating a file’s access time every time it is read:

defaults,noatime

This can reduce unnecessary write activity, although modern Linux systems often already use less aggressive timestamp behaviour.

Mounts the filesystem read-only:

Mounts the filesystem read/write:

This is normally included by defaults.

nofail

Allows the system to continue booting if the filesystem is unavailable:

defaults,nofail

This can be useful for non-essential drives, removable disks or storage that might occasionally be disconnected.

Example:

UUID=5d82c312-1e11-4ad5-9982-a42dcb6a3740 /mnt/data ext4 defaults,nofail 0 2

Use this carefully. A system may boot successfully while an application silently starts without its expected data drive.

x-systemd.device-timeout=10s

Limits how long systemd waits for a device to appear:

defaults,nofail,x-systemd.device-timeout=10s

This can prevent long boot delays caused by a missing optional drive.

noexec

Prevents binaries on the mounted filesystem from being executed directly:

defaults,noexec

This may be useful for some upload, archive or shared-data volumes.

It can also break scripts, applications or software stored on that drive.

nosuid

Ignores set-user-ID and set-group-ID bits:

defaults,nosuid

This can reduce risk on data-only filesystems.

nodev

Prevents device files on the filesystem from being interpreted as actual devices:

defaults,nodev

For a data-only partition, a security-conscious entry might look like:

UUID=5d82c312-1e11-4ad5-9982-a42dcb6a3740 /mnt/data ext4 defaults,nodev,nosuid 0 2

Do not add restrictive options blindly. Applications may rely on behaviour that those options disable.

Automounting on First Access

Systemd can mount a filesystem only when something tries to access it.

Example:

UUID=5d82c312-1e11-4ad5-9982-a42dcb6a3740 /mnt/archive ext4 defaults,nofail,x-systemd.automount 0 2

This can reduce boot dependencies and work well for infrequently used storage.

The first access to the directory may be slightly delayed while the drive mounts.

Ownership and Permissions

Mounting a filesystem and setting permissions are related, but they are not always the same thing.

For Linux-native filesystems such as ext4 and XFS, ownership is stored inside the filesystem itself.

After mounting an ext4 drive, you might assign ownership with:

sudo chown -R username:groupname /mnt/data

For example:

sudo chown -R carl:carl /mnt/data

Be extremely careful with -R. It recursively changes every file and directory on the drive.

For an empty new filesystem, this may be appropriate:

sudo chown carl:carl /mnt/data

For NTFS, FAT and exFAT, Linux ownership is usually controlled through mount options such as:

uid=1000,gid=1000

These filesystems do not store normal Linux ownership and permission information in the same way as ext4.

The Hidden-Files Problem

Suppose /mnt/data already contains files on the root filesystem. When another drive is mounted over that directory, those original files become hidden behind the mounted filesystem.

They are not deleted, but they cannot be seen at that path until the drive is unmounted.

This can create a serious storage problem:

An application writes files into /mnt/data before the drive is mounted.
The drive later mounts over the directory.
The files seem to disappear.
The root filesystem continues consuming space unexpectedly.

Before mounting a new filesystem, inspect the mount point:

sudo ls -la /mnt/data

For a new mount point, it should normally be empty.

Moving Existing Data to a New Drive

When moving application data, do not simply mount the new empty disk over the existing directory. That would hide the original files.

A safer high-level process is:

Mount the new drive temporarily.
Stop the application.
Copy the existing data.
Preserve ownership and permissions.
Rename the original directory as a backup.
Create a fresh mount point.
Add the new drive to fstab.
Test the mount.
Start the application.
Remove the old copy only after verification.

For example:

sudo mkdir -p /mnt/newdisk

sudo mount /dev/sdb1 /mnt/newdisk

Stop the relevant service:

sudo systemctl stop example-service

Copy the data:

sudo rsync -aHAX /srv/application-data/ /mnt/newdisk/

Then verify the copied files before changing the mount arrangement.

Data migrations should be planned carefully, especially for databases, virtual machines and business-critical systems.

Handling Spaces in Mount Paths

Spaces cannot simply be written literally in all fstab fields.

For a path such as:

/mnt/Business Data

the space should be escaped as:

/mnt/Business\040Data

Example:

UUID=5d82c312-1e11-4ad5-9982-a42dcb6a3740 /mnt/Business\040Data ext4 defaults 0 2

It is usually simpler to avoid spaces in Linux mount-point names:

/mnt/business-data

Network Shares in

fstab

fstab can also mount network filesystems.

NFS example

192.168.1.20:/exports/shared /mnt/shared nfs defaults,_netdev,nofail 0 0

The _netdev option indicates that the mount depends on network connectivity.

SMB or CIFS example

//192.168.1.30/shared /mnt/shared cifs credentials=/root/.smbcredentials,_netdev,nofail,uid=1000,gid=1000 0 0

A credentials file might contain:

username=exampleuser

password=examplepassword

domain=EXAMPLE

Restrict its permissions:

sudo chmod 600 /root/.smbcredentials

Avoid placing plain-text passwords directly inside /etc/fstab, because the file is normally readable by local users.

Network mounts introduce additional issues such as DNS, network availability, credentials and server timeouts. They should be tested carefully.

What Happens When a Drive Is Missing?

Without suitable options, Linux may wait for the missing device during boot or enter an emergency state.

For a non-critical drive, consider:

defaults,nofail,x-systemd.device-timeout=10s

For critical storage, nofail may be inappropriate. If a database disk is missing, it may be safer for the system or application to fail clearly rather than continue with an empty directory.

The right behaviour depends on the purpose of the drive.

Troubleshooting

fstab

Problems

“Mount point does not exist”

Create the directory:

sudo mkdir -p /mnt/data

Then retry:

sudo mount -a

“Wrong fs type”

Confirm the filesystem:

lsblk -f

sudo blkid

Make sure the fstab filesystem field matches.

“Special device UUID=… does not exist”

The UUID may be mistyped, or the drive may not be connected.

Check:

sudo blkid

Copy the UUID carefully.

Permission denied after mounting

Inspect ownership and permissions:

ls -ld /mnt/data

ls -la /mnt/data

For ext4 or XFS, use chown and chmod as appropriate.

For NTFS, exFAT or FAT, adjust uid, gid, umask, fmask or dmask in the mount options.

Drive mounts manually but not at boot

Check the system log:

sudo journalctl -b

Look specifically for mount failures:

sudo journalctl -b | grep -i mount

Check the generated systemd unit:

systemctl status mnt-data.mount

Systemd converts fstab entries into mount units. A mount point of /mnt/data normally becomes:

mnt-data.mount

mount -a

reports an error

Do not reboot.

Correct the entry, then rerun:

sudo findmnt --verify

sudo mount -a

Repeat until both checks succeed.

Safely Removing an

fstab

Entry

Before removing a permanent mount, check whether anything is using it:

sudo lsof +f -- /mnt/data

Or:

sudo fuser -vm /mnt/data

Stop any relevant applications, then unmount it:

sudo umount /mnt/data

Edit /etc/fstab and remove or comment out the entry:

# UUID=5d82c312-1e11-4ad5-9982-a42dcb6a3740 /mnt/data ext4 defaults 0 2

Verify the remaining file:

sudo findmnt --verify

sudo mount -a

A Safe Permanent-Mount Checklist

Before rebooting, confirm all of the following:

The correct disk and partition have been identified.
The filesystem type has been verified.
The UUID has been copied accurately.
The mount-point directory exists.
The mount point does not contain files that will be hidden.
The drive mounts manually.
The fstab entry contains six valid fields.
sudo findmnt --verify reports no serious errors.
sudo mount -a completes successfully.
findmnt shows the filesystem at the intended location.
Ownership and permissions are correct.
A recovery console is available for remote systems.

Only after these checks should you reboot:

sudo reboot

Once the machine returns, verify the mount:

findmnt /mnt/data

df -hT /mnt/data

Final Thoughts

Using /etc/fstab is one of the most useful Linux administration skills. It allows storage to appear consistently after every reboot and ensures applications can find their data where they expect it.

The key is to treat fstab as a critical system configuration file rather than a place for trial and error.

Use UUIDs, create clear mount points, understand the chosen options and always test with:

sudo findmnt --verify

sudo mount -a

A few careful checks can prevent a simple storage change from becoming a difficult boot-recovery exercise.

Need Help Managing Linux Storage?

Hamilton Group can help your organisation configure Linux servers, permanent drive mounts, backup storage, shared filesystems and secure infrastructure.

Whether you are adding storage to a server, moving application data or troubleshooting a machine that no longer boots after an fstab change, our team can help you complete the work safely.

Call 0330 043 0069 or visit hgmssp.com to speak with one of our IT specialists.