Linux blkid Command: 41 Examples Every SOC Analyst Should Know

Linux blkid Command Cheat Sheet: Identify Disks, UUIDs, and Filesystems Safely During Investigations

Quick Answer
blkid reads block-device metadata such as UUIDs, filesystem types, and labels. Use it with lsblk to identify disks before mounting, repairing, editing /etc/fstab, or triaging suspicious media during an investigation.

Picture a composite scenario that plays out in many data centers. An admin adds a new data disk, hardcodes /dev/sdb1 into /etc/fstab, and reboots. After the reboot the kernel enumerates the disks in a different order, the wrong device lands on the mount point, and the server drops into emergency mode. In a worse variation, a technician plugs in a USB drive found in a parking lot and mounts it without checking what it is.

Both problems come down to one question: what exactly is this block device? The blkid command answers it quickly. For SOC analysts, incident responders, and anyone doing enterprise Linux server hardening, it is a small tool that supports digital forensics workflows and prevents costly configuration mistakes.

Table of Contents

• Why blkid matters to security teams
• Core blkid commands
• Filtering fields: UUID, TYPE, LABEL
• Output formats for scripting and reporting
• Low-level probing and cache behavior
• Safe /etc/fstab workflow with UUIDs
• Searching by label, UUID, or type
• Incident response and forensics use cases
• Common pitfalls and corrections
• Expert tips
• FAQ

Why blkid Matters to Security Teams

blkid is part of the util-linux package. It inspects block devices and reports metadata such as the filesystem UUID, filesystem type, and label. UUIDs stay with the filesystem, while names like /dev/sda1 can change between boots. That makes UUIDs the safer way to reference storage in configuration files.

From a defender's view, blkid helps you:

• Confirm what a newly attached device contains before you touch it.
• Spot encrypted containers (for example, crypto_LUKS) on systems where encryption was not expected.
• Document storage identifiers in an incident timeline.
• Prevent boot failures caused by bad /etc/fstab entries.

Core blkid Commands

List everything blkid can see

sudo blkid

What it does: Prints device names, UUIDs, filesystem types, and labels where available.
When to use it: As your first step on an unfamiliar system.
Expected output: One line per device, such as /dev/sda1: UUID="..." TYPE="ext4".

Inspect a single partition

sudo blkid /dev/sda1

Shows metadata for just that partition. Running blkid /dev/sda1 without sudo may work, but access to some devices or metadata can be restricted, so use root for reliable results.

Cross-check with lsblk

lsblk -f
sudo blkid

Compare the device layout from lsblk with the filesystem metadata from blkid. Any mismatch is worth investigating.

Filtering Fields: UUID, TYPE, and LABEL

The -s option limits output to the tags you select.

sudo blkid -s UUID
sudo blkid -s TYPE
sudo blkid -s LABEL
sudo blkid -s UUID /dev/sda1
sudo blkid -s TYPE /dev/sda1
sudo blkid -s LABEL /dev/sda1
sudo blkid -s UUID -s TYPE -s LABEL

The last command is a good pre-mount check: UUID, type, and label in one line per device. Labels are only shown if they were set when the filesystem was created.

Version and usage metadata

sudo blkid -s VERSION /dev/sda1
sudo blkid -p -s USAGE /dev/sda1

VERSION shows filesystem version metadata when the filesystem reports it. USAGE (for example, "filesystem" or "raid") is most dependable with low-level probing (-p), and either field may be empty depending on the filesystem and your util-linux version.

Output Formats for Scripting and Reporting

sudo blkid -o value -s TYPE
sudo blkid -o value -s UUID
sudo blkid -o device
sudo blkid -o udev
sudo blkid -o export

• value prints only the values, with no field names.
• device lists device names that have recognized metadata.
• udev and export produce KEY=value pairs that are easy to parse in scripts.

For structured JSON, a reliable option is lsblk:

lsblk --json -o NAME,FSTYPE,LABEL,UUID,MOUNTPOINT

Run blkid --help and check the man page before relying on any JSON output mode from blkid itself, because support varies by version.

To save a report for a ticket or case file:

sudo blkid | tee blkid-report.txt

Low-Level Probing and Cache Behavior

By default, blkid may use a cache file. When you need fresh results, for example after a device changed or when you distrust stale data, probe directly:

sudo blkid -p /dev/sda1
sudo blkid -p -o full /dev/sda1

The -p option reads the device itself instead of relying on the cache. Supported output modes in this mode depend on your util-linux version.

You can also point blkid at an empty cache file so it does not rely on cached data:

sudo blkid -c /dev/null

Note that this does not "display cached metadata"; it does the opposite by bypassing the cache. To write the cache to a specific file, use -w with a valid path, and only when you actually need it:

sudo blkid -w /run/blkid/blkid.tab

Safe /etc/fstab Workflow with UUIDs

Using UUIDs in /etc/fstab avoids the device-name reordering problem from the opening scenario.

Step 1: Identify the correct device (replace with the real device shown by lsblk):

lsblk -f
sudo blkid /dev/sda1

Step 2: Add an entry using real values for the UUID, mount point, and filesystem type:

# UUID=your-actual-uuid /data ext4 defaults 0 2

Step 3: Verify before you reboot:

sudo findmnt --verify --verbose

This checks /etc/fstab for configuration problems. Warning: always back up /etc/fstab before editing, and test in a maintenance window. A bad entry can prevent a normal boot. For non-critical data disks, many admins add the nofail option so a missing disk does not halt startup.

