Fsck: Complete Guide to Checking and Repairing Linux Filesystems

Introduction / Why This Is Needed

The file system is the foundation of data storage on disk. Over time, due to power outages, hardware errors, or software bugs, inconsistencies can accumulate: lost blocks, incorrect links, corrupted inodes. The fsck (file system check) utility is the standard Linux tool for checking and fixing such problems. Regular checks help prevent data loss and ensure system stability. This guide explains in detail how to safely use fsck on various file system types.

Requirements / Preparation

Before you begin, ensure that:

1. You have root privileges (or use sudo).
2. The file system is unmounted. Running fsck on a mounted partition (especially in read-write mode) is dangerous and can worsen corruption. For the root partition (/), you will need to boot from a Live USB/CD.
3. The appropriate utilities are installed. Usually fsck is included in the util-linux package, but for specific file systems, additional packages may be required:
   • ext2/3/4: e2fsprogs (often installed by default)
   • XFS: xfsprogs
   • Btrfs: btrfs-progs
   • NTFS: ntfs-3g
4. A backup of important data has been made, if possible. Although fsck is generally safe, there is a risk of file loss in case of severe corruption.

Step 1: Identify the File System and Device

First, find out what type of file system is used on the target partition and which device it corresponds to.

lsblk -f

Example output:

NAME   FSTYPE LABEL UUID                                 MOUNTPOINT
sda                                                      
├─sda1 vfat   BOOT  ABCD-1234                            /boot/efi
├─sda2 ext4   ROOT  a1b2c3d4-e5f6-7890-abcd-ef1234567890 /
├─sda3 swap        abcdef12-3456-7890-abcd-ef1234567890 [SWAP]
└─sda4 xfs   HOME  9876fedc-ba54-3210-fedc-ba9876543210 /home

Or use blkid:

blkid /dev/sda2

Output: /dev/sda2: UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" TYPE="ext4"

Note down the device (e.g., /dev/sda2) and the file system type (ext4, xfs, etc.).

Step 2: Unmount the Partition

Check if the partition is mounted:

mount | grep /dev/sda2

If the partition is mounted (e.g., in /home), unmount it:

umount /dev/sda2

If the partition is in use (e.g., your current working directory), close all applications that use it or change to a different directory. For the root partition (/), a simple umount will not work — you must boot from a Live media (e.g., Ubuntu Live USB) and run the check from there.

Step 3: Run fsck for Your File System Type

fsck is a frontend that calls specific utilities depending on the file system type. It is recommended to call them directly for greater reliability.

For ext2/ext3/ext4:

fsck.ext4 -f /dev/sdX1

The -f option forces a check even if the file system appears clean.

For XFS:

XFS requires the file system to be unmounted. Use xfs_repair (this is the equivalent of fsck for XFS):

xfs_repair /dev/sdX1

⚠️ Important: xfs_repair has no "check-only" option. It immediately fixes any errors it finds. Ensure you have a backup.

For Btrfs:

Btrfs supports online checking (on a mounted file system) via btrfs check, but for serious corruption it is better to unmount:

btrfs check /dev/sdX1

Use the --repair option to fix errors, but be cautious — it is potentially dangerous.

For NTFS (via ntfs-3g):

ntfsfix /dev/sdX1

ntfsfix is a simplified fsck equivalent for NTFS. It fixes basic errors and clears the transaction log. For complex cases, use the Windows utility chkdsk.

Step 4: Decide on Fixing Errors

After scanning, fsck (or the corresponding utility) will list the problems found and ask whether to fix them.

Example for ext4:

/dev/sda2: 1234/4567890 files (0.0% non-contiguous), 5678/9112345 blocks

If there are errors, you will see questions like:

/dev/sda2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
            (i.e., without -a or -p options)

Action options:

1. Automatic fix: Run with the -y option (or -p for automatic fixing of only safe errors) to answer "yes" to all questions:

   fsck.ext4 -y /dev/sdX1
   

   
   Use with caution: if there is severe corruption, it is better to analyze each error individually.
