How to Mount a Disk in Linux: The Complete Guide Every Admin Needs

I’ll never forget the first time I had to mount an external drive in production at 2 AM. The backup server was running out of space, and I needed to add a new disk fast. I fumbled through the mount command, second-guessing every flag, triple-checking the UUID before adding it to fstab. One wrong character and the entire system wouldn’t boot.

That night taught me something important: mounting disks in Linux is one of those fundamental skills that looks simple until you actually have to do it under pressure. Whether you’re adding storage to a server, accessing an external USB drive, or mounting network shares, understanding how Linux handles disk mounting will save you from a lot of headaches.

In this guide, I’ll walk you through everything you need to know about mounting disks in Linux—from the basics to the best practices I wish someone had taught me on day one.

What Does “Mounting” Actually Mean?

Before we dive into commands, let’s clear up what mounting actually does. In Linux, just plugging in a disk doesn’t make it usable. The operating system needs to attach that disk’s filesystem to a specific directory in your file tree—that’s mounting.

Think of it like this: your Linux system is a tree of directories starting from root (/). When you mount a disk at /mnt/backup, you’re telling Linux “make this disk’s contents appear at this location.” Everything on that disk becomes accessible through that directory path.

The mount command handles this process, and it’s been a core part of Unix-like systems since the beginning.

Identifying Your Disk: The First Critical Step

You can’t mount a disk if you don’t know its device name. Linux assigns block device names like /dev/sda, /dev/sdb, /dev/nvme0n1 depending on the type and order of detection.

Here’s how I always start:

lsblk

This command lists all block devices with their sizes, types, and current mount points. The output looks something like this:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 465.8G  0 disk
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0 465.3G  0 part /
sdb      8:16   0   1.8T  0 disk

In this example, sdb is a 1.8TB disk that isn’t mounted anywhere. That’s my target.

For more detailed information including filesystem types and UUIDs, I use:

sudo blkid

This shows each partition’s UUID (Universally Unique Identifier), which we’ll need for permanent mounting. It looks like:

/dev/sdb1: UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" TYPE="ext4"

Mounting a Disk Temporarily

For one-time access—like when you plug in a USB drive—temporary mounting is the way to go. The mount won’t persist after a reboot, which is exactly what you want for removable media.

Create a Mount Point

First, create a directory where you want the disk to appear:

sudo mkdir -p /mnt/mydisk

I typically use /mnt for temporary mounts and /media for removable media, but you can choose any empty directory.

Mount the Disk

The basic syntax is straightforward:

sudo mount /dev/sdb1 /mnt/mydisk

If Linux can’t auto-detect the filesystem type, specify it explicitly:

sudo mount -t ext4 /dev/sdb1 /mnt/mydisk

Common filesystem types include ext4, xfs, vfat (for FAT32), ntfs, and exfat.

Verify the Mount

Check that it worked:

df -h | grep mydisk

Or use the more modern approach:

findmnt /mnt/mydisk

Now you can access the disk’s contents through /mnt/mydisk. When you’re done, unmount it cleanly:

sudo umount /mnt/mydisk

Pro tip: If unmount fails with “target is busy,” something is still using the disk. Use lsof /mnt/mydisk to find which process is holding it open, then either close that program or kill the process if necessary.

Mounting a Disk Permanently with fstab

For disks you want available every time the system boots—like an extra data drive—you need to add an entry to /etc/fstab (filesystem table).

This is where things get serious. A misconfigured fstab can prevent your system from booting. I learned this the hard way, which is why I always back up fstab before editing:

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

Why You Should Use UUID Instead of Device Names

Here’s something that bit me early in my career: device names like /dev/sdb can change between reboots. Add another disk, change your BIOS boot order, or swap cables, and suddenly /dev/sdb becomes /dev/sdc. Your carefully configured mount fails, and your system won’t boot.

UUIDs solve this problem. A UUID is permanently tied to the filesystem itself, not the device name. As the nixCraft guide explains, using UUIDs ensures your mounts work regardless of device enumeration order.

Get your disk’s UUID with:

sudo blkid /dev/sdb1

Adding an Entry to fstab

Open fstab with your favorite editor:

sudo nano /etc/fstab

Add a line following this format:

UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 /mnt/mydisk ext4 defaults 0 2

Let me break down each field:

• UUID=… – The unique identifier for your filesystem
• /mnt/mydisk – The mount point (must exist before mounting)
• ext4 – The filesystem type
• defaults – Mount options (more on this in a moment)
• 0 – Dump backup utility flag (0 = don’t backup)
• 2 – fsck check order (0 = don’t check, 1 = check first, 2 = check after root)

The Arch Wiki fstab page provides comprehensive documentation on every field and option if you need to dive deeper.

Testing Your fstab Configuration

This is the step that saves you from boot failures. Never reboot without testing your fstab changes first.

sudo mount -a

This command attempts to mount everything in fstab. If you see an error, you know immediately and can fix it while your system is still running. You can also verify the configuration with:

sudo findmnt --verify --verbose

If everything looks good, verify your disk is mounted:

df -h /mnt/mydisk

Understanding Mount Options

The “defaults” option is fine for most situations, but sometimes you need more control. Here are the options I use regularly:

• defaults – Equivalent to rw,suid,dev,exec,auto,nouser,async
• noatime – Don’t update access times (improves performance for frequently accessed files)
• ro – Mount read-only
• nofail – Don’t fail boot if this disk isn’t present (critical for external drives)
• user – Allow non-root users to mount this filesystem
• x-systemd.automount – Mount on first access instead of at boot (useful for network drives)

