Mount a disk in Linux: a new drive, a drive with data on it, and /etc/fstab

Short answer: to mount a drive that already has data on it, do not partition or format it. Find its partition with lsblk -f (a drive with data shows a file system such as ext4 or ntfs), create an empty folder and mount the partition there: sudo mount /dev/sdb1 /mnt/data. To mount it at every boot, add it to /etc/fstab by UUID.

lsblk -f                                  # find it: note the partition and its FSTYPE
sudo mkdir -p /mnt/data
sudo mount -o ro /dev/sdb1 /mnt/data       # read-only first, to look before you touch
ls -la /mnt/data
sudo mount -o remount,rw /mnt/data         # writable, once you are sure it is the right one

Device names in this guide (/dev/sdb, /dev/vdb) are examples; always use the names lsblk prints on your machine. The mkfs.ext4 prompts and the findmnt --verify messages quoted below were produced on Debian 12 (e2fsprogs 1.47.0, util-linux 2.38.1) against image files in a scratch folder, not a real disk; mount, umount and /etc/fstab behaviour follows their man pages.

Step 1: which disk is it, and does it hold data?

lsblk -f
sudo blkid /dev/vdb1

NAME    FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
vda
├─vda1  ext4   1.0          1d0c2e8a-5b7f-4a3e-9c11-2f6d8e4b7a10   31.2G    35% /
└─vda15 vfat   FAT32        7A1B-3C2D                              98.3M     6% /boot/efi
vdb
└─vdb1  ext4   1.0   backup 7f9e3c1a-8d42-4b6e-a5f0-3c9b1e2d4f68
vdc

/dev/vdb1: LABEL="backup" UUID="7f9e3c1a-8d42-4b6e-a5f0-3c9b1e2d4f68" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c4e1b7d2-3a5f-4e8b-9d06-1f2a3b4c5d6e"

Read it from the left. vda holds the system: its partition is mounted on /. vdb has one partition with an ext4 file system and a label, so it carries data and is not mounted anywhere yet. vdc shows no partition and no file system at all, which usually means it is empty. Name prefixes tell you the hardware: vd is a virtio disk in a virtual machine, sd a SATA, SAS or virtio-scsi disk, nvme0n1 an NVMe drive whose partitions are nvme0n1p1, nvme0n1p2 and so on.

Mount a drive that already has data

1. 1Create a mount point

   sudo mkdir -p /mnt/data

   A mount point is an ordinary empty folder. /mnt/NAME is the convention for something temporary, a top-level folder such as /data or /srv/backup for a permanent disk. If you mount onto a folder that already has files in it, they are hidden (not deleted) until you unmount again.

2. 2Mount it read-only and look

   sudo mount -o ro /dev/vdb1 /mnt/data
   ls -la /mnt/data
   df -h /mnt/data
   findmnt /mnt/data

   mount detects the file system type on its own; add -t ext4 only if it guesses wrong. Read-only is a cheap safety step: if you picked the wrong partition, no file on it has been changed. One caveat from man mount: on an ext4 file system that was not cleanly unmounted, the kernel still replays the journal; -o ro,noload prevents even that. When the contents are what you expected, make it writable with sudo mount -o remount,rw /mnt/data, or go straight on to the fstab entry below.

3. 3Fix ownership if the disk came from another machine

   ls -ln /mnt/data                       # numeric owners, as stored on the disk
   sudo chown -R alice: /mnt/data/projects   # hand a folder to the matching local user

   Linux file systems store owners as numbers, not names. A folder that belonged to UID 1001 on the old server belongs to whoever has UID 1001 here, which may be nobody or the wrong person. chown fixes it; NTFS and exFAT have no Unix owners at all (see below).

If mount refuses with wrong fs type, bad option, bad superblock on /dev/vdb1, read the last kernel lines with sudo dmesg | tail. The usual causes are a missing driver for the file system, a partition that is part of LVM or RAID (first table above), or a file system that was not cleanly unmounted. sudo fsck -n /dev/vdb1 checks without changing anything; the repair itself, on the unmounted partition, is in read-only file system.

Prepare a new, empty disk

sudo wipefs /dev/vdc         # lists every signature it finds; no output = none
sudo blkid -p /dev/vdc       # exit code 2 = nothing recognised

wipefs without -a only lists, it changes nothing. A blank disk prints nothing at all. One with an old partition table shows lines of type gpt or dos, one with a file system its type and UUID. Either means someone used this disk, so make sure that what is on it can go. Then create a partition and a file system:

sudo apt install -y parted
sudo parted --script /dev/vdc mklabel gpt mkpart data ext4 0% 100%
sudo mkfs.ext4 -L data /dev/vdc1
lsblk -f /dev/vdc            # vdc1 now shows ext4, the label and a UUID

