Check and Repair Linux File Systems with fsck

Learn how to safely inspect and repair Linux file systems with fsck, identify devices, unmount partitions, use filesystem-specific tools, and interpret results.

A Linux file system organizes files, directories, allocation information, and metadata on storage. Its metadata can become inconsistent after a power loss, improper shutdown, software defect, or failing disk, cable, controller, or other storage hardware.

Checking examines file system structures for inconsistencies. Repairing changes metadata to correct problems that the checker finds. Repair can remove damaged references or discard information that cannot be recovered, so create a backup or storage snapshot before making changes whenever possible.

What fsck Does

fsck means “file system check.” It is usually a dispatcher, or front end, rather than one universal checker. It detects the target file system type and invokes an appropriate filesystem-specific program.

The selected checker examines structures such as allocation maps, inode records, directory entries, journals, and superblocks. An inode is a metadata record that describes a file or directory, while a superblock contains core information about the file system’s layout and properties. A journal records pending or recent changes so a journaling file system can recover more safely after a crash.

Identify the Correct Device First

A block device is a device file representing disk-like storage, such as a partition, logical volume, or mapped encrypted device. A mount point is a directory through which a mounted file system is accessed. They are not interchangeable: /dev/sdb1 is a device, while /data might be its mount point.

lsblk -f
blkid
findmnt
df -T

Compare the device name, file system type, UUID, label, size, and mount point. A UUID is a stable unique identifier for a file system and is often more reliable than a device name that can change between boots. Use a direct device path for an explicit check; some workflows can instead select a file system by UUID or label.

Inspect the configured mounts

grep -vE '^\s*($|#)' /etc/fstab

/etc/fstab describes file systems, their mount points, file system types, mount options, and boot-time behavior. Verify the intended entry before using an automatic check. Extra care is required with NVMe devices, USB disks, virtual disks, RAID, LVM, multipath storage, encrypted volumes, and device-mapper paths.

When It Is Safe to Run fsck

Situation	Can the target be checked now?	Recommended action	Reason
Unmounted data partition	Generally yes	Confirm its identity, then run the appropriate checker	No active file operations should modify the metadata
Mounted read-write data partition	No	Stop users and services, then unmount it	Concurrent changes can corrupt results or cause more damage
Root file system during normal operation	Normally no	Use rescue mode, recovery mode, a live environment, or an offline boot-time check	The running system normally cannot unmount its root file system
System booted into rescue or live environment	Usually yes	Identify the target and ensure it is not mounted read-write	The target can be checked offline
Storage showing hardware failure symptoms	Not before protecting data	Copy or image the storage first when possible, then investigate hardware	Repair activity can increase loss on failing media

A read-only mount can be safer than a read-write mount in limited situations, but an unmounted, offline check remains standard practice. Check whether a device is mounted before proceeding:

findmnt /dev/sdb1
findmnt /data

For a non-root file system, unmount the correct target. The command may fail if a process is using it; stop the relevant services and investigate dependent mounts rather than forcing an unmount blindly.

sudo umount /dev/sdb1

Basic fsck Invocation

The general form is:

sudo fsck [options] /dev/device

For example, an explicit ext4 partition target might be:

sudo fsck -V -t ext4 /dev/sdb1

/dev/sdb1 is an example only. Never substitute a device name until lsblk -f, blkid, and findmnt confirm that it is the intended partition. Running a repair command on the wrong partition can destroy unrelated data.

Common fsck Options

Option	Purpose	Typical use	Safety notes
`-A`	Check file systems configured for checking in `/etc/fstab`	`sudo fsck -A`	Do not assume every configured target is safely unmounted
`-t FSTYPE`	Select or constrain the file system type	`sudo fsck -t ext4 /dev/sdb1`	Use only after verifying the actual type
`-N`	Display commands that would be executed without performing checks	`sudo fsck -ANV`	A planning aid, not a consistency check
`-R`	Skip the root file system when processing `-A`	`sudo fsck -ARV`	It does not make mounted non-root file systems safe
`-V`	Show verbose information, including selected checker commands	`sudo fsck -V /dev/sdb1`	Output format and details vary by implementation

Exact availability and behavior vary between distributions and fsck implementations. Preview an fstab-based operation before doing real work:

sudo fsck -ANV

Options that automatically answer repair prompts, such as checker-specific “yes to all” options, should not be used blindly. Review the proposed repairs and preserve a backup first.

Practical Offline Checks

Check an unmounted ext4 partition

findmnt /dev/sdb1
sudo umount /dev/sdb1
sudo fsck -V -t ext4 /dev/sdb1

The checker may ask whether to fix individual problems. Read each prompt when the data is important. An ext-family checker can also be called directly:

sudo e2fsck -f /dev/sdb1

e2fsck checks and repairs ext2, ext3, and ext4 file systems. The -f option forces a check even when the file system appears clean. The target must not be mounted read-write.

Filesystem-Specific Tools