For an external backup drive that might not always be connected, I use:

UUID=... /mnt/backup ext4 defaults,nofail,noatime 0 2

The nofail option is crucial—without it, your system will hang during boot waiting for a disk that isn’t there.

Choosing the Right Filesystem

When you’re formatting a new disk, the filesystem you choose matters. For Linux systems, you’re usually choosing between ext4 and XFS.

ext4 is the safe, proven choice. It performs well for general use, handles small files efficiently, and has excellent tool support. If you’re not sure what to use, choose ext4.

XFS excels with large files and high-throughput workloads. I use XFS for video storage and database servers where we’re dealing with files in the hundreds of gigabytes. As this Pure Storage comparison notes, XFS scales better on multi-core systems but uses more CPU for metadata operations.

The catch with XFS? You can’t shrink it, only grow it. With ext4, you have more flexibility to resize in either direction.

Advanced: Mounting Network Shares

Mounting isn’t limited to local disks. You can mount network filesystems like NFS or CIFS (Windows shares) the same way.

For an NFS share:

sudo mount -t nfs 192.168.1.100:/shared /mnt/nfs

In fstab, with network-specific options:

192.168.1.100:/shared /mnt/nfs nfs defaults,_netdev,x-systemd.automount 0 0

The _netdev option tells systemd to wait until the network is up before trying to mount. The x-systemd.automount delays the actual mount until someone tries to access the directory—preventing boot delays if the NFS server is slow to respond.

Troubleshooting Common Mount Issues

When mounts fail, here’s my debugging checklist:

Mount Point Doesn’t Exist

Error: mount point does not exist

Solution: Create it first with mkdir -p /mnt/yourmountpoint

Device Already Mounted

Error: /dev/sdb1 is already mounted

Solution: Check where it’s mounted with findmnt /dev/sdb1, then either use that location or unmount it first.

Permission Denied

Error: mount: only root can do that

Solution: Use sudo. Regular users can’t mount filesystems unless specifically allowed in fstab with the user option.

Wrong Filesystem Type

Error: wrong fs type, bad option, bad superblock

Solution: Verify the filesystem with sudo blkid /dev/sdb1 and specify the correct type with -t.

Boot Failure After Editing fstab

If your system won’t boot after fstab changes, you’ll likely see emergency mode. Boot from a live USB, mount your root filesystem, and edit /etc/fstab to fix the error. This is why I always keep that backup copy and test with mount -a before rebooting.

For ongoing system issues, check the system logs with journalctl to see exactly what failed during the mount attempt.

Checking What’s Currently Mounted

To see all currently mounted filesystems, I use:

findmnt

This gives a tree view of the entire mount hierarchy. For a simpler list focused on disk usage, the classic approach works too:

df -h

If you need to check disk usage more thoroughly, that command shows you how much space is available on each mounted filesystem.

Automating Mounts with systemd

Modern Linux systems use systemd, which gives us more sophisticated mount options. You can create dedicated mount units instead of using fstab, which provides better logging and dependency handling.

For a mount unit at /etc/systemd/system/mnt-mydisk.mount:

[Unit]
Description=My Data Disk

[Mount]
What=/dev/disk/by-uuid/a1b2c3d4-e5f6-7890-abcd-ef1234567890
Where=/mnt/mydisk
Type=ext4
Options=defaults,noatime

[Install]
WantedBy=multi-user.target

Enable it with:

sudo systemctl enable mnt-mydisk.mount
sudo systemctl start mnt-mydisk.mount

Check the status just like any other service:

sudo systemctl status mnt-mydisk.mount

This approach integrates better with systemd’s service management and gives you clearer logging when things go wrong.

Best Practices I’ve Learned the Hard Way

After years of managing storage across dozens of servers, here’s what I always do:

Always use UUIDs in fstab. Device names change. UUIDs don’t. This single practice has saved me from countless boot failures.

Test with mount -a before rebooting. If fstab has errors, you want to find out while the system is still running, not during boot.

Use nofail for optional disks. External drives, backup volumes, anything that might not be connected at boot should have the nofail option.

Label your filesystems. You can assign human-readable labels with e2label (ext4) or xfs_admin -L (XFS). Then mount by label instead of UUID for better readability.

Monitor mount points after changes. Use df -h and check service status to verify everything mounted correctly.

Document your mounts. Add comments in fstab explaining what each disk is for. Six months later, you’ll thank yourself.

When to Remount vs Unmount and Mount

Sometimes you need to change mount options on a filesystem that’s already mounted—like making it read-only for maintenance. You can remount without unmounting:

sudo mount -o remount,ro /mnt/mydisk

This is especially useful when you can’t unmount because files are in use, but you need to change permissions or options. To make it read-write again:

sudo mount -o remount,rw /mnt/mydisk

Final Thoughts

Mounting disks in Linux is one of those skills that seems simple until you need to do it right. The basics are straightforward—mount /dev/sdb1 /mnt/disk—but production systems demand more: persistent mounts, proper UUIDs, thoughtful options, and robust error handling.

I still remember that 2 AM panic when I first had to mount a production disk. These days, I move through the process with confidence: identify the disk with lsblk, grab the UUID with blkid, add it to fstab with the right options, test with mount -a, verify with findmnt.

The difference between then and now isn’t just knowing the commands—it’s understanding why each step matters and what can go wrong if you skip them.

Take your time, test your changes, and always keep a backup of your fstab. Your future self will thank you.