How to Find the UUID of a Disk or Partition on Linux

This guide shows you how to find the UUID of a disk or partition on a Linux server, and, just as importantly, why you should use it. A UUID (Universally Unique Identifier) is a long, fixed label that identifies a filesystem no matter which /dev name the kernel gives its disk on a given boot. You will learn the three standard ways to read a UUID (lsblk, blkid and the /dev/disk/by-uuid directory), the difference between a filesystem UUID and a partition UUID, and how to use a UUID in /etc/fstab so that extra volumes mount in the right place every time. It is written for Noiz clients who run a self-managed VPS or dedicated server, or who have a shell-user account, and who reach the server over SSH with root or sudo access. If you have never needed a UUID before, the short version is this: it is the reliable answer to the question "which disk did I actually mean?"

Last reviewed: 27 July 2026, against the standard util-linux tools (blkid and lsblk) and the Linux fstab(5) format as shipped on current mainstream distributions. This guide is written for Noiz hosting and is kept current against those tools. Column layout and wording in command output can vary slightly between distributions and util-linux versions, so treat the sample output below as representative rather than character-for-character. It complements, and does not replace, the official documentation linked below.

Official Documentation Reference

• fstab(5) manual page: the authoritative description of the /etc/fstab file and its six fields. It states plainly that identifying a filesystem by UUID= or LABEL= is "the recommended method, as device names are often a coincidence of hardware detection order, and can change when other disks are added or removed."
• blkid(8) manual page: the reference for the blkid command, which reads the UUID, LABEL and TYPE tokens directly from filesystem and swap metadata.
• lsblk(8) manual page: the reference for lsblk, whose -f option prints filesystem type, label, UUID and mount point in a tree view.
• Persistent block device naming (Arch Wiki): a distribution-neutral explanation of why /dev/sda style names are not stable, and of the persistent alternatives: by-uuid, by-partuuid, by-label and by-id.

Prerequisites

• SSH access to your server as root, or as a user who can run sudo. Reading a UUID works for any user, but blkid only returns full, verified details when run with root privileges, and editing /etc/fstab always requires root.
• Basic comfort at the Linux command line: running a command, reading its output, and editing a text file with an editor such as nano or vi.
• This is a server-administration task on a VPS or dedicated server. On a shared hosting account you do not manage disks or /etc/fstab, so this guide does not apply there.

What a UUID is, and the kinds you will meet

A filesystem UUID is a 128-bit identifier written into the filesystem's own metadata (its superblock) when the filesystem is created with mkfs. It looks like this:

a1b2c3d4-5e6f-4789-9abc-0123456789ab

Because the UUID lives inside the filesystem, it travels with the data. Move the disk to a different port, attach it to a different server, or let the kernel assign it a different /dev name, and the UUID stays the same. It only changes if you reformat the filesystem or deliberately reset it. That permanence is exactly what makes it useful.

You will run into a few related labels, and it helps to know which is which:

• Filesystem UUID: the one described above, stored in the filesystem. This is what you almost always want for mounting, and it is what lsblk -f and blkid show in the UUID column.
• PARTUUID: a separate identifier stored in the GPT partition table for a partition, independent of whatever filesystem is inside it. It is useful when there is no filesystem UUID to use, for example for a raw partition, and some bootloaders prefer it.
• LABEL and PARTLABEL: optional human-readable names for a filesystem or a partition. Handy for people, but a label is easy to duplicate by accident, so a UUID is the safer choice for automatic mounting.

One quirk to expect: FAT and vfat filesystems, such as an EFI system partition, do not have a full 128-bit UUID. They show a shorter volume serial like 1234-ABCD instead. That is normal, and it still works in fstab as UUID=1234-ABCD.

Why use a UUID instead of /dev/sda: the real reason

The names /dev/sda, /dev/sdb and so on (and their virtual-disk and NVMe cousins /dev/vda and /dev/nvme0n1) are handed out by the kernel in the order it discovers storage during boot. That order is not a contract. It can change when you attach a second volume, when a controller is added or reordered, when you restore from a snapshot that has an extra disk attached, or simply on a boot where devices are probed in a different sequence. The disk that is /dev/sdb today can come up as /dev/sda tomorrow, with nothing on the disk itself having changed.

