How to Use fsck to Check and Repair Linux Filesystem Errors

Linux filesystems are responsible for organizing how data is stored and retrieved. Over time – due to sudden power failures, forced shutdowns, hardware issues, or software bugs – a filesystem can become corrupted, and certain parts of it may become inaccessible.

When that happens, you need a reliable way to detect and fix those inconsistencies before they cause data loss or system instability. This is where fsck (File System Consistency Check) comes in.

In this article, we’ll cover everything you need to know about fsck from basic usage to running it safely on root and production partitions.

What is fsck in Linux?

fsck is a built-in Linux utility used to check and repair filesystem inconsistencies. It works similarly to chkdsk on Windows. The tool can be run automatically during system boot or manually by the system administrator.

Depending on the filesystem type (ext2, ext3, ext4, xfs, etc.), fsck calls the appropriate backend checker, for example, e2fsck for ext-family filesystems.

When Should You Run fsck?

Here are the most common scenarios where running fsck is necessary or recommended:

• The system fails to boot or drops into emergency/rescue mode.
• You see Input/Output errors when reading or writing files.
• A drive (HDD, SSD, USB flash drive, or SD card) isn’t working as expected.
• After an unclean shutdown – power loss, kernel panic, or forceful reboot.
• Routine maintenance – periodic integrity checks on critical servers.
• Filesystem reports corruption in kernel logs (dmesg output).

Production Tip: Always check /var/log/syslog or run dmesg | grep -i error before scheduling an fsck, which helps you understand the scope of the problem before diving in.

fsck Command Syntax:

fsck [options] [filesystem]

fsck must be run with superuser (root) privileges, and here are the most important options:

How to Check Which Filesystem Type You Have

Before running fsck, confirm the filesystem type of your partition:

lsblk -f
Or
blkid /dev/sdb1

This is important because fsck delegates to type-specific tools like e2fsck (ext4), fsck.xfs, fsck.vfat, etc.

Important: Never Run fsck on a Mounted Partition

Running fsck on a mounted partition can cause severe data corruption, so always unmount the partition first.

To check if a partition is mounted:

mount | grep /dev/sdb

If it’s mounted, unmount it:

umount /dev/sdb1

If the device is busy, find what’s using it using lsof command:

lsof /dev/sdb1

Then try a lazy unmount:

umount -l /dev/sdb1

Running fsck to Check and Repair a Partition

To perform a basic filesystem check, run the following command, which will check and prompt you interactively to fix each error it finds.

fsck /dev/sdb1

For production servers where you want to automate repairs, use the -y flag.

fsck -y /dev/sdb1

To see what fsck would do without touching anything:

fsck -N /dev/sdb1

Production Tip: Always do a dry run first on critical systems before committing to repairs. Review the output, then decide if you want to proceed.

If the filesystem was marked as clean, but you still suspect issues:

fsck -f /dev/sdb1

To check a specific filesystem type:

fsck -t ext4 /dev/sdb1

To check all filesystems (excluding root), use the -A flag that reads entries from /etc/fstab, and -R skips the root filesystem.

fsck -AR -y

You can also use the following command to verbose output with a progress bar:

fsck -C -V /dev/sdb1

This is useful for large drives where you want to monitor progress.

Understanding fsck Exit Codes

After running fsck, it returns an exit code that tells you what happened. You can check it with echo $? right after running the command.

0    - No errors detected
1    - Filesystem errors were corrected
2    - System should be rebooted
4    - Filesystem errors left uncorrected
8    - Operational error
16   - Usage or syntax error
32   - Checking was canceled by user request
128  - Shared library error

Exit codes can be combined (added together). For example, an exit code of 3 means errors were corrected (1) and a reboot is required (2).

Production Tip: In scripts and cron jobs, always capture and evaluate the fsck exit code to trigger alerts or automatic reboots when needed.

fsck -y /dev/sdb1
EXIT_CODE=$?

if [ $EXIT_CODE -ge 4 ]; then
    echo "ALERT: Filesystem errors could not be corrected on /dev/sdb1" | mail -s "fsck Alert" [email protected]
fi

