VMware ESXi and vSphere Cluster Management

Check and Repair Linux File Systems with fsck

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

Why file-system checks are needed

A filesystem check inspects filesystem metadata and structures for inconsistencies. Metadata describes how directories, files, free space, and storage blocks are organized. An inode is a metadata structure that records information about a file, excluding its name.

Unexpected shutdowns, software faults, hardware failures, and storage-device problems can interrupt updates to this metadata. The result may be filesystem corruption: damage or inconsistency in the filesystem's data structures.

Corruption can cause inaccessible files, broken directory entries, incorrect free-space information, or orphaned files. An orphaned file is a filesystem object whose metadata still exists but is no longer correctly connected through a directory entry. Severe corruption can result in permanent data loss.

A check examines these structures and may repair detected inconsistencies. Repair is a potentially destructive operation: it can discard damaged metadata or reconnect objects in ways that do not restore the original files perfectly. Back up important data and confirm the target before authorizing repairs.

What fsck does

fsck is the general Linux utility for checking filesystems. It is usually a dispatcher, or front end, that selects and invokes a checker appropriate for the filesystem type. The actual checker may be an ext-family tool such as e2fsck or a filesystem-specific program such as xfs_repair.

A block device is a disk or partition represented by a path such as /dev/sdb1 or /dev/nvme0n1p2. A mount point is the directory where a filesystem is attached to the directory tree, such as /data or /home. For manual checks, the device is normally the target:

sudo fsck [options] DEVICE

For example, /dev/sdb1 identifies a filesystem device, while /data identifies a directory through which that filesystem may be mounted. Both a device and, where supported, a mount-point path can help identify the target, but do not confuse a directory with the underlying partition.

Safety requirements before repair

A mounted filesystem is currently accessible through the running operating system. Do not normally run a repair check against a mounted read-write filesystem. Programs may change directories, inodes, allocation maps, and journal data while the checker is examining them. Those concurrent changes can produce misleading results or cause additional damage.

Identify the intended filesystem device, filesystem type, and mount point.
Back up important data if the filesystem is still readable.
Stop applications, services, containers, shells, and other processes using the filesystem.
Unmount the filesystem before a manual repair.
Confirm the device one more time before accepting repair prompts.

lsblk -f
findmnt -S /dev/sdb1
sudo umount /dev/sdb1

If the filesystem is busy, move any shell out of its mount directory, stop dependent workloads cleanly, and identify remaining users or processes. Do not force a repair merely because unmounting is inconvenient.

The root filesystem requires special handling. A normal running system needs its root filesystem, so it generally cannot be unmounted during that session. Use the distribution's maintenance or recovery mode, a suitable offline boot environment, or another approved procedure. Ensure the root filesystem is not mounted read-write before performing an offline repair.

Identify the target before checking it

Command	Information returned	How it helps prevent errors
`lsblk -f`	Block devices, filesystem types, labels, UUIDs, and often mount points	Shows the partition and format together before a checker is selected
`findmnt`	Mounted filesystems, source devices, targets, and mount options	Shows whether the intended device is mounted and where
`df -hT`	Filesystem type, capacity, used space, and available space for mounted filesystems	Helps distinguish a full filesystem from a structural corruption problem
`mount`	Current mount relationships and options	Provides another way to verify mount state and read-only versus read-write status

Use these commands together when necessary. blkid is also useful for identifying a device's filesystem type and UUID. Disk-space reporting does not validate filesystem metadata.

Basic manual fsck usage

Checking a selected device

After confirming that an ext4 target is unmounted, a generic check can be started with:

sudo fsck -t ext4 /dev/sdb1

The -t ext4 option restricts checker selection to ext4. Use it only after verifying that the device really contains ext4. Omitting it allows the generic utility to use filesystem detection and its configured checker.

Some checkers support a report-only or check-only mode that avoids writing repairs. For ext2, ext3, and ext4, for example:

sudo e2fsck -n /dev/sdb1

The exact options and behavior depend on the filesystem-specific checker. Read the relevant manual page before using a check-only or repair option. A check-only run is useful for assessment, but it does not guarantee that a later repair will be risk-free.

Understanding output and status

Output commonly reports the stages examined, inconsistencies found, and whether repairs were made or proposed. A checker may ask for confirmation before changing metadata. Interactive responses and automatic-repair options vary by checker; never approve a repair until the device and backup situation are clear.

The exit status is a summary for scripts and administrators. A zero status generally means no reportable problem was found, while a nonzero status can indicate inconsistencies, repairs, operational errors, or an interrupted check. The meaning of individual status bits is checker-specific, so consult the tool's manual page rather than treating every nonzero result as the same condition.

Important fsck options

Option	Purpose	Typical use	Safety notes
`-A`	Process filesystems configured for checking in `/etc/fstab`	`sudo fsck -A`	Review the selected devices first; this may include more filesystems than intended
`-t FSTYPE`	Select or restrict the filesystem type	`sudo fsck -t ext4 /dev/sdb1`	Only use a type that matches the actual on-disk format
`-N`	Show what would be done or which checkers would be invoked without performing the check	`fsck -AN`	It is a preview, not evidence that the filesystem is healthy
`-R`	When using `-A`, omit the root filesystem	`sudo fsck -ARV`	Useful for avoiding the active root target, but still review all selected devices
`-V`	Print verbose details about the operation	`sudo fsck -ARV`	More output improves visibility but does not make an unsafe target safe

Options can be passed through to filesystem-specific checkers where appropriate. Support is not uniform: a flag accepted by an ext checker may not apply to XFS or another filesystem. Use fsck --help and the checker-specific manual page for the installed implementation.

