fsck Command Examples

10 Detailed fsck Examples

1Basic Filesystem Check (Non-Interactive)

# First, unmount the filesystem sudo umount /dev/sdb1 # Run fsck with automatic yes to all prompts sudo fsck -y /dev/sdb1

fsck from util-linux 2.37.2 e2fsck 1.46.5 (30-Dec-2021) /dev/sdb1: clean, 15432/655360 files, 245678/2621440 blocks

Explanation:

-y automatically answers "yes" to all repair prompts
Must unmount before checking to prevent corruption
Output shows filesystem is "clean" (no errors found)
Shows file and block usage statistics

💡 Pro Tip: For production systems, always run with -n (dry-run) first to see what would be changed without actually modifying anything.

2Check Filesystem Without Making Changes (Dry Run)

# Check what would be fixed without actually fixing sudo fsck -n /dev/sdc1

fsck from util-linux 2.37.2 e2fsck 1.46.5 (30-Dec-2021) Warning: skipping journal recovery because doing a read-only filesystem check. /dev/sdc1 contains a file system with errors, file system check required. 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 has illegal block(s). Clear<n>? no /dev/sdc1: ***** FILE SYSTEM WAS MODIFIED ***** (No changes were actually made - this is a read-only check)

Explanation:

-n performs read-only check (no modifications)
Safe to run on any filesystem, even mounted (though not recommended)
Shows what errors exist and what would be fixed
Perfect for assessing filesystem health before repair
Will prompt for each fix but won't apply them

💡 Pro Tip: Always run -n first on critical filesystems to understand the scope of damage before running actual repairs.

3Check Root Filesystem Using Single-User Mode

# At GRUB menu, press 'e' to edit # Add to kernel line: rd.break # At emergency prompt: mount -o remount,ro /sysroot fsck -y /dev/sda1 # After fsck completes: mount -o remount,rw /sysroot touch /sysroot/.autorelabel # If using SELinux exit # System will continue booting

fsck from util-linux 2.37.2 e2fsck 1.46.5 (30-Dec-2021) /dev/sda1: recovering journal 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 Free blocks count wrong (1234567, counted=1234590). Fix? yes /dev/sda1: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sda1: 25432/1310720 files (1.2% non-contiguous), 456789/5242880 blocks

Explanation:

Root filesystem (/) cannot be checked while mounted normally
rd.break interrupts boot process in initramfs
Root filesystem is accessible but not yet mounted
Remount as read-only first for safety
After fsck, system can boot normally
.autorelabel tells SELinux to relabel on next boot

⚠️ Warning: This is the ONLY safe way to fsck the root filesystem. Never attempt fsck on a mounted root partition from within the running system!

4Force Filesystem Check (Even if Clean)

# Force check even if filesystem appears clean sudo umount /dev/sdb1 sudo fsck -f /dev/sdb1

fsck from util-linux 2.37.2 e2fsck 1.46.5 (30-Dec-2021) 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 /dev/sdb1: 11/655360 files (0.0% non-contiguous), 83137/2621440 blocks

Explanation:

-f forces check even if filesystem is marked clean
Useful after hardware issues or unexpected shutdowns
Runs all 5 passes regardless of filesystem state
Takes longer than normal check
Recommended after disk errors or system crashes

💡 Pro Tip: Use -f periodically on critical filesystems as preventive maintenance, especially after power failures or hardware issues.

5Verbose Output for Detailed Diagnostics

# Check with verbose output to see what fsck is doing sudo umount /dev/sdc1 sudo fsck -v /dev/sdc1

fsck from util-linux 2.37.2 e2fsck 1.46.5 (30-Dec-2021) /dev/sdc1: clean, 15432/655360 files, 245678/2621440 blocks 15432 inodes used (2.35%, out of 655360) 45 non-contiguous files (0.3%) 12 non-contiguous directories (0.1%) # of inodes with ind/dind/tind blocks: 0/0/0 Extent depth histogram: 15320/98/14 245678 blocks used (9.37%, out of 2621440) 0 bad blocks 1 large file 15320 regular files 98 directories 0 character device files 0 block device files 0 fifos 0 links 14 symbolic links (14 fast symbolic links) 0 sockets 15432 files

Explanation:

