File system corruption can cause a range of symptoms from strange errors to a server failing to boot. This guide covers using fsck (file system check) to diagnose and repair common file system issues.
What fsck Does
Checks a file system for structural inconsistencies (damaged inodes, orphaned blocks, incorrect metadata) and attempts to repair them — the standard Linux tool for file system integrity verification and repair.
Important: Never Run fsck on a Mounted, Actively-Used File System
Running fsck on a mounted file system risks further corruption — the root file system typically needs to be checked either at boot time (before full mount) or by booting from a rescue/recovery environment.
Checking a Non-Root, Unmounted File System
sudo umount /dev/sdb1
sudo fsck /dev/sdb1Checking the Root File System (Requires Special Handling)
Since you can't unmount the root file system while running normally, options include: scheduling a check for the next reboot, or booting into a rescue/recovery environment via your VPS provider's console tools.
Scheduling an fsck Check for the Next Boot
sudo touch /forcefsckForces a file system check on the next boot before the system fully starts — the presence of this file triggers the check, then it's automatically removed.
Using Provider Rescue Mode
Most VPS providers offer a "rescue mode" or similar — boots from an external minimal environment with your actual disk mounted but not as the active root, letting you safely run fsck on what would normally be your unmountable root partition.
Running fsck in Rescue Mode
sudo fsck -y /dev/sda1-y automatically answers "yes" to repair prompts — convenient for unattended repair, though understand this means accepting fsck's proposed fixes without individual review.
Understanding fsck Output
fsck reports and (if not in dry-run mode) fixes issues like: unreferenced inodes, incorrect block/free counts, and directory structure problems — some fixes may result in files being moved to a lost+found directory if their original location/name couldn't be determined.
Checking lost+found After Repair
ls -la /lost+foundReview any files recovered here — fsck sometimes can restore file content but not always its original filename/location, requiring manual identification and restoration.
Running fsck in Check-Only Mode First (Non-Destructive)
sudo fsck -n /dev/sda1-n reports issues without making any changes — useful for understanding the scope of corruption before committing to actual repairs.
When fsck Can't Fully Repair the File System
If corruption is severe enough that fsck can't restore a functional file system, restoring from a backup (see How to Set Up Automated VPS Backups) becomes the necessary path forward rather than continued repair attempts.
Preventing File System Corruption
- Always shut down gracefully, never force-power-off a running server unnecessarily
- Monitor underlying disk health where visible
- Maintain regular backups as your ultimate safety net regardless of prevention efforts
Common Errors
fsck reports the file system is "clean" but problems persist — the actual issue may not be file-system-level corruption at all; investigate application-level or other causes for the observed symptoms.
Continue Reading
- How to Recover from a Corrupted Database
- How to Set Up Automated VPS Backups
- How to Access Your VPS Console When SSH Isn't Working
Browse more articles in Troubleshooting & FAQ.