File system	Primary tool	Relationship to fsck	Key caution
ext2	`e2fsck` or `fsck.ext2`	Commonly selected by `fsck`	Run offline; understand prompts before repairing
ext3	`e2fsck` or `fsck.ext3`	Commonly selected by `fsck`	Journal and metadata repairs can change recoverability
ext4	`e2fsck` or `fsck.ext4`	Commonly selected by `fsck`	Run against an unmounted target
XFS	`xfs_repair`	Uses XFS-specific semantics; `xfs_check` is historical or deprecated on many systems	Read warnings carefully, especially those involving log information
Btrfs	Btrfs-specific tooling	Not a universal fsck repair target	Repair operations require especially careful, filesystem-specific guidance

Different file systems store and repair metadata differently. fsck is not a universal repair solution. XFS repair should be performed offline:

sudo xfs_repair -n /dev/sdb1
sudo xfs_repair /dev/sdb1

xfs_repair -n performs a non-modifying inspection. Review its output before running the modifying command. If XFS warns about discarding or bypassing log information, use the least destructive supported recovery path; recent metadata changes may be lost.

Automatic Checks and /etc/fstab

During startup, traditional boot logic and many modern systemd-based systems can use /etc/fstab and file system state to decide whether checks should run. The final field of an fstab entry is the fsck pass number, which controls whether and in what order a file system is checked.

Pass value	Meaning	Typical use
`0`	Do not check automatically	File systems that should not receive boot-time fsck processing
`1`	Check first	The root file system
`2`	Check after pass 1	Other local file systems, potentially in parallel where supported

Do not mark removable, network, virtual, or otherwise unsuitable storage for automatic boot-time repair without understanding the result. An fstab check setting does not remove the requirement for correct tool support or safe mount state.

Recovering Disconnected Files

A directory entry maps a name to an object. On ext-family file systems, the object is described by an inode. If directory entries or metadata are damaged, a checker may find an inode or file whose original path can no longer be determined.

Some file systems create a lost+found directory and place recovered files or directories there. Generated names may contain numbers rather than useful original names:

sudo ls -la /mount/point/lost+found
sudo file /mount/point/lost+found/*

Inspect file types, sizes, timestamps, and contents. Compare them with backups and application records before renaming or restoring anything. Keep uncertain recovered data separate until it has been validated.

Understanding Results and Exit Status

A check can report that the file system is clean, that errors were corrected, or that errors remain uncorrected. The command’s exit status provides a machine-readable summary. Exact values can vary slightly by checker, but common fsck conventions are:

Exit status or condition	Meaning	Administrator response
No errors, commonly `0`	The check found no problem	Record the result and return the file system to normal service
Errors corrected, commonly `1`	Repair changes were made	Review output and validate important data
Reboot required, commonly included in `2`	Further checking or a restart is needed	Follow the checker’s instruction before remounting for normal use
Errors left uncorrected, commonly `4`	Problems remain	Do not assume the file system is safe; preserve data and investigate further
Operational or usage error, commonly `8` or `16`	The check could not run correctly, or invocation was invalid	Correct the command, mount state, permissions, or missing tool

After repair, remount the file system only when the checker indicates it is safe. Inspect lost+found, review logs, and verify application data rather than checking only whether the mount succeeded.

journalctl -b
dmesg -T

Troubleshooting Common Problems

fsck says the device is mounted

Use findmnt /dev/target and lsblk -f to identify the mount state. A non-root target may have been remounted by an automount service, or a process may still be using it. Stop appropriate services, unmount the correct device, and retry. For the root file system, boot into rescue, recovery, or live media.

The target device is uncertain

Similar disk names and layered storage make mistakes easy. Match UUID, label, size, file system type, and mount point across lsblk -f, blkid, and findmnt. Do not proceed until the identity is certain. Prefer stable identifiers in documentation and configuration.

An unexpected checker is selected

The target may be wrong, the checker package may be missing, identifying metadata may be damaged, or the file system may be unsupported. Use:

sudo fsck -N -V /dev/sdb1

Verify the type with lsblk -f and blkid. Use -t only after confirming the actual type, and use the filesystem-specific recovery procedure when the type cannot be identified.

Corruption returns

Repeated corruption can indicate a failing disk, cable, controller, memory, virtual storage layer, or power system. Review kernel logs, run appropriate SMART or vendor diagnostics, back up immediately, and replace or migrate failing components. fsck repairs file system metadata; it does not cure failing hardware or repeated unsafe shutdowns.

Recommended Safety Workflow

Back up or snapshot important data; image failing storage first when possible.
Identify the exact block device, file system type, UUID, and mount point.
Confirm that the target is not mounted read-write.
Unmount a non-root file system, or boot into an offline rescue, recovery, or live environment for the root file system.
Preview fstab-based checks with sudo fsck -ANV when applicable.
Use fsck or the correct filesystem-specific checker.
Read the output, record the exit status, and repeat only when the tool or recovery procedure requires it.
Remount, inspect recovered content, review logs, and verify application data.
Investigate hardware or software causes if corruption recurs.