-v provides verbose output with detailed statistics
Shows inode usage, block usage, and fragmentation stats
Lists file types and counts
Helpful for understanding filesystem health
Good for documentation and analysis

6Check Specific Filesystem Type

# Explicitly specify filesystem type sudo fsck -t ext4 /dev/sdb1 # Or use type-specific fsck command directly sudo fsck.ext4 /dev/sdb1 # For XFS filesystems (different tool) sudo xfs_repair /dev/sdc1 # For Btrfs sudo btrfs check /dev/sdd1

fsck from util-linux 2.37.2 e2fsck 1.46.5 (30-Dec-2021) /dev/sdb1: clean, 25432/1310720 files, 456789/5242880 blocks

Explanation:

-t specifies filesystem type (ext2, ext3, ext4, etc.)
fsck is a wrapper that calls appropriate filesystem-specific checker
Can also call specific checkers directly (fsck.ext4, fsck.vfat, etc.)
XFS uses xfs_repair instead of fsck
Btrfs uses btrfs check

ext2/ext3/ext4

fsck.ext4 or e2fsck

XFS

xfs_repair

Btrfs

btrfs check

FAT/VFAT

fsck.vfat or dosfsck

7Check All Filesystems in /etc/fstab

# Check all filesystems listed in /etc/fstab # Must be run from single-user mode or rescue system sudo fsck -A # Check all except root filesystem sudo fsck -A -R # Check all in parallel (faster for multiple disks) sudo fsck -A -M

fsck from util-linux 2.37.2 /dev/sdb1: clean, 15432/655360 files, 245678/2621440 blocks /dev/sdc1: clean, 8765/327680 files, 123456/1310720 blocks /dev/sdd1: recovering journal /dev/sdd1: clean, 43210/1966080 files, 789012/7864320 blocks

Explanation:

-A checks all filesystems in /etc/fstab
-R skips root filesystem (useful when booted normally)
-M enables parallel checking for speed
Respects the pass number in /etc/fstab (6th field)
Best run from rescue mode or LiveCD

💡 Pro Tip: The 6th field in /etc/fstab controls fsck behavior: 0=don't check, 1=root fs (check first), 2=other fs (check after root).

8Repair Filesystem with Corrupted Superblock

# If primary superblock is corrupted, use backup superblock # First, find backup superblock locations sudo mke2fs -n /dev/sdb1 # Use backup superblock for repair sudo fsck -b 32768 /dev/sdb1 # Or try another backup superblock sudo fsck -b 98304 /dev/sdb1

# Output from mke2fs -n (finding backups): mke2fs 1.46.5 (30-Dec-2021) Creating filesystem with 2621440 4k blocks and 655360 inodes Filesystem UUID: a1b2c3d4-e5f6-7890-abcd-ef1234567890 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 # Output from fsck with backup superblock: fsck from util-linux 2.37.2 e2fsck 1.46.5 (30-Dec-2021) /dev/sdb1 was not cleanly unmounted, 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 /dev/sdb1: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sdb1: 15432/655360 files (1.5% non-contiguous), 245678/2621440 blocks

Explanation:

Superblock contains critical filesystem metadata
Corruption of primary superblock can make filesystem unmountable
ext filesystems maintain backup superblocks at regular intervals
mke2fs -n shows backup locations without creating filesystem
-b tells fsck to use specified backup superblock
Try different backup locations if first one doesn't work

⚠️ Critical: This is a last-resort recovery technique. If backup superblocks fail, data recovery becomes extremely difficult.

9Interactive Filesystem Repair

# Run fsck interactively (prompts for each fix) sudo umount /dev/sdb1 sudo fsck /dev/sdb1

fsck from util-linux 2.37.2 e2fsck 1.46.5 (30-Dec-2021) /dev/sdb1: recovering journal Pass 1: Checking inodes, blocks, and sizes Inode 12345 has illegal block(s). Clear<y>? y Illegal block #123 (456789) in inode 12345. CLEARED. Inode 12345, i_blocks is 1024, should be 512. Fix<y>? y Pass 2: Checking directory structure Entry 'tempfile.txt' in /home/user (23456) has deleted/unused inode 12345. Clear<y>? y Pass 3: Checking directory connectivity Pass 4: Checking reference counts Inode 2 ref count is 5, should be 4. Fix<y>? y Pass 5: Checking group summary information Block bitmap differences: -123 -456 -789 Fix<y>? y Free blocks count wrong for group #0 (7890, counted=7893). Fix<y>? y /dev/sdb1: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sdb1: 15431/655360 files (1.2% non-contiguous), 245675/2621440 blocks

