Linux Disk Commands Cheat Sheet: df, du, mount, fsck (2026)

Linux Disk Management Cheat Sheet: df, du, mount, lsblk, fdisk, parted, mkfs, fsck, blkid and tune2fs

Quick Answer
Use df and du to find what is filling a disk, lsblk and blkid to identify devices, and mount options like noexec and nosuid to harden Linux servers and preserve evidence.

Last verified: October 3, 2026. Commands tested against current util-linux, e2fsprogs, and parted behavior on mainstream distributions.

It is 2:07 AM and the pager goes off. A production Linux server is reporting "No space left on device," and the application has stopped writing logs. The on-call engineer assumes a runaway debug log. Ten minutes with df and du tell a different story: a 40 GB archive sitting in a hidden directory under /var/tmp, created two days earlier by an account that should not have been active. The disk was full because someone was staging data for exfiltration.

That is why disk management is more than sysadmin housekeeping. For anyone doing incident response and digital forensics, or Linux server hardening, these commands are how you see what is on a system, what is attached to it, and how it is mounted. This cheat sheet is organized the way you would use it on a real shift.

Table of Contents

• Why Disk Commands Matter for Security Teams
• Finding What Is Filling the Disk: df and du
• Identifying Devices: lsblk and blkid
• Mounting and Unmounting Safely
• Partitioning: fdisk and parted
• Filesystems: mkfs and fsck
• Tuning ext Filesystems with tune2fs
• Hardening Mounts and Detecting Changes
• Quick Reference Table
• Expert Tips
• FAQ

Why Disk Commands Matter for Security Teams

SOC analysts tend to live in SIEM dashboards, but the endpoint is where many investigations end. Disk-related signals show up in several places:

• Sudden disk or inode exhaustion, often from log flooding, staging archives, or cryptominer artifacts
• New block devices appearing, such as USB storage on a server that should never have one
• Partitions mounted without restrictive options, letting binaries run from locations like /tmp
• Filesystem corruption after an unclean shutdown or tampering

One note on the input topic: the command is tune2fs (ext2/3/4), not "tune3fs." There is no separate tune3fs tool, and it works on ext3 and ext4 as well.

Finding What Is Filling the Disk: df and du

df reports free space per mounted filesystem. du reports how much space files and directories consume. Use df to find which filesystem is full, then du to find the culprit.

df -hT

Shows sizes in human-readable units plus filesystem type. Run this first to see which mount point is near 100%.

df -i

Shows inode usage. A disk can be "full" with plenty of free space if millions of tiny files have exhausted inodes. This is common with mail queues, session files, and some abuse scenarios.

du -xh --max-depth=1 /var | sort -rh | head -10

Lists the largest directories one level deep, staying on a single filesystem (-x). Expected output is a ranked list, with the biggest consumer on top. Repeat on the top entry to drill down.

du -ah /var/tmp 2>/dev/null | sort -rh | head -20

Lists the largest individual files under a path, hiding permission errors. Look for unexpected archives (.tar, .zip, .7z), database dumps, and hidden dot-directories.

lsof +L1

Finds files that were deleted but are still held open by a process. This explains the classic mystery where df says the disk is full but du cannot find the space. It is also worth reviewing during an investigation, since deleted-but-running binaries are a known evasion pattern.

Identifying Devices: lsblk and blkid

Before you partition, format, or mount anything, confirm exactly which device you are looking at. Mistakes here are expensive.

lsblk -f

Displays a tree of disks and partitions with filesystem type, label, UUID, and mount point.

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

A custom column view that is easy to paste into an incident ticket.

sudo blkid /dev/sdb1

Prints the UUID, filesystem type, and label for one device. Use UUIDs in /etc/fstab instead of names like /dev/sdb1, because device names can change between boots.

Mounting and Unmounting Safely

findmnt

Shows all mounts as a tree, including options. It is easier to read than the output of plain mount.

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

