Connecting and Mounting an Additional Server Disk in Linux

You've rebooted the server and it won't come up. The console is stuck on emergency mode or showing Failed to mount /mnt/data, and you're not just dealing with a new disk; you're dealing with an fstab error. This is exactly the moment when you realize that "mounting" isn't a one-line command, it's an operational decision. If you've just connected an additional server disk and don't know where to start, the order of work is: identify, partition, create filesystem, mount temporarily, test, then make it permanent.

First, check whether the kernel sees the additional server disk

Before anything else, you need to make sure the disk is visible at the operating system level. If the server is physical and you've just added the disk to a back slot, you may need to rescan:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
sudo partprobe
cat /proc/partitions

The lsblk output should show a device with no mountpoint, for example sdb with a size of 500G. If you don't see anything, the problem isn't partitioning; the problem is at a lower layer. On virtual machines, you must have attached the disk to the machine from the panel, and after that a restart or rescan is needed. On cloud servers, the disk usually appears immediately after attach, but on some platforms the device isn't created in /dev until a shutdown and power-on.

Partitioning and creating a filesystem on the additional server disk

For a data disk, choose GPT, not MBR. The reason is simple: MBR has a 2-terabyte ceiling, and if you connect a larger disk later, you'll be forced to migrate. With parted, things move faster:

sudo parted /dev/sdb mklabel gpt
sudo parted -a optimal /dev/sdb mkpart primary ext4 0% 100%
sudo mkfs.ext4 -L data /dev/sdb1

Don't underestimate the -L data label. On servers with multiple disks, device names shift after adding or removing hardware, and sdb may one day become sdc. With LABEL or UUID, this problem is solved.

Choosing a filesystem is a real decision, not a matter of taste. For a data disk on a general-purpose server, ext4 is my default choice: stable, mature repair tools, and predictable behavior under load. I choose XFS when there are large files and heavy concurrent writes; for example, a backup repository or a database disk with multi-gigabyte files. XFS cannot be shrunk, only grown. If you think you might need to reduce the size someday, go with ext4 from the start.

Temporary mount, test, then make it permanent

Never go straight to fstab. First mount temporarily and write and read:

sudo mkdir -p /mnt/data
sudo mount /dev/sdb1 /mnt/data
sudo chown deploy:deploy /mnt/data
echo test | sudo tee /mnt/data/probe.txt
df -h /mnt/data

If df shows the correct size and the file was written, now it's time to make it permanent. Get the UUID:

sudo blkid /dev/sdb1

And write the fstab line with the UUID, not with the device name:

UUID=8f3c1a2e-... /mnt/data ext4 defaults,nofail 0 2

Two points in this very line are the difference between a healthy reboot and a server in emergency mode. First, nofail: if the disk is absent for any reason, boot won't stop. Second, the last column is the number 2, not 1. The number 1 is reserved for the root (/), and if you give it to a data disk, fsck may run in the wrong order. For non-root filesystems, put 2 or 0.

Before rebooting, always run this:

sudo mount -a
sudo findmnt --verify

If mount -a returns without errors, the chance of a healthy boot is high. If it errors, fix it right there; not after the reboot when you only have the console.

This is where they make mistakes

The most common mistake I've actually seen: writing the fstab line with the device name (/dev/sdb1) instead of the UUID, and then adding another disk. The sign is that the server stops at emergency mode after reboot and journalctl -xb gives the message Dependency failed for /mnt/data, while the disk itself is healthy. The second mistake is forgetting nofail on non-critical disks. The third mistake, which is seen less often but costs a lot: mounting a data disk on a path that already has files. If /mnt/data is full of files and you mount the disk on top of it, those files become hidden under the mount point. The disk is full, but du shows nothing strange. To see them, you need to use another mount point or a bind mount.

When you wrote the additional server disk wrong in fstab and the server won't come up

The solution is booting in rescue mode. Enable rescue mode from the server panel, and after boot, mount the root disk and fix the fstab file. If you're not familiar with rescue, Reinstalling the server and working with rescue mode; saving data when you've lost access explains the exact path step by step. Important point: in rescue, comment out the faulty line, don't delete the whole file. After a successful boot, rewrite it with the correct UUID.

There's another temporary solution that works in the console: in GRUB, press the e key and add systemd.unit=emergency.target to the kernel line. After boot, the root is mounted read-only, so first run mount -o remount,rw / and then edit fstab.

Permanent mount for services: systemd mount or fstab?

For a normal data disk, fstab is enough and simpler. But if a service like MySQL or Docker depends on that path, boot order becomes important. In this case, write a unit of type mount so systemd can manage the dependency precisely:

[Unit]
Description=Data disk
Before=mysql.service

[Mount]
What=/dev/disk/by-uuid/8f3c1a2e-...
Where=/mnt/data
Type=ext4
Options=defaults,nofail

[Install]
WantedBy=multi-user.target

The file name must exactly match the mount path: mnt-data.mount. If you name it wrong, the unit is created but never activated, and you think it's working. The cost of this method is more complexity and harder debugging; that's why I only go for it where service dependency really matters.

A note about performance

If the additional server disk is NVMe and you're running a database on it, add the noatime option to the fstab line. It won't update the access timestamp every time a file is read, and under heavy write load there's a noticeable difference. For a backup disk where only writes happen, this option is almost ineffective and you can remove it.

If after mounting, read and write speed is lower than expected, before making any changes to settings, see Diagnosing the cause of high server load; a practical and step-by-step guide; because in many cases the bottleneck isn't the disk, it's the I/O queue or another service. For transferring existing data to the new disk, Transferring files with scp and rsync; a practical guide for servers covers safe options.

If your server is virtual and you're adding the disk from the panel, the attach behavior in cloud server and dedicated server is a bit different; in the former it usually appears without a reboot, and in the latter it may need a controller rescan. For lighter Linux environments, Linux hosting is an option that goes through this same partitioning and mounting cycle without dealing with physical hardware.

Frequently asked questions

Why does the server come up in emergency mode after adding the fstab line?

Because systemd can't mount the disk defined in fstab and stops the boot. The cause is usually a wrong UUID, a shifted device name, or the absence of the nofail option. With journalctl -xb in the same console, the exact line is identified.

What's the difference between UUID and LABEL in fstab, and which is better?

UUID is a unique identifier generated when the filesystem is created and doesn't change until you recreate the filesystem. LABEL is a name you set yourself and may accidentally be duplicated. UUID is safer; LABEL is only useful when you want the fstab line to be readable and you control the names.

Should I format the additional server disk before mounting?

If the disk is new, yes; you need to partition and create a filesystem. If the disk already has data, formatting erases everything. First check with blkid and lsblk -f whether it has a filesystem, and if it does, just mount it.

How do I know the disk is really mounted permanently?

After reboot, findmnt /mnt/data should show the path and UUID, and systemctl status mnt-data.mount should be active. If it's not mounted after reboot but works manually, it means your fstab line was never read or has a syntax error.

Before any reboot, run mount -a and findmnt --verify. These two commands alone save the largest number of servers that get stuck in emergency mode.