Explanation:

Interactive mode prompts before each repair
Gives you control over what gets fixed
Shows specific problems found in each pass
You can answer: y (yes), n (no), or a (yes to all remaining)
Good for learning what types of errors exist
Takes longer but provides more control

💡 Pro Tip: In production emergencies, use -y for speed. In development or learning, interactive mode teaches you about filesystem structure.

10Schedule Automatic Filesystem Checks

# View current fsck settings for a filesystem sudo tune2fs -l /dev/sdb1 | grep -i "check" # Set maximum mount count before forcing fsck sudo tune2fs -c 30 /dev/sdb1 # Set maximum time interval between fscks (180 days) sudo tune2fs -i 180d /dev/sdb1 # Disable automatic fsck (not recommended) sudo tune2fs -c 0 -i 0 /dev/sdb1 # Set filesystem check at next boot sudo tune2fs -C 30 /dev/sdb1 # Fake mount count # or sudo shutdown -rF now # Force fsck on reboot # Check if fsck will run at next boot sudo dumpe2fs -h /dev/sdb1 | grep -i "mount count"

# Output from tune2fs -l: Mount count: 15 Maximum mount count: 30 Last checked: Wed Jan 10 08:23:45 2024 Check interval: 15552000 (6 months) Next check after: Mon Jul 8 08:23:45 2024 # After setting new values: Setting maximal mount count to 30 Setting interval between checks to 15552000 seconds # Output showing fsck will run: Mount count: 30 Maximum mount count: 30 Last checked: Wed Jan 10 08:23:45 2024 Filesystem state: clean with errors

Explanation:

tune2fs manages ext2/ext3/ext4 filesystem parameters
-c sets max mount count before forced fsck
-i sets time interval between checks
-C artificially sets current mount count
shutdown -rF forces fsck on next reboot
Automatic checks help prevent filesystem degradation
Balance between system availability and filesystem health

💡 Pro Tip: For production servers, schedule fsck during maintenance windows using tune2fs -C to trigger it at next planned reboot.

Common fsck Options Reference

Option	Description	Use Case
`-y`	Automatically answer "yes" to all prompts	Automated repairs, emergency situations
`-n`	Read-only check, no modifications	Assessment without risk, mounted filesystems
`-f`	Force check even if filesystem is clean	After crashes, periodic maintenance
`-v`	Verbose output with detailed statistics	Diagnostics, documentation
`-a`	Automatically repair (no prompts, safer than -y)	Boot-time checks, automated scripts
`-p`	Automatic safe repair (like -a)	Boot scripts, automatic fixes
`-r`	Interactive repair (prompt for each fix)	Manual control, learning
`-b`	Use alternate superblock	Superblock corruption recovery
`-t`	Specify filesystem type	Multiple filesystem types
`-A`	Check all filesystems in /etc/fstab	System-wide checks
`-R`	Skip root filesystem when using -A	Check non-root filesystems
`-M`	Don't check mounted filesystems	Safety check in scripts
`-C`	Display progress bar	Long-running checks

Common Recovery Scenarios

Scenario 1: System Won't Boot - "Unexpected Inconsistency"

1. Boot into rescue mode (rd.break or rescue media) 2. mount -o remount,ro /sysroot 3. fsck -y /dev/sda1 4. mount -o remount,rw /sysroot 5. exit (continue boot)

Cause: Improper shutdown, power failure, hardware fault

Scenario 2: Filesystem Shows Errors in dmesg

1. Check errors: dmesg | grep -i "ext4\|error" 2. Unmount: sudo umount /dev/sdb1 3. Check: sudo fsck -fy /dev/sdb1 4. Remount: sudo mount /dev/sdb1 /mnt/data 5. Verify: df -h && ls -la /mnt/data

Cause: Filesystem corruption, bad sectors, write errors

Scenario 3: Read-Only Filesystem After Remount

1. System detected errors and remounted read-only 2. reboot into single-user mode 3. fsck -y /dev/sda1 4. reboot normally

Cause: Kernel detected filesystem inconsistencies

Scenario 4: Files Disappearing or Directory Corruption

