Mounting a New Disk on Linux

You add a new hard drive to a server, plug it in, and the system shows no extra usable space—a scenario almost everyone runs into the first time they expand storage. Between "connected to the motherboard" and "able to store files" there are four steps: detection, partitioning, formatting, and mounting. This note walks through the whole process and explains what each step actually does.

Background: Why a Freshly Plugged-in Disk Isn't Usable

In Linux, everything is a file, and disks are no exception. When a new disk is attached, the kernel recognizes it as a block device such as /dev/sdb or /dev/vdb, but at that point it's just a "raw" disk:

• No partition table, so the system doesn't know how the space is divided;
• No filesystem, so the kernel doesn't know how data is organized;
• No mount point, so userspace programs can't access it through a path.

The full workflow is therefore: detect → partition → format → mount, and finally configure auto-mount at boot. Skipping any step breaks the chain.

Step by Step

1) Connect the disk to the motherboard (this matters)

On a physical machine, that means hooking up the SATA and power cables; on a cloud server, it means attaching the cloud disk to the instance in the console. This sounds obvious, but when troubleshooting "the system can't see the disk," a loose hardware connection really is the most common cause.

2) Reboot the system

reboot

On older systems, or when hot-plugging doesn't take effect, a reboot is the easiest way to make the kernel rescan the hardware. Environments that support hot-plugging can detect the disk without rebooting, but a reboot is the most reliable fallback.

3) Check whether the disk has been detected

fdisk -l

fdisk -l lists all block devices and their partitions. A new disk typically shows capacity but no partitions (no entries like /dev/sdb1 underneath it). Note down this device name—you'll need it in every subsequent step. You can also cross-check with lsblk, which displays disks and partitions as a tree and is easier to read.

4) Enter the disk and start partitioning

fdisk /dev/{disk name}

Replace {disk name} with the device name from the previous step, e.g. sdb. fdisk is an interactive tool; the commands you'll use most often inside it are:

• n: create a new partition
• p: print the current partition table
• d: delete a partition
• w: write changes to disk and exit
• q: exit without saving

5) Set up the partitions—a single partition is fine

If the whole disk is just for storing data, press n to create one primary partition, hit Enter to accept the default start and end sectors, and turn the entire disk into a single partition, then w to save and exit. Splitting a disk into multiple partitions rarely pays off these days and only adds management overhead.

One reminder: the traditional MBR partition table only supports up to 2TB. Disks larger than 2TB need a GPT partition table, in which case you should use parted or gdisk instead.

6) Format the partition

mkfs.ext4 /dev/{partition name}

Note that the target here is the partition (e.g. /dev/sdb1), not the whole disk. mkfs.ext4 creates an ext4 filesystem on the partition, writing metadata structures like the superblock and inode tables. ext4 is currently the most universal choice across Linux distributions; if your distribution defaults to XFS (like the CentOS family), mkfs.xfs works just as well.

Formatting wipes all data on the partition, so double-check the device name before running it.

7) Mount the partition

mount /dev/{partition name} /{some directory}

The mount point is just a regular directory—if it doesn't exist, create it first with mkdir, e.g. mkdir /data. Once mounted, files written to /data actually land on the new disk. You can verify with df -h, which shows the mapping between partitions, capacity, and mount points.

If the mount point directory already contained files, they'll be "hidden" after mounting and reappear once you umount—no data is lost, but it's confusing, so use an empty directory as the mount point.

8) Set up auto-mount at boot

The mount command only lasts for the current boot; after a restart the mount is gone. To make it persistent, edit /etc/fstab:

vim /etc/fstab

Append a line at the end of the file:

/dev/(disk partition) /(mount directory) ext4 (filesystem type) defaults 0 0

This line has six fields, in order:

1. Device: the partition to mount, e.g. /dev/sdb1;
2. Mount point: the directory path, e.g. /data;
3. Filesystem type: must match what you formatted with, here ext4;
4. Mount options: defaults means a standard set of options like read-write and allow-execute;
5. Dump backup flag: 0 means don't back up with the dump utility;
6. fsck check order: 0 means no filesystem check at boot; the root partition is usually 1, and data disks can be 2 or 0.

warning

A mistake in /etc/fstab can make the system fail to boot and drop into emergency mode. After saving, run mount -a first to verify—it mounts every not-yet-mounted entry in fstab. Only reboot once it completes without errors.

Pitfalls and Notes

• Use UUIDs instead of device names for reliability. Names like /dev/sdb depend on the kernel's detection order and can change after adding or removing disks, causing fstab to mount the wrong one. Look up the partition's UUID with blkid and write the first fstab column as UUID=xxxx—that way device-name drift can't affect it.
• Confirm the device name before formatting. Running mkfs on the wrong target is irreversible. Double-check with lsblk or fdisk -l beforehand and make sure the capacity matches what you expect.
• Distinguish disks from partitions. Partitioning, formatting, and mounting each operate on different objects: fdisk works on the whole disk (/dev/sdb), while mkfs and mount work on partitions (/dev/sdb1). Mixing them up is the most common source of errors for beginners.

Wrap-up

The main line of mounting a new disk is four steps: fdisk -l to confirm detection, fdisk to partition, mkfs.ext4 to format, mount to mount, and finally writing /etc/fstab so the configuration survives reboots. Once you understand the chain of "raw disk → partition → filesystem → mount point," any future storage expansion or disk replacement can be troubleshot layer by layer along that same chain.