Linux fsck Command Guide: Fix Disk Errors Without Data Loss

Linux fsck Command Guide: Safe Filesystem Repair After Crashes and Incidents

Quick Answer
fsck checks and repairs Linux filesystems, but only on unmounted disks. Run it read-only with -n first, back up or image the disk, and use -y only when you accept the risk of data loss.

Last verified: October 8, 2026, against the util-linux fsck, e2fsprogs, xfsprogs, and btrfs-progs documentation.

Picture a scenario SOC and infrastructure teams know well. A server loses power at 2 a.m. It reboots into emergency mode, the monitoring dashboard is red, and someone on the call says, "Just run fsck -y on it." That one command might fix the problem. It might also silently delete the files you needed for a digital forensics review, or make a failing drive worse. This guide covers what fsck does, which of the common cheat-sheet commands are safe, and how to use it during a real outage or incident without making things worse.

Table of Contents

• What fsck Actually Does
• Step Zero: Identify the Device and Filesystem
• Core fsck Commands and Flags
• Read-Only First, Repair Second
• Filesystem-Specific Checkers (ext4, FAT, XFS, Btrfs)
• Checking Multiple Filesystems and /etc/fstab
• Logging Output and Reading Exit Codes
• fsck During Incident Response and Forensics
• Detecting Corruption Early and Preventing It
• Expert Tips
• FAQ

What fsck Actually Does

fsck (file system consistency check) is a front-end. Per the util-linux documentation, it inspects the filesystem type and calls the matching checker, such as fsck.ext4 (which is e2fsck), fsck.fat, or fsck.xfs. It verifies that the metadata is consistent: inodes, directory entries, block allocation maps, and journal state.

It does not recover deleted files, and it does not "scan for viruses." It only makes the structure self-consistent, and sometimes that means discarding damaged data. This is why data integrity and disaster recovery planning matters: fsck is a last-resort repair tool, not a backup strategy.

Warning: Never run a repairing fsck on a mounted filesystem. Doing so can corrupt it badly. Always unmount first, or boot from rescue media for the root filesystem.

Step Zero: Identify the Device and Filesystem

Device names like /dev/sda1 and /dev/sdb1 in tutorials are examples. On your system, names can change between boots, especially with USB drives. Running a repair against the wrong device is a common and painful mistake. Confirm before you act:

lsblk -f

Lists block devices with filesystem type, label, UUID, and mount point. Use it first, every time.

sudo blkid /dev/sda1

Prints the filesystem type, UUID, and related metadata for one partition. Expected output looks like /dev/sda1: UUID="..." TYPE="ext4".

findmnt /dev/sda1

Shows where the device is mounted. No output means it is not currently mounted, which is what you want before a repair.

Core fsck Commands and Flags

These are the flags you will use most often, per the util-linux man page. Flags that fsck does not recognize are passed through to the filesystem-specific checker.

Flag	What it does	Risk level
-n	Reports problems, makes no changes	Lowest
-f	Forces a full check even if the filesystem looks clean	Low (read-heavy)
-t TYPE	Selects the filesystem type/checker	Low
-v	More detailed output from the checker	Low
-V	Shows the commands fsck itself executes	Low
-r	Reports statistics per device when finished (not an interactive repair mode in util-linux fsck)	Low
(no flag)	Interactive: asks before each fix	Medium
-y	Answers "yes" to every repair prompt	High
-A	Checks filesystems listed in /etc/fstab	Depends on other flags
-R	With -A, skips the root filesystem	Low
-M	Skips filesystems that are currently mounted	Low

A common cheat-sheet mistake: many lists describe fsck -r as "interactive repair." In the util-linux fsck, interactive prompting is already the default when you pass no repair flag, and -r prints statistics. The one place -r means "repair interactively" is fsck.fat (dosfstools). Always check man fsck for your distribution.

fsck --version
fsck --help

Shows the installed util-linux version and the supported options. Run it on unfamiliar systems before relying on a flag.

Read-Only First, Repair Second

The habit that separates cautious admins from regretful ones is a read-only pass before any repair.

sudo umount /dev/sda1
sudo fsck -n /dev/sda1

Unmounts the partition and reports problems without modifying anything. Expected output on a healthy ext4 volume ends with a summary of files, blocks, and "clean" or "no errors." If you run -n on a mounted filesystem, the checker may report phantom errors because data is changing underneath it. That output is not trustworthy.

sudo fsck -f /dev/sda1

Forces a full check after an unexpected shutdown or when corruption is suspected. It will prompt before each fix, which gives you a chance to stop if the volume of damage looks alarming.

Warning: -y removes the prompts and accepts every repair automatically. Some of those repairs delete or relocate damaged inodes and data. The same applies to the often-listed "safe" combination below. It is not safe in any data-preservation sense.

sudo fsck -f -y /dev/sda1

Forces the check and accepts every repair automatically. Use it only after you have a backup or disk image, or when the data is expendable (a rebuildable cache volume, for example). Expected output lists each fix applied, often followed by "FILE SYSTEM WAS MODIFIED."

Filesystem-Specific Checkers (ext4, FAT, XFS, Btrfs)

You can call the underlying checker directly, which is useful when you want that tool's own flags.

sudo fsck -t ext4 /dev/sda1
sudo fsck.ext4 -n /dev/sda1
sudo fsck.ext4 -f /dev/sda1

The first command selects the ext4 checker via the front-end. The second and third call it directly, read-only and forced. fsck.ext2, fsck.ext3, and fsck.ext4 all map to e2fsck.

sudo fsck.fat -n /dev/sdb1

Checks a FAT volume (common on USB drives and EFI partitions) without writing changes. Per the dosfstools documentation, -r here enables interactive repair, unlike generic fsck.

sudo xfs_repair -n /dev/sda1

XFS does not use a repairing fsck at boot. fsck.xfs is effectively a no-op, and the supported tool is xfs_repair on an unmounted filesystem. The -n flag means "no modify." Warning: the -L option zeroes the metadata log and can lose recent changes, so treat it as a last resort after the volume refuses to mount and you have an image.

sudo btrfs check /dev/sda1

Btrfs has its own checker, read-only by default. The btrfs-progs documentation warns that --repair is dangerous and should be used only with backups and, ideally, expert guidance.

ls /sbin/fsck.*

Lists the filesystem-specific checkers installed on the machine. On systems where /sbin is a symlink to /usr/sbin, this still works.

Checking Multiple Filesystems and /etc/fstab

sudo fsck -A -R -V

Walks the entries in /etc/fstab, skips the root filesystem (-R), and prints the checker commands it runs (-V). Only entries with a non-zero "pass" field in fstab are processed.

sudo fsck -A -M

Checks fstab filesystems but skips anything currently mounted. This is a safer pattern for maintenance windows on a live server.

sudo fsck /dev/sda1 /dev/sda2

Checks several specified filesystems in one command.

sudo fsck UUID=your-uuid-here

fsck accepts UUID= and LABEL= specifiers, which is more reliable than device names that can shift between reboots. Get the UUID from blkid.

The root filesystem: you cannot safely repair it while it is mounted read-write. Boot from a live USB, or on systemd-based distributions request a check at the next boot with the kernel parameters fsck.mode=force and fsck.repair=yes (per the systemd-fsck documentation).

Logging Output and Reading Exit Codes

sudo fsck -v /dev/sda1 2>&1 | tee fsck-report.txt

Displays the output and saves a copy for ticketing or later review. Note that piping hides fsck's exit code from the shell. If you need both, run it without the pipe or inspect ${PIPESTATUS[0]} in bash.

sudo fsck /dev/sda1
echo $?

Runs a check and prints the exit status. Per the fsck man page, the code is a sum of these values:

Code	Meaning
0	No errors
1	Errors corrected
2	System should be rebooted
4	Errors left uncorrected
8	Operational error
16	Usage or syntax error
32	Canceled by user request
128	Shared-library error

After any repair, run the check a second time. A clean second pass (exit code 0) is your confirmation that the repair worked.

fsck During Incident Response and Forensics

This is where many guides stop and where incident response practice begins. fsck writes to the disk. Even a "successful" repair changes metadata, timestamps, and sometimes file contents. If the machine is part of a security investigation (suspected ransomware, unauthorized access, insider activity), that matters.

• Image first. Make a bit-for-bit copy of the affected disk with a tool such as ddrescue or dd to separate storage, then work on the copy.
• Mount evidence read-only. Use mount -o ro,noload on ext4 so the journal is not replayed against the original.
• Document everything. Save command output with timestamps and note who ran what. Chain-of-custody gaps are hard to explain later.
• Do not assume corruption means hardware failure. Filesystem damage can result from a crash, a failing drive, or deliberate tampering. fsck cannot tell you which.

Detecting Corruption Early and Preventing It

Filesystem problems usually announce themselves before a hard failure. Watch for kernel log messages such as "EXT4-fs error," "I/O error," or "Buffer I/O error."

sudo dmesg | grep -i -E "ext4-fs error|i/o error"
sudo journalctl -k -p err --since "1 day ago"

Searches the kernel ring buffer and the journal for storage-related errors. Expected output is empty on a healthy system.

sudo smartctl -H /dev/sda

Reports the drive's overall SMART health (requires the smartmontools package). A failing result means replace the drive, not just repair the filesystem.

Prevention is mostly boring and effective: tested backups, uninterruptible power supplies for servers, proper shutdowns, and alerting on storage errors in your SIEM or monitoring stack. These steps reduce risk but cannot guarantee a filesystem will never need repair.

Expert Tips

• Make lsblk -f a reflex before every disk command.
• Run -n first. If it reports thousands of errors, stop and image the disk before repairing.
• Repeated errors on the same device after a repair point to failing hardware.
• For XFS and Btrfs, use their native tools and read their repair warnings.
• Keep a rescue USB with matching tool versions for root filesystem repairs.

Related Cybersecurity Topics You Should Explore

• 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
  
• Linux chgrp Cheat Sheet (2026): Commands, Examples & Audit Tips

FAQ

Can I run fsck on a mounted filesystem?

Not for repairs. A read-only -n check may run but can show false errors. Unmount first, or use rescue media.

Is fsck -y safe?

It is convenient, not safe. It accepts every fix automatically, including ones that discard damaged data. Back up or image first.

What is the difference between fsck and fsck.ext4?

fsck is a wrapper that picks the right checker. fsck.ext4 calls the ext4 checker (e2fsck) directly.

Does fsck work on XFS?

Not in the traditional sense. Use xfs_repair on an unmounted XFS volume.

Will fsck recover deleted files?

No. It repairs structure. For deleted files, use backups or dedicated recovery tools, and stop writing to the disk.

How long does fsck take?

It depends on volume size, file count, and disk speed. Large volumes can take hours, so plan maintenance windows accordingly.

What does exit code 4 mean?

Errors remain uncorrected. Re-run the check, review the output, and consider a disk image and hardware diagnostics.

Conclusion

fsck is one of the most useful commands on a Linux system and one of the easiest to misuse. Identify the device, unmount it, run read-only first, capture the output, and treat -y as a decision rather than a default. During security incidents, preserve evidence before you repair anything. A few minutes of caution is cheaper than a restore from backup, or an investigation you cannot defend.

Analysis based on SOC monitoring experience and review of official util-linux, e2fsprogs, xfsprogs, and btrfs-progs documentation.