2. Manual confirmation: Run without -y and read each question carefully. Typical actions:
   • Fix? — fix the error.
   • Clear? — clear the block.
   • Abort? — abort the check (not recommended if fixing has already started).
   
   If unsure, you can choose "no" for questionable cases and review the logs afterward.
3. Check only: For testing without changes, use -n (no modify).

Step 5: Check the Result and Mount the Partition

Upon completion, fsck will return an exit code:

• 0 — no errors found.
• 1 — errors were fixed.
• 4 — errors remain (unfixable) or the file system was changed and requires a reboot (for the root partition).
• 8 — operational error (e.g., partition is mounted).

Review the output for warnings about unfixed errors.

Then mount the partition:

mount /dev/sdX1 /mnt

If mounting was successful (no errors in the console), check if files are accessible:

ls /mnt

Step 6: Check System Logs for Errors

Even after a successful fix, it is useful to ensure the system does not report new issues.

dmesg | tail -20

Or view the systemd journal:

journalctl -xe | grep -i "error\|fail" | tail -20

If logs mention disk problems (e.g., I/O error, medium error), this may indicate hardware issues. In such a case, perform a SMART check (see the related guide on smartctl).

Verifying the Result

The main indicator of success is the ability to mount the file system and read/write files without errors. Additionally:

1. Ensure fsck returned code 0 or 1.
2. Check that there are no errors in dmesg after mounting.
3. For ext-based file systems, you can perform an additional check:

   e2fsck -n /dev/sdX1  # check only, no changes
   

   
   It should report "Filesystem is clean".

Possible Issues

1. "Filesystem is mounted" — Partition is mounted

Fsck will refuse to work on a mounted file system. Solution:

• Unmount the partition (see Step 2).
• For the root partition, boot from a Live media.
• As a last resort for ext4, you can use the -f option even on a mounted system, but this is dangerous and can lead to data loss. Do not do this without a backup.

2. "Bad magic number" or "Invalid argument" — Superblock is corrupted

The superblock is file system metadata. If it is corrupted, fsck cannot recognize the file system. For ext2/3/4, you can try using a backup superblock:

fsck.ext4 -b 32768 /dev/sdX1

The backup block number depends on the file system block size. Common values:

• 8192 (for 1K blocks)
• 32768 (for 2K blocks)
• 32768 (for 4K blocks)

To find the location of backup superblocks, use:

dumpe2fs -h /dev/sdX1 | grep -i "backup"

3. Fsck hangs or runs very slowly

This may indicate:

• Physical disk damage (bad sectors). Check SMART:

  smartctl -a /dev/sdX
  

  
  Look for errors like Reallocated_Sector_Ct, Current_Pending_Sector, UDMA_CRC_Error_Count.
• A very large number of errors — fsck may take a long time to fix them. Give it time.
• An extremely large partition (several TB) — it is normal for a check to take hours.

If the disk is failing, immediately copy data (e.g., using ddrescue) and replace the disk.

4. System does not boot after repair

If fsck repaired the root partition but the system does not boot:

• Check if the bootloader (GRUB) is damaged. Reinstall it from a Live media.
• Check boot logs via journalctl -b -1 (previous boot).
• Ensure that /etc/fstab specifies correct UUIDs for partitions (after repair, the UUID might have changed? Usually not, but it can happen when new inodes are created).

5. Error "No such file or directory" when calling fsck for a specific type

Ensure the package with support for that file system is installed. For example, for XFS:

sudo apt install xfsprogs   # Debian/Ubuntu
sudo yum install xfsprogs   # RHEL/CentOS

6. Data loss after fsck

Fsck tries to preserve data, but with severe corruption some files may be lost. You can recover them:

• For ext4: tools like extundelete or testdisk (work on an unmounted partition).
• For XFS: xfs_repair may move damaged inodes to the lost+found directory. Check it after mounting.
• For NTFS: ntfs undelete (from the ntfs-3g package) or Windows utilities.

Prevention: always take regular backups and use journaling file systems (ext4, XFS, btrfs), which handle crashes better.