A file system straight on the whole disk (mkfs.ext4 /dev/vdc, no partition) works too and is what the block storage guide does. A partition table costs nothing and tells every tool that looks at the disk what it is for. Use mkfs.xfs instead of mkfs.ext4 if you prefer XFS; the remaining steps are the same.

mkfs only asks in a terminal

mkfs.ext4 has a safety question, but it does not always ask it. Run in a terminal against a target that already holds something, it stops:

mke2fs 1.47.0 (5-Feb-2023)
./disk.img contains a ext4 file system labelled 'data'
	created on Wed Oct 21 19:48:00 2026
Proceed anyway? (y,N) n

Found a gpt partition table in ./disk2.img
Proceed anyway? (y,N) n

Run from a script, a pipe or anything else without a terminal, the same command formatted the image that already had a file system without asking, and its old UUID and label were gone. So a formatting step in a provisioning script needs its own check first, such as [ -z "$(wipefs /dev/vdc)" ] || exit 1 before the mkfs line.

Mount it at every boot: /etc/fstab

A plain mount lasts until the next reboot. For a permanent mount, add a line to /etc/fstab, and identify the partition by its UUID, because names like /dev/vdb can swap places when disks are added or removed.

sudo cp /etc/fstab /etc/fstab.bak
sudo blkid -s UUID -o value /dev/vdb1      # prints the UUID only
echo "UUID=7f9e3c1a-8d42-4b6e-a5f0-3c9b1e2d4f68 /mnt/data ext4 defaults,nofail 0 2" | sudo tee -a /etc/fstab

nofail is the option to remember. Without it, a disk that is missing or renamed at boot drops the whole server into emergency mode, which on a remote machine means the console. With it, the boot carries on and only that mount is absent. For an NTFS or exFAT drive the type field reads ntfs3 or exfat; a swap file or swap partition gets a line of its own, as in adding swap space.

Test the entry before you reboot

sudo findmnt --verify          # checks /etc/fstab
sudo systemctl daemon-reload   # systemd re-reads fstab
sudo mount -a                  # mounts everything listed that is not mounted yet
findmnt /mnt/data

Success, no errors or warnings detected

/mnt/backup
   [E] unreachable on boot required target: No such file or directory
   [E] unreachable on boot required source: UUID=0000aaaa-1111-2222-3333-444455556666

0 parse errors, 2 errors, 0 warnings

The first error means the mount point folder does not exist, the second that no disk with that UUID is attached: a typo, or the UUID of the disk rather than of the partition. findmnt --verify exits with 1 when it finds an error, so it fits in a script. It does not catch everything: in the same test a misspelt option (defualts) passed without a word. mount -a is the check for that, because the kernel refuses an option it does not know. Run both, and reboot only when both are quiet.

Unmount, and “target is busy”

sudo umount /mnt/data           # umount, without the n

umount: /mnt/data: target is busy.

Something still has a file or folder open on that file system. Very often it is your own shell, sitting inside the mount point. Find the rest:

cd /                            # leave the mount point yourself
sudo fuser -vm /mnt/data        # processes using the file system
sudo lsof /mnt/data             # open files on it, with the program and user

Stop the service or close the program that holds it, then umount again. sudo umount -l /mnt/data (lazy) detaches the mount at once and finishes the job when the last user lets go; it is handy but hides which process was still writing. fuser -km kills every process on the file system and is rarely what you want on a server. More ways to read lsof output are in the lsof command. To stop a disk from mounting at boot, delete or comment out its line in /etc/fstab as well.

NTFS and exFAT drives

Current kernels read and write both: the ntfs3 driver has been in Linux since 5.15 and the exfat driver since 5.7 (older systems use the ntfs-3g package). For checking and formatting, install ntfs-3g or exfatprogs. Neither file system stores Unix owners, so pick them at mount time, for example sudo mount -o uid=1000,gid=1000 /dev/sdb1 /mnt/usb. An NTFS drive that Windows left hibernated, which Fast Startup does, is mounted read-only or refused; shut Windows down fully, or copy the data off read-only. On a server, use these formats only to move data in or out, and keep it on ext4 or XFS.

On a VPS or dedicated server

• A VMHeaven VPS. Extra storage from the panel, in fixed blocks on a running server, enlarges the existing virtual disk rather than adding a second one. You then either grow the partition and file system into the new space, which what is block storage shows with growpart and resize2fs, or create a new partition in the free space, format it and mount it, for example at /data, with the steps above. The Storage VPS page has the sizes and the Windows variant.
• A dedicated server. The drives are physical. Run lsblk -f before anything else to see which drive holds the system and which are still unused.
• A bad fstab line. If a VMHeaven VPS stops in emergency mode after a reboot, the VNC console in the panel still reaches it: log in, comment out the line, reboot. A dedicated server has no VNC console to fall back on, so there nofail and the two checks above matter even more.
• Space running out on the new mount? Checking disk usage finds what is using it.

Frequently asked