Find the root filesystem UUID

findmnt -no SOURCE /
findmnt -no SOURCE,UUID /
sudo blkid

The first command identifies the root device, the second shows source and UUID where your findmnt version supports it, and blkid lets you match it manually.

Searching by Label, UUID, or Type

sudo blkid -t LABEL=DATA
sudo blkid -t UUID=your-actual-uuid
sudo blkid -t TYPE=ext4

These find devices matching a single token. Be careful with combined conditions. Passing -t twice, as in -t TYPE=ext4 -t LABEL=DATA, may not apply both filters in every version. A more dependable approach is to filter the output yourself:

sudo blkid | grep 'TYPE="ext4"' | grep 'LABEL="DATA"'

Incident Response and Forensics Use Cases

Triage a newly attached USB device

lsblk
sudo blkid /dev/sdb1

Replace /dev/sdb1 with the actual partition from lsblk. Identify the filesystem type and label first. If you must look inside unknown media, many analysts prefer a dedicated analysis workstation and read-only mounting so nothing on the device is modified or auto-processed:

sudo mount -o ro,noexec,nosuid,nodev /dev/sdb1 /mnt/evidence

Create the /mnt/evidence directory first, and follow your organization's evidence handling policy. For formal investigations, a hardware write blocker is the stronger control.

Check encrypted, LVM, and loop devices

sudo blkid /dev/sda2
sudo blkid /dev/loop0

An encrypted container normally shows its outer type (such as crypto_LUKS) rather than an inner filesystem. That is expected. A loop device shows metadata only if it contains a recognizable filesystem.

Build a quick storage inventory

sudo blkid
lsblk -o NAME,FSTYPE,LABEL,UUID,MOUNTPOINTS

This maps filesystem identifiers to the current layout, which is useful for baselining a server. Older util-linux versions use MOUNTPOINT instead of MOUNTPOINTS, so adjust if you see an error.

Teams that run endpoint detection and response tools can record this inventory as a baseline and investigate unexpected new filesystems or labels that appear later. blkid itself does not detect threats; it supplies context for analysts.

Common Pitfalls and Corrections

Pitfall	What to do instead
Running without root and getting partial output	Use sudo for complete results
Trusting cached data after hardware changes	Use blkid -p to probe directly
Combining multiple -t filters	Pipe through grep for reliable multi-condition matching
Hardcoding /dev/sdX in fstab	Use the filesystem UUID
Expecting inner details of encrypted volumes	Expect only the outer container type until it is unlocked
Assuming every option exists on every system	Check blkid --help and blkid --version

To confirm what your installed version supports:

blkid --help
blkid --version

Expert Tips

• Pair lsblk -f with blkid every time. Two views of the same data catch mistakes.
• Never copy a UUID from memory or an old ticket. Copy it from fresh output, then re-verify with findmnt --verify.
• Record device identifiers in your incident notes so timelines stay accurate even if device names change.
• Remember that duplicate UUIDs can appear on cloned disks or VM snapshots, which can confuse mounting. Check for duplicates before editing fstab.
• Treat metadata like labels as untrusted input when scripting. Anyone who controls a device can set its label.

Related Cybersecurity Topics You Should Explore

• Linux fsck Command Guide: Fix Disk Errors Without Data Loss
  
• Linux mkfs Command Cheat Sheet: Format Disks Safely (2026)
  
• Linux parted Command Cheat Sheet: Partition Disks Safely
  
• Linux fdisk Command Cheat Sheet: Partition Disks Safely (2026)
  
• Linux lsblk Command: Cheat Sheet for Disks, USB & Encryption
  
• Linux umount Command Cheat Sheet: Safe Unmount Without Data Loss
  
• Linux Mount Commands Cheat Sheet: Secure Mounts (2026)
  
• Linux du Command Cheat Sheet: Find Disk Space Hogs Fast
  
• Linux df Command Cheat Sheet: Fix Full Disk & Missing Logs
  
• Linux Disk Commands Cheat Sheet: df, du, mount, fsck (2026)
  
• Linux umask Cheat Sheet: 022 vs 027 vs 077 Explained

FAQ

What does the blkid command do in Linux?

It reports metadata about block devices, including UUID, filesystem type, and label, using the util-linux library.

Do I need sudo to run blkid?

Not always, but root access gives the most complete and reliable results.

What is the difference between blkid and lsblk?

lsblk shows the device tree and layout, while blkid focuses on identifying filesystem metadata. Using both together gives the clearest picture.

Why should I use UUIDs in /etc/fstab?

Device names like /dev/sdb1 can change between boots, while a filesystem UUID stays attached to the filesystem.

How do I get fresh results instead of cached ones?

Use sudo blkid -p /dev/sda1 to probe the device directly.

Can blkid show data inside an encrypted partition?

No. It typically shows only the outer container type until the volume is unlocked.

Is blkid useful for digital forensics?

Yes, as a quick identification step. It helps you document devices and choose safe handling, but it does not replace proper forensic tooling or evidence procedures.

Conclusion

The blkid command is small, fast, and easy to overlook, yet it prevents real problems: broken boots from bad fstab entries, mounting the wrong disk, and handling unknown media carelessly. Use it alongside lsblk and findmnt, prefer UUIDs, probe directly when you need fresh data, and always verify your version's supported options. Build this into your runbooks and your Linux storage work gets safer and more repeatable.

Analysis based on SOC monitoring and public threat intelligence review.