Automatic checks and /etc/fstab

/etc/fstab is a system configuration file containing filesystem mount settings and, traditionally, filesystem-check ordering information. The final field on an entry is the fsck pass number. It indicates whether a filesystem participates in checking and its relative order.

UUID=example-uuid /data ext4 defaults 0 2

In the traditional convention, the root filesystem has pass number 1 and is checked first. Other eligible filesystems commonly use pass number 2 and are checked afterward, potentially in parallel depending on the implementation.

The exact automatic behavior depends on the Linux distribution, init system, filesystem type, and local policies. Startup or maintenance processes may use the fstab configuration, but not every filesystem follows the same checking model. The -A option tells fsck to use the filesystems selected by fstab:

fsck -AN
sudo fsck -ARV

The first command previews fstab-selected checks. The second requests verbose checking of configured filesystems while omitting root. Treat the preview as a review step, not as authorization to repair.

Filesystem-specific checking and repair tools

Filesystem family	Primary checker or repair utility	Relationship to fsck	Important operational note
ext2	`e2fsck` or `fsck.ext2`	Usually selected by the generic fsck dispatcher	Check unmounted when repairing; verify options for the installed version
ext3	`e2fsck` or `fsck.ext3`	Usually selected by fsck according to the detected type	Understand journal-related messages and follow the checker prompts carefully
ext4	`e2fsck` or `fsck.ext4`	Usually selected by fsck according to the detected type	Use an offline target for repair and consider a check-only assessment first
XFS	`xfs_repair`	Uses a different workflow from ext-family fsck tools	Unmount the volume; use XFS documentation and do not apply ext-specific assumptions

Not every Linux filesystem uses fsck in the same way, and some do not support repair through the generic interface. Always verify the filesystem type before selecting a tool.

For an XFS volume, first identify and unmount it, then perform a non-modifying assessment with the XFS-specific utility:

lsblk -f
findmnt -S /dev/sdb2
sudo umount /dev/sdb2
sudo xfs_repair -n /dev/sdb2

An actual XFS repair uses xfs_repair without the assessment option only after reviewing its documentation, confirming an offline target, and protecting important data.

Recovered files and lost+found

During repair, a tool may find an inode or other filesystem object that is not connected to a normal directory entry. It can reconnect that object under a lost+found directory. This directory is commonly used by repair tools to hold recovered filesystem objects.

Recovered objects may have generated names or names based on metadata rather than their original directory paths. The original filename, directory, ownership context, or complete contents may not be recoverable. After mounting the repaired filesystem, inspect the directory:

sudo find /mnt/repaired-volume/lost+found -maxdepth 1 -ls
sudo file /mnt/repaired-volume/lost+found/*

Inspect file types and contents carefully, compare them with backups, and determine whether each object can be identified or restored. Document uncertain or damaged data before returning the filesystem to normal service.

Integrity checking versus capacity inspection

Task	Example tools	What it answers	What it does not answer
Filesystem consistency check	`fsck`, `e2fsck`, `xfs_repair`	Whether filesystem metadata and structures contain detectable inconsistencies	Whether the disk has enough free space or whether the hardware is physically healthy
Disk usage inspection	`df -hT`, `du`	How much capacity is used and available	Whether directory entries, inodes, or allocation metadata are structurally valid
Mount and filesystem-type identification	`lsblk -f`, `findmnt`, `mount`, `blkid`	Which device is mounted, where it is mounted, and which format it uses	Whether the filesystem is internally consistent

A filesystem can be nearly full while structurally healthy, or have metadata corruption while showing available capacity. Use the appropriate tool for the question.

Troubleshooting common problems

fsck warns that the target is mounted

Use findmnt and lsblk -f to verify the device and mount point.
Stop dependent processes and unmount the filesystem.
Do not force a repair on an active read-write filesystem.

The filesystem is busy and cannot be unmounted

Move the current shell out of the mount directory.
Identify users and processes with suitable process-inspection tools.
Stop the workload or service cleanly, then retry the unmount.

The root filesystem needs checking

The root filesystem cannot normally be unmounted during an ordinary running session. Boot into an appropriate maintenance, recovery, or offline environment and ensure it is not mounted read-write before repair.

fsck selects an unexpected checker

Confirm the target partition with lsblk -f or blkid.
Check that the required filesystem-specific utility is installed.
Use an explicit type only when the actual filesystem format has been verified.
For XFS, use xfs_repair rather than ext-family assumptions.

Recovered files have unfamiliar names

This usually means repair reconnected orphaned objects without enough directory information to restore their original names. Inspect their types and contents, compare them with backups, and document any data loss.

The filesystem has little free space but no metadata errors

Capacity exhaustion is separate from structural corruption. Use df -hT to assess usage, then remove, archive, or move data according to your retention policy. Use fsck for consistency validation and repair, not for freeing space.

Safe decision sequence

Determine whether the symptom suggests metadata corruption, low capacity, or possible hardware failure.
Use lsblk -f, findmnt, and df -hT to identify the device, type, mount state, and capacity.
Back up readable data and preserve evidence when hardware failure is suspected.
Stop users and services, then unmount a non-root target.
Select the checker that matches the filesystem: ext-family tools for ext2/ext3/ext4, or xfs_repair for XFS.
Perform a check-only assessment where the selected tool supports it.
Review output, confirm the target, and authorize repair only when appropriate.
Mount the repaired filesystem, inspect lost+found, review logs, and validate important files from backups.

For a concise refresher on the target-identification workflow, see the Linux file-system checking guide.