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:
| Option | Description |
|---|---|
-A |
Check all filesystems listed in /etc/fstab |
-C |
Show a progress bar during the check |
-l |
Lock the device to prevent other programs from accessing it during the check |
-M |
Skip mounted filesystems (do not check them) |
-N |
Dry run – show what would be done without making any changes |
-P |
Check filesystems in parallel, including root |
-R |
Skip the root filesystem (use with -A) |
-r |
Show per-device statistics |
-T |
Suppress the title banner |
-t fstype |
Check only a specific filesystem type (e.g., ext4) |
-V |
Verbose — describe what is being done |
-y |
Automatically answer “yes” to all repair prompts |
-n |
Automatically answer “no” to all repair prompts (read-only check) |
-f |
Force check even if the filesystem appears clean |
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
Shiftkey 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.