The consequence is not academic. If /etc/fstab mounts your data volume by /dev/sdb1 and the kernel later swaps the names around, the server can mount the wrong filesystem at your mount point, or fail the mount entirely and drop to an emergency prompt on the next reboot. Because a UUID identifies the filesystem itself rather than its slot in the boot order, mounting by UUID always gives you the filesystem you meant. This is why the fstab(5) manual page calls UUID (or LABEL) the recommended method, and why nearly every modern distribution and cloud image already mounts the root filesystem by UUID out of the box.

On a Noiz VPS this matters most the day you attach an additional block-storage volume for data or backups. When Noiz provisions the server, the root filesystem is already referenced by UUID in /etc/fstab. When you add your own volume and want it to mount automatically at boot, add it by UUID too. If you take the shortcut of writing /dev/sdb1 instead, a later reboot may quietly mount it in the wrong place, or leave your server unable to boot cleanly until you fix the entry.

Find the UUID

Any of the three methods below gives you the same answer. Pick whichever you find easiest to read. Running them as root (or with sudo) gives the most complete output.

Method 1: lsblk -f (clearest overview)

The lsblk command lists block devices as a tree. The -f option adds filesystem details, including the UUID, and shows how partitions sit under each disk and where they are mounted. This is usually the friendliest place to start:

lsblk -f

Typical output on a server with a system disk and one attached data volume looks like this:

NAME   FSTYPE LABEL UUID                                 MOUNTPOINTS
sda
├─sda1 vfat         1234-ABCD                            /boot/efi
└─sda2 ext4         a1b2c3d4-5e6f-4789-9abc-0123456789ab /
sdb
└─sdb1 ext4  data   f0e1d2c3-b4a5-4687-9182-abcdef012345 /mnt/data

Read down the UUID column to find the value for the partition you care about. In the example above, the data volume sdb1 has UUID f0e1d2c3-b4a5-4687-9182-abcdef012345. If you want a tidier, custom set of columns, you can ask for exactly the fields you need:

lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINT

Method 2: blkid (device-by-device detail)

The blkid command reads the identifying tokens straight from each device's metadata. Run on its own it lists every block device it can see:

sudo blkid

Each line names a device and its attributes:

/dev/sda1: UUID="1234-ABCD" TYPE="vfat" PARTUUID="0001a2b3-01"
/dev/sda2: UUID="a1b2c3d4-5e6f-4789-9abc-0123456789ab" TYPE="ext4" PARTUUID="0001a2b3-02"
/dev/sdb1: LABEL="data" UUID="f0e1d2c3-b4a5-4687-9182-abcdef012345" TYPE="ext4" PARTUUID="9f8e7d6c-01"

To read just one device, name it. This is the cleanest way to grab a single value:

sudo blkid /dev/sdb1

You can also ask blkid for one field only, which is handy when scripting or copying the value into fstab:

sudo blkid -s UUID -o value /dev/sdb1

Note that blkid gives verified, up-to-date results only when run as root. An ordinary user may get cached or incomplete output, which is a common reason a UUID appears to be "missing".

Method 3: ls -l /dev/disk/by-uuid (the mapping the system uses)

The system itself keeps a directory of symbolic links named after every UUID, each pointing back to the current /dev name. Listing it shows the live mapping and is a good sanity check:

ls -l /dev/disk/by-uuid/

The output makes the point of this whole guide visible at a glance:

lrwxrwxrwx 1 root root 10 Jul 21 09:14 1234-ABCD -> ../../sda1
lrwxrwxrwx 1 root root 10 Jul 21 09:14 a1b2c3d4-5e6f-4789-9abc-0123456789ab -> ../../sda2
lrwxrwxrwx 1 root root 10 Jul 21 09:14 f0e1d2c3-b4a5-4687-9182-abcdef012345 -> ../../sdb1

Each stable UUID on the left maps to whatever changeable /dev name is current on the right. Sibling directories /dev/disk/by-partuuid, /dev/disk/by-label and /dev/disk/by-id provide the same idea for the other persistent identifiers.

Reading the UUID of an already-mounted filesystem

If the filesystem is already mounted and you only need its source and UUID, findmnt is quick:

findmnt -o TARGET,SOURCE,FSTYPE,UUID /mnt/data

Use the UUID in /etc/fstab to mount reliably

The /etc/fstab file tells the system which filesystems to mount at boot and where. Each line has six fields, in this order: the device to mount, the mount point, the filesystem type, the mount options, the dump flag, and the fsck pass order. To mount by UUID, put UUID= followed by the value in the first field instead of a /dev name.

A complete line for the data volume from the examples above, mounting it at /mnt/data, looks like this:

UUID=f0e1d2c3-b4a5-4687-9182-abcdef012345  /mnt/data  ext4  defaults  0  2

Taking the fields in turn:

• Device: UUID=f0e1d2c3-b4a5-4687-9182-abcdef012345. Replace this with your own value. Do not put quotation marks around it in fstab, even though blkid prints them.
• Mount point: /mnt/data. The directory must already exist. Create it first with sudo mkdir -p /mnt/data.
• Type: ext4 here. Use whatever lsblk -f or blkid reported in the FSTYPE or TYPE column, for example xfs or vfat.
• Options: defaults is a sensible baseline. See the note on nofail below for a small change that protects your boot.
• Dump: 0. This field is used by the old dump backup tool and is almost always left at 0.
• Pass: the fsck order at boot. Use 1 only for the root filesystem, 2 for other filesystems that should be checked, and 0 to skip the check.

Test the entry before you trust it

A mistake in /etc/fstab can stop the server booting, so never reboot to "see if it worked". Test it while the system is safely running instead. First, ask the system to check the file for obvious errors:

sudo findmnt --verify --verbose

Then try mounting everything in fstab that is not already mounted:

sudo mount -a

If mount -a returns with no error and your filesystem appears where you expect (confirm with lsblk -f or df -h /mnt/data), the entry is good. If it prints an error, fix the line and test again. Only once mount -a is clean should you consider the entry safe across reboots.

Protect the boot with nofail on non-essential volumes

For any volume that is not required for the server to function, such as an extra data or backup disk, add the nofail option so a missing or unreadable disk does not block the boot:

UUID=f0e1d2c3-b4a5-4687-9182-abcdef012345  /mnt/data  ext4  defaults,nofail  0  2

With nofail, if that volume is ever detached or fails to appear, the server still boots and simply leaves the mount point empty, rather than dropping into emergency mode. Do not use nofail on filesystems the system genuinely needs to run.

Troubleshooting

• blkid prints nothing, or an incomplete list: you are probably running it as an unprivileged user. Run it with sudo. As a non-root user, blkid returns only cached, unverified information and may show nothing at all.
• Two disks show the same UUID: this happens after cloning a disk, restoring an image, or booting from a snapshot alongside its original. Duplicate UUIDs make mounting ambiguous, and the wrong filesystem can be mounted. Give one of them a fresh UUID. For ext2/3/4 use sudo tune2fs -U random /dev/sdb1; for XFS use sudo xfs_admin -U generate /dev/sdb1. Then re-read the new UUID and update fstab to match.
• A FAT or EFI partition shows a short UUID like 1234-ABCD: that is expected. FAT/vfat volumes carry a short volume serial rather than a full 128-bit UUID, and it works normally as UUID=1234-ABCD in fstab.
• The UUID changed after you formatted the disk: reformatting with mkfs creates a brand-new filesystem with a brand-new UUID, so any old fstab entry now points at nothing. Read the new UUID and update the entry.
• mount -a reports "special device UUID=... does not exist": the UUID in fstab does not match any current device. Re-check it against lsblk -f or blkid for a typo, and confirm the disk is actually attached. On a VPS, verify the extra volume is attached to the server in the first place.
• The server dropped to an emergency prompt after a reboot: a bad fstab line is the usual cause. At the emergency prompt, remount the root filesystem writable with mount -o remount,rw /, open /etc/fstab, correct or comment out (with a leading #) the offending line, save, and reboot. Adding nofail to non-essential volumes prevents this class of failure in future.

If you run a managed Noiz plan, or you are attaching a new volume and would rather have it set up for you, open a support ticket with the Noiz support team. Include the server name, the output of sudo lsblk -f, the mount point you want, and what the volume is for. Never include private keys or passwords in a ticket.