Mounts a device read-only with execution, setuid, and device-file support disabled. This is a sensible default when you are inspecting an unknown or suspect disk. For ext4 volumes that may need forensic care, adding noload avoids replaying the journal, which would otherwise write to the disk.

sudo blockdev --setro /dev/sdb

Marks the whole device read-only at the kernel level. Many examiners prefer a hardware write blocker for evidence, but this is a useful extra layer in lab and triage work.

sudo umount /mnt/evidence

Unmounts the filesystem. If you get "target is busy," identify what is using it:

sudo fuser -vm /mnt/evidence

Lists the processes holding the mount open. Resolve those first. A lazy unmount (umount -l) works, but it only detaches the mount point and can hide the fact that something is still using it, so treat it as a last resort.

Partitioning: fdisk and parted

Warning: Partitioning commands can destroy data. Always confirm the target with lsblk first, and work on a test disk if you are learning.

sudo fdisk -l

Lists all disks and their partition tables. This is read-only and safe.

sudo fdisk /dev/sdb

Opens the interactive editor. Common keys: p to print, n for a new partition, g for a new GPT table, w to write changes. Nothing is saved until you press w, so q safely exits.

sudo parted -l

Lists devices and partition tables, including GPT disks. Read-only.

sudo parted /dev/sdb --script mklabel gpt mkpart primary ext4 1MiB 100%

Destructive: this writes a new GPT label, wiping the existing partition table on /dev/sdb. Unlike fdisk, parted applies changes immediately. Use GPT for disks larger than 2 TB.

Filesystems: mkfs and fsck

Warning: mkfs erases whatever filesystem is on the target partition. Verify the device name twice.

sudo mkfs.ext4 -L datavol /dev/sdb1

Creates an ext4 filesystem with the label "datavol." Use mkfs.xfs for XFS, which is the default on several enterprise distributions.

sudo fsck -n /dev/sdb1

Runs a check in no-change mode (answers "no" to every repair prompt). The filesystem must be unmounted. It is the safe way to see whether corruption exists before you let the tool modify anything.

sudo fsck -f /dev/sdb1

Forces a full check and may repair errors. Take an image or backup first if the data matters, and never run it on a mounted filesystem. According to the fsck man page, exit code 0 means no errors, 1 means errors were corrected, 2 means a reboot is required, 4 means errors were left uncorrected, and 8 means an operational error. XFS uses xfs_repair instead.

Tuning ext Filesystems with tune2fs

sudo tune2fs -l /dev/sdb1

Prints the superblock details: UUID, mount count, last mount time, last checked time, and features. The last-mounted and last-checked fields are useful timeline clues during an investigation.

sudo tune2fs -L newlabel /dev/sdb1

Changes the volume label.

sudo tune2fs -m 1 /dev/sdb1

Lowers the reserved-block percentage to 1%. Ext filesystems reserve 5% by default for root, which is wasteful on large data volumes but worth keeping on system partitions.

sudo tune2fs -e remount-ro /dev/sdb1

Sets the error behavior so the filesystem remounts read-only if the kernel detects errors, limiting further damage.

Hardening Mounts and Detecting Changes

Mount options are one of the cheapest defensive controls on Linux. A typical hardened /etc/fstab pattern looks like this:

UUID=your-uuid-here  /data  ext4  defaults,nodev,nosuid,noexec  0  2
tmpfs  /tmp  tmpfs  defaults,nodev,nosuid,noexec  0  0

Replace the UUID with the value from blkid. Test before rebooting:

sudo findmnt --verify
sudo mount -a

A mistake in fstab can drop a server into emergency mode on the next boot, so always validate first. CIS Benchmarks for Linux recommend separate partitions and restrictive options for locations such as /tmp, /var, and /home. As analysts note, noexec is not a complete barrier: a script can still be run by passing it to an interpreter, so treat it as one layer in a defense-in-depth design alongside file integrity monitoring and EDR.

Detecting New Mounts and Devices