How to Run fsck on the Root Partition (/)

You cannot run fsck on a mounted root partition, but the following are three reliable methods to handle it.

Method 1: Force fsck on Next Boot

The simplest approach is to create a forcefsck flag file in the root:

touch /forcefsck

Then schedule a reboot:

reboot

During the next boot, the system will automatically run fsck on the root filesystem before mounting it. After the system comes back up, verify and remove the flag file to avoid triggering fsck on every boot:

ls /forcefsck
rm /forcefsck

Note: On systemd-based systems (RHEL 7+, Ubuntu 16.04+), the forcefsck method may not work. Use the method below instead.

Method 2: Force fsck via tune2fs (ext4)

For ext4 filesystems, you can force an fsck on the next reboot using tune2fs, which will sets the mount count to 1, which triggers fsck at next boot. After the check, the mount count resets automatically.

tune2fs -C 1 /dev/sda1

You can also set a maximum mount count after which fsck is forced automatically:

tune2fs -c 30 /dev/sda1

Method 3: Run fsck in Rescue/Recovery Mode

This method gives you full manual control and is recommended for serious corruption cases.

• Step 1: Reboot the system and during boot, hold the Shift key to bring up the GRUB menu.
• Step 2: Select “Advanced options” from the GRUB menu.
• Step 3: Choose “Recovery mode” for your kernel version.
• Step 4: In the recovery menu, select “fsck“.
• Step 5: When prompted to remount the root filesystem, select “Yes“.
• Step 6: Once fsck completes, select “Resume” to continue normal boot.

How to Run fsck on LVM and Software RAID Volumes

For LVM logical volumes, first identify the volume:

lvdisplay

Deactivate it before running fsck:

lvchange -an /dev/vg_data/lv_data
fsck -y /dev/vg_data/lv_data
lvchange -ay /dev/vg_data/lv_data

For a RAID member, check the underlying block device:

fsck -y /dev/md0

Production Warning: Be extra cautious with RAID arrays. Ensure the array is in a healthy state (cat /proc/mdstat) before running fsck. A degraded array should be rebuilt first.

How to Schedule Regular fsck Checks

On production servers, it’s good practice to schedule periodic fsck runs rather than waiting for problems to occur.

Using tune2fs for Automatic Checks (ext4)

Set a time-based check interval (e.g., every 6 months):

tune2fs -i 6m /dev/sda1

Set a mount-count-based check (e.g., every 30 mounts):

tune2fs -c 30 /dev/sda1

Verify the settings:

tune2fs -l /dev/sda1 | grep -i "mount count\|check interval"

View Filesystem Health Summary

tune2fs -l /dev/sda1 | grep -E "Filesystem state|Last checked|Mount count|Maximum mount"

Checking fsck Logs

After fsck runs (either at boot or manually), you can review what it did:

# On RHEL/CentOS/Rocky Linux
grep -i fsck /var/log/messages

# On Ubuntu/Debian
grep -i fsck /var/log/syslog

# Systemd journal
journalctl -b | grep -i fsck

Quick Reference: fsck Command Examples

# Check a partition interactively
fsck /dev/sdb1

# Auto-repair all errors
fsck -y /dev/sdb1

# Dry run (no changes)
fsck -N /dev/sdb1

# Force check even if filesystem looks clean
fsck -f /dev/sdb1

# Check all filesystems except root
fsck -AR -y

# Verbose check with progress bar
fsck -C -V /dev/sdb1

# Check only ext4 filesystems
fsck -t ext4 -A -y

Conclusion

fsck is one of the most critical tools in a Linux sysadmin’s toolkit. Whether you’re dealing with a corrupted partition after a power outage, running routine integrity checks on a production server, or troubleshooting a system that won’t boot – knowing how to use fsck correctly can save you from serious data loss and unplanned downtime.

The key rules to remember:

• Never run fsck on a mounted partition.
• Always do a dry run (-N) first on critical systems.
• Capture exit codes in scripts to automate alerts and reboots.
• Schedule periodic checks using tune2fs on important filesystems.

If you have any questions about using fsck or ran into a specific error, feel free to share it in the comments below.