Mounting Drives & Filesystems

When you attach a new disk to a Linux server — an extra hard drive, a USB stick, or a cloud volume — Linux does not automatically start using it. You first have to mount it, which means attaching the disk’s filesystem to a folder so you can read and write files there. A filesystem is just the way data is organized on a disk (common types on Ubuntu are ext4 and xfs). This page shows you how to find a disk, mount it by hand, and make that mount come back automatically after every reboot using /etc/fstab.

What “mounting” actually means

On Linux there are no drive letters like C: or D: (that is a Windows idea). Instead, everything lives under one single tree that starts at / (called the root of the filesystem). When you mount a disk, you pick an empty folder — called a mount point — and from then on, opening that folder shows the contents of the disk.

For example, if you mount a 100 GB volume at /mnt/data, then /mnt/data and everything under it lives on that new disk. The folder name does not change; only what is behind it does.

Gotcha: If the folder you choose as a mount point already has files in it, those files become hidden (not deleted) while the disk is mounted. Always mount onto an empty folder to avoid confusion.

Finding your disks

Before mounting anything, you need the device name, like /dev/sdb or /dev/nvme1n1. Two tools tell you what is attached.

lsblk — list block devices

lsblk (“list block devices”) shows every disk and partition in a clean tree. A block device is just the kernel’s name for a storage device.

lsblk

Output:

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda       8:0    0   30G  0 disk
└─sda1    8:1    0   30G  0 part /
sdb       8:16   0  100G  0 disk

Here sda is the main system disk (its only partition sda1 is mounted at /). The disk sdb is brand new — it has no partition and no mount point yet. That is the one we will mount.

blkid — find the UUID and filesystem type

Every formatted filesystem has a UUID (Universally Unique Identifier — a long, permanent label). Device names like /dev/sdb can change order between reboots, but a UUID never changes, so we use it in /etc/fstab.

sudo blkid /dev/sdb

Output:

/dev/sdb: UUID="b2c4d6e8-1234-5678-9abc-def012345678" TYPE="ext4"

If blkid prints nothing, the disk has no filesystem yet — see the next section.

Formatting a brand-new disk

A fresh cloud volume is usually empty (no filesystem). Writing a filesystem onto it is called formatting. Do this only on a new, empty disk — formatting erases everything.

sudo mkfs.ext4 /dev/sdb

Output:

mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 26214400 4k blocks and 6553600 inodes
Filesystem UUID: b2c4d6e8-1234-5678-9abc-def012345678
Writing superblocks and filesystem accounting information: done

Warning: Double-check the device name with lsblk first. Running mkfs on the wrong device (like your root disk /dev/sda) will destroy your server. There is no undo.

Mounting a disk by hand

Now create a mount point and mount the disk. The mount you make this way is temporary — it disappears on reboot. That makes it perfect for a quick test before you commit to a permanent setup.

sudo mkdir -p /mnt/data
sudo mount /dev/sdb /mnt/data

The first command makes the empty folder (-p creates parent folders as needed). The second attaches the disk to it. Confirm it worked:

df -h /mnt/data

Output:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb         98G   24K   93G   1% /mnt/data

df -h (“disk free”, human-readable) confirms the disk is mounted and shows free space. You can now write files into /mnt/data.

Unmounting a disk

To detach a disk safely, use umount (note the spelling — there is no “n”). Always unmount before physically removing a USB drive or detaching a cloud volume, so pending writes finish.

sudo umount /mnt/data

If you get a target is busy error, something is using the disk. Find out what with lsof (“list open files”):

sudo lsof /mnt/data

A common cause is that your terminal’s current directory is inside the mount point. Just cd ~ and try again.

Making the mount permanent with /etc/fstab

A manual mount is gone after a reboot. To mount automatically at boot, add a line to /etc/fstab (the “filesystem table”). This is the standard, correct way to mount extra drives on a server.

Each line has six fields:

Field	Meaning	Example
Device	The UUID or device path	UUID=b2c4d6e8-...
Mount point	Where to attach it	/mnt/data
Filesystem type	The format	ext4
Options	Mount options	defaults
Dump	Backup flag (almost always 0)	0
Pass	fsck check order at boot (0 = skip, 2 = data disks)	2

Open the file with a text editor:

sudo nano /etc/fstab

Add this line at the bottom, using your UUID from blkid:

UUID=b2c4d6e8-1234-5678-9abc-def012345678  /mnt/data  ext4  defaults,nofail  0  2

The nofail option is important: it tells the system to keep booting even if the disk is missing, instead of dropping you into an emergency shell.

Test before you reboot

This is the single most important habit with /etc/fstab. A bad entry can stop your server from booting, and on a cloud server you may not have screen access to fix it. Test the file first:

sudo umount /mnt/data
sudo mount -a

mount -a mounts everything in /etc/fstab. If it runs with no errors, your entry is valid. Confirm with df -h /mnt/data again. Only reboot once mount -a is clean.

Warning: Never reboot right after editing /etc/fstab without running sudo mount -a first. A typo in this file is the most common reason a Linux server fails to boot. The nofail option is your safety net — use it on every non-essential drive.

Mounting an extra cloud volume

On a cloud provider (AWS EBS, DigitalOcean Volumes, etc.) the steps are exactly the same. After you attach the volume in the provider’s dashboard:

lsblk                              # find the new device, e.g. /dev/nvme1n1
sudo mkfs.ext4 /dev/nvme1n1        # format only if it is new and empty
sudo mkdir -p /mnt/appdata
sudo blkid /dev/nvme1n1            # copy the UUID
sudo nano /etc/fstab               # add: UUID=...  /mnt/appdata  ext4  defaults,nofail  0  2
sudo mount -a                      # test
df -h /mnt/appdata                 # verify

The volume now survives reboots and keeps your data even if you rebuild the server, because the disk is separate from the machine.

Best Practices

• Always identify disks with lsblk and blkid before touching them — never guess a device name.
• Mount data disks by UUID in /etc/fstab, never by /dev/sdX, because device names can change between boots.
• Add nofail to every extra-drive fstab line so a missing disk never blocks boot.
• After editing /etc/fstab, run sudo mount -a and check for errors before you ever reboot.
• Format (mkfs) only brand-new, empty disks — and triple-check the device name first.
• Always umount a USB or cloud volume before detaching it to avoid losing unwritten data.

Related Topics

• Disk Management
• Checking Disk Usage
• Memory and Swap
• The Boot Process
• Monitoring Resources