1. Unmount immediately: sudo umount /dev/sdc1 2. Run fsck: sudo fsck -y /dev/sdc1 3. Check lost+found: ls -la /mnt/recovered/lost+found 4. Restore files from lost+found if needed

Cause: Directory structure corruption, orphaned inodes

Scenario 5: Can't Mount - "Bad Superblock"

1. Find backup superblocks: mke2fs -n /dev/sdb1 2. Try backup: fsck -b 32768 /dev/sdb1 3. If fails, try next: fsck -b 98304 /dev/sdb1 4. Mount and verify: mount /dev/sdb1 /mnt/test

Cause: Superblock corruption from write errors

Best Practices & Tips

🔍 Before Running fsck:

Always try to unmount the filesystem first
If unmount fails, check what's using it: lsof /mount/point
Make backups if possible (though if fsck is needed, mounting may not work)
Run with -n first to assess damage
Document current state: dmesg, tune2fs -l, etc.

📋 During fsck:

Have console/terminal access (not SSH if checking root)
Allow plenty of time - large filesystems take hours
Don't interrupt fsck once started (can worsen corruption)
Monitor for repeated same errors (indicates hardware issues)

✅ After fsck:

Check lost+found directory for recovered files
Verify filesystem integrity: df -h, ls -laR
Check system logs: dmesg, /var/log/messages
If fsck ran automatically at boot, check /var/log/boot.log
Monitor for recurring issues (may indicate hardware problems)
Update backups once filesystem is stable

🚫 Never Do These:

Run fsck on a mounted read-write filesystem
Interrupt fsck once started (except in true emergency)
Run fsck multiple times simultaneously on same filesystem
Ignore repeated fsck errors (usually means hardware failure)
Use -y blindly without understanding what might be lost

Related Filesystem Tools

Command	Purpose	Example
`tune2fs`	Adjust filesystem parameters	`tune2fs -l /dev/sda1`
`dumpe2fs`	Display filesystem information	`dumpe2fs -h /dev/sda1`
`debugfs`	Interactive filesystem debugger	`debugfs /dev/sda1`
`e2fsck`	Ext2/3/4 specific checker (fsck wrapper)	`e2fsck -f /dev/sda1`
`xfs_repair`	XFS filesystem repair	`xfs_repair /dev/sdb1`
`btrfs check`	Btrfs filesystem check	`btrfs check /dev/sdc1`
`badblocks`	Check for bad disk sectors	`badblocks -sv /dev/sda`
`smartctl`	Check disk SMART status	`smartctl -a /dev/sda`

fsck Exit Codes

Code	Meaning	Action Required
`0`	No errors	None - filesystem is clean
`1`	Errors corrected	Monitor filesystem, check logs
`2`	System should be rebooted	Reboot required for changes
`4`	Errors left uncorrected	Manual intervention needed
`8`	Operational error	Check fsck command syntax
`16`	Usage or syntax error	Fix fsck command
`32`	Fsck canceled by user	User interrupted
`128`	Shared library error	System library problem

💡 Checking Exit Codes:
fsck /dev/sdb1; echo $? - Shows the exit code immediately after fsck runs

🔧 fsck Command Examples

⚠️ CRITICAL WARNINGS - READ BEFORE USING FSCK

What is fsck?

10 Detailed fsck Examples

1Basic Filesystem Check (Non-Interactive)

2Check Filesystem Without Making Changes (Dry Run)

3Check Root Filesystem Using Single-User Mode

4Force Filesystem Check (Even if Clean)

5Verbose Output for Detailed Diagnostics

6Check Specific Filesystem Type

ext2/ext3/ext4

XFS

Btrfs

FAT/VFAT

7Check All Filesystems in /etc/fstab

8Repair Filesystem with Corrupted Superblock

9Interactive Filesystem Repair

10Schedule Automatic Filesystem Checks

Common fsck Options Reference

Common Recovery Scenarios

Scenario 1: System Won't Boot - "Unexpected Inconsistency"

Scenario 2: Filesystem Shows Errors in dmesg

Scenario 3: Read-Only Filesystem After Remount

Scenario 4: Files Disappearing or Directory Corruption

Scenario 5: Can't Mount - "Bad Superblock"

Best Practices & Tips

Related Filesystem Tools

fsck Exit Codes