If you run the Linux audit framework, a rule can log mount activity:

-a always,exit -F arch=b64 -S mount,umount2 -k mounts

Add it to a file under /etc/audit/rules.d/, load it with augenrules --load, and review hits with:

sudo ausearch -k mounts -i

Kernel messages are another quick check for newly attached storage:

sudo journalctl -k --since "1 hour ago" | grep -i "sd[b-z]"

Feed these events into your SIEM so an unexpected USB mount on a production server becomes an alert instead of a surprise.

Quick Reference Table

Task	Command	Risk
Disk space by filesystem	df -hT	Read-only
Inode usage	df -i	Read-only
Largest directories	du -xh --max-depth=1 /path | sort -rh	Read-only
Device tree with UUIDs	lsblk -f	Read-only
Device UUID and type	blkid /dev/sdX1	Read-only
Show mounts	findmnt	Read-only
Mount read-only, no exec	mount -o ro,noexec,nosuid,nodev	Low
List partition tables	fdisk -l / parted -l	Read-only
Create partition table	fdisk / parted mklabel	Destructive
Create filesystem	mkfs.ext4	Destructive
Check filesystem (dry run)	fsck -n	Read-only
Repair filesystem	fsck -f	Can modify data
View superblock info	tune2fs -l	Read-only

Expert Tips

• Triage in order: df -hT, then df -i, then du, then lsof +L1. This sequence catches most "disk full" cases quickly.
• Record before you touch: save lsblk -f, findmnt, and tune2fs -l output to your case notes before any change.
• Never repair the original: for suspected compromise, image the disk and run fsck only on a copy.
• Use UUIDs in fstab and keep a backup copy of the file before editing.
• Baseline your mounts: if you know what normal looks like, drift is easy to spot.

Related Cybersecurity Topics You Should Explore

• Linux umask Cheat Sheet: 022 vs 027 vs 077 Explained
  
• Linux chgrp Cheat Sheet (2026): Commands, Examples & Audit Tips
  
• Linux chown Command Cheat Sheet: 40+ Examples (2026)
  
• Linux chmod Cheat Sheet: Stop Using 777 (Safer Fixes)
  
• OnePlus 15 Root Exploit: Zero-Permission Apps Can Take Full Control
  
• One Misconfigured chmod Command Gave Attackers Root Access
  
• How SOC Analysts Use sed to Catch Attacks Before the SIEM Does
  
• Linux tr Command Tutorial: Fix Messy SOC Logs in Seconds

FAQ

What is the difference between df and du?

df asks the filesystem how much space is used and free overall. du walks directories and adds up file sizes. They can disagree when deleted files are still held open by processes.

Is it tune2fs or tune3fs?

It is tune2fs. The same tool manages ext2, ext3, and ext4 filesystems. XFS uses xfs_admin instead.

Should I use fdisk or parted?

Modern fdisk supports both MBR and GPT. parted is handy for scripting and large disks, but it applies changes immediately, so it demands extra care.

Can I run fsck on a mounted filesystem?

No. Running repairs on a mounted filesystem can cause serious corruption. Unmount it first, or boot into recovery mode for the root filesystem.

Why use UUIDs instead of /dev/sdb1 in fstab?

Device names can change when disks are added, removed, or detected in a different order. UUIDs stay with the filesystem.

Does noexec stop malware?

It blocks direct execution of binaries from that mount, which stops many simple attacks. It does not stop everything, so combine it with monitoring, least privilege, and endpoint protection.

Conclusion

The incident at the start of this article was solved by a handful of commands: df to find the full filesystem, du to find the hidden archive, and lsblk and findmnt to confirm nothing unexpected was attached. The same toolkit, used with restrictive mount options and audit logging, turns routine disk management into a security control. Bookmark this cheat sheet, practice the read-only commands first, and treat anything that writes to a disk with caution.

Analysis based on SOC monitoring experience and public Linux documentation review.