fsck Command: Tutorial & Examples

Check and repair file systems for consistency and integrity

The fsck command (file system consistency check) is a vital utility in Linux and Unix systems used to verify and repair inconsistencies in file systems. It helps maintain filesystem integrity by detecting and correcting structural problems that can arise from improper shutdowns, hardware failures, or software errors. This article provides an in-depth overview of fsck, explains how it works, common usage scenarios, detailed examples, and important considerations for safe and effective use.

How fsck Works

The fsck utility performs a thorough examination of a file system's metadata and structure. It typically follows these steps:

Checking Blocks and Sizes: Verifies that data blocks and inode sizes are within valid ranges.
Checking File Tree: Examines directory structure for correctness and consistency.
Checking Reference Counts: Validates that link counts on inodes match actual references.
Adjusting and Repairing: Attempts to fix detected inconsistencies, such as orphaned inodes or incorrect metadata.

When invoked, fsck usually determines the filesystem type and delegates checks to the appropriate filesystem-specific checker (e.g., fsck.ext4 for EXT4 filesystems). This modular approach ensures that filesystem-specific intricacies are handled properly.

On many Linux systems, fsck runs automatically during boot if the system detects an unclean shutdown or scheduled filesystem checks are due. However, administrators can run fsck manually as needed.

What fsck Is Used For

fsck is primarily used to:

Detect and repair filesystem corruption caused by improper shutdowns, crashes, or hardware issues.
Verify the integrity of filesystems after disk errors or suspected data corruption.
Check raw partitions or filesystem images for consistency.
Perform scheduled maintenance checks to prevent data loss.

It is particularly useful for recovering from disk-error situations and preventing further damage or data loss due to undetected filesystem issues.

Why fsck Is Important

File systems can become corrupted due to sudden power loss, hardware failures, or software bugs. Such corruption may lead to data loss, system instability, or inability to mount filesystems. The fsck command is essential for:

Maintaining data integrity by identifying and fixing inconsistencies.
Preventing system crashes or boot failures caused by corrupted filesystems.
Ensuring reliable operation of critical servers by regular health checks.
Recovering from filesystem problems that cannot be fixed by normal operations.

Using fsck carefully can save significant troubleshooting time and avoid costly data recovery efforts.

How to Use fsck

Before running fsck, it is critical to ensure the target filesystem is not mounted or is mounted read-only to avoid potential data corruption. Use the umount command to unmount the filesystem if necessary.

Basic usage example:

sudo fsck /dev/sda1

This command checks the filesystem on the /dev/sda1 partition and prompts for repair if needed.

To check the filesystem without making any changes, use the -N (no-action) option:

sudo fsck -N /dev/sda1

This displays what actions would be taken without actually performing them.

To force a check even if the filesystem appears clean, use the -f option:

sudo fsck -f /dev/sda1

During system boot, fsck is often run with the -A option to check all filesystems listed in /etc/fstab:

sudo fsck -A

You can also skip checking the root filesystem with -R:

sudo fsck -A -R

Common Command Line Parameters

Here are some frequently used fsck options:

-A: Check all filesystems listed in /etc/fstab. Useful for batch checking during boot.
-R: When used with -A, skips checking the root filesystem.
-N: Show what would be done without actually performing any operations.
-f: Force checking even if the filesystem seems clean.
-y: Automatically answer yes to all prompts (use with caution).
-C: Display progress bar during checking.
-t [fstype]: Specify filesystem type explicitly if fsck cannot detect it.

Example forcing automatic repair with progress:

sudo fsck -f -y -C /dev/sda1

This forces a check, automatically repairs issues, and shows progress output.

Practical Examples Using fsck

Example 1: Checking and repairing a partition interactively

sudo fsck /dev/sdb1

Sample output when errors are found:

fsck from util-linux 2.36
e2fsck 1.45.6 (20-Mar-2020)
/dev/sdb1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Inode 12345 extent tree (at level 0) could be narrower.  Fix<y>? y
/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb1: 12345/65536 files (0.1% non-contiguous), 234567/262144 blocks

You will be prompted to fix errors interactively.

Example 2: Dry run without changes

sudo fsck -N /dev/sdb1

Output shows what would be done without making changes.

Example 3: Checking all filesystems at once except root

sudo fsck -A -R

Useful during maintenance windows for batch filesystem checks.

Potential Problems and Pitfalls

Running fsck on Mounted Filesystems: Running fsck on a mounted filesystem, especially mounted read-write, can cause severe data corruption. Always unmount or remount as read-only before running fsck.
Data Loss During Repairs: Repairing filesystems may result in some data loss, especially if directory structures or inodes are damaged. Always back up important data before running repairs.
Virtual Filesystems: Filesystems like /proc, /sys, and /dev are virtual and should never be checked with fsck.
Unsupported Filesystems: Some filesystems have their own specific tools and may not be fully supported by generic fsck. For instance, fsck delegates to filesystem-specific checkers like fsck.ext4, fsck.xfs (which only reports errors), or fsck.btrfs (which uses other tools).
Ignoring Prompts: Using the -y option forces automatic answers but can cause undesired data loss if you are not careful.

Common Errors and Troubleshooting

"fsck: Device or resource busy"
Occurs when trying to run fsck on a mounted device. Solution: unmount the device first.
"fsck.ext4: Bad magic number in super-block"
Indicates filesystem corruption or wrong device. Verify the device and filesystem type.
Filesystem fails to repair or boot still fails after fsck
May require advanced recovery tools or restoring from backups.
Permission denied
Running fsck usually requires superuser privileges. Use sudo as necessary.

Use system logs (journalctl, /var/log/syslog) for additional error information.

Advanced Usage

Scripting and Automation: fsck can be integrated into maintenance scripts or scheduled via cron to run periodic checks on non-critical filesystems.
Forcing fsck at Boot: Create an empty file /forcefsck (on some distros) to force a filesystem check on next reboot.
Using fsck with Remote Filesystems: fsck does not support checking remote filesystems like NFS; these should be checked on the server side.
Filesystem-Specific Options: Some filesystem checkers support extra options. For example, fsck.ext4 allows -c to check for bad blocks.

Example forcing fsck on next boot (on Debian/Ubuntu):

sudo touch /forcefsck
sudo reboot

Security and Safety Considerations

Always ensure filesystems are unmounted or mounted read-only before running fsck to avoid corruption.
Backup important data before running repair operations.
Avoid running fsck on critical production systems without prior testing.
Be cautious with automatic repair options (-y) as they may cause unintended data loss.
Verify device names carefully to prevent accidental damage.