How to Force fsck on Ubuntu Server Using /forcefsck.

Filesystem integrity is essential for Linux server reliability. Unexpected power outages, system crashes, and storage problems can leave filesystems in an inconsistent state.

Linux provides fsck (File System Consistency Check), a front-end utility that invokes filesystem-specific checking tools to detect and, where supported, repair filesystem errors.

Linux normally checks filesystems when necessary during startup. However, you may want to request a filesystem check explicitly, particularly when troubleshooting filesystem inconsistencies.

In this tutorial, we'll explore the traditional /forcefsck method, explain how modern Ubuntu systems handle filesystem checks, and show you how to verify the results safely.

Understanding /forcefsck

On older Linux systems, creating an empty file named /forcefsck could request a filesystem check during the next reboot.

The command is straightforward:

$ sudo touch /forcefsck

Then reboot:

$ sudo reboot

However, this method is not reliable across modern Ubuntu installations. Ubuntu Server uses systemd and may perform filesystem checks through its initramfs before the main system starts. Depending on the boot configuration and filesystem, the /forcefsck file may be ignored or may not produce the behavior you expect.

For modern systemd-based systems, the documented boot parameter for requesting a forced filesystem check is fsck.mode=force. Ubuntu Manpages

When Should You Force a Filesystem Check?

A manual filesystem check may be appropriate when:

• A server has experienced an unexpected shutdown or power failure.
• Filesystem errors have appeared in system logs.
• You suspect filesystem metadata corruption.
• You are troubleshooting unexpected filesystem behavior.
• You need to investigate filesystem consistency during scheduled maintenance.

A filesystem check is not a substitute for diagnosing failing storage. If you suspect hardware problems, inspect the disk's health and kernel logs before attempting repairs.

For example, review recent kernel messages:

$ sudo journalctl -k -b | grep -iE 'I/O error|filesystem error|ext4|xfs|btrfs'

Look for repeated I/O errors, filesystem warnings, or other storage-related messages.

Identify Your Filesystem and Mount Points

Before running a filesystem check, identify the filesystem type and the device on which it resides.

Use:

$ lsblk -f

This displays available block devices, filesystem types, UUIDs, and mount points.

You can also inspect mounted filesystems with:

$ df -Th

For example, your root filesystem might be mounted from /dev/sda2 and formatted as ext4.

The filesystem type matters because fsck delegates its work to filesystem-specific utilities. Not every filesystem supports the same checking and repair operations.

Important: Do not run a repair check against a mounted, writable root filesystem. For a reliable offline check, use a suitable recovery environment where the target filesystem is unmounted.

Method 1: Force a Filesystem Check Using systemd

Modern Ubuntu systems use systemd's filesystem-checking mechanism, which supports the following kernel command-line parameters:

• fsck.mode=auto — use the filesystem checker's normal criteria.
• fsck.mode=force — request a full filesystem check.
• fsck.mode=skip — skip filesystem checks.

The fsck.repair parameter controls how repair questions are handled:

• fsck.repair=preen — automatically repair problems that can safely be fixed without interactive intervention.
• fsck.repair=yes — automatically answer yes to all repair questions.
• fsck.repair=no — automatically answer no to repair questions.

For routine troubleshooting, fsck.repair=preen is generally a more cautious choice than automatically approving every repair. Ubuntu Manpages

Temporarily Add the Parameters Through GRUB

If your Ubuntu Server uses GRUB and allows access to its boot menu, you can try requesting a forced check for the next boot without permanently changing the configuration.

1. Reboot the server.
2. Open the GRUB menu. On some systems, you may need to hold Shift or press Esc during startup.
3. Select the Ubuntu boot entry and press e to edit it.
4. Find the line beginning with linux.
5. Append the following parameters to that line:

fsck.mode=force fsck.repair=preen

6. Boot using the edited entry. GRUB commonly uses Ctrl+X or F10 to continue.

These changes apply to that boot only. They do not permanently modify /etc/default/grub.

Important limitation: On Ubuntu, the initramfs may check the root filesystem before the main systemd services start. Consequently, the main system's filesystem-check service may report that it was skipped because the root filesystem was already checked. The actual check results may be recorded in initramfs logs rather than appearing as a new check in the main system's journal. Ubuntu Mailing Lists

If you need to verify or repair the root filesystem conclusively, use the appropriate recovery procedure for your system rather than assuming that adding kernel parameters guarantees the check ran.

Should You Make the GRUB Change Permanent?

You can edit /etc/default/grub and run sudo update-grub to change kernel parameters persistently. However, I do not recommend permanently enabling forced filesystem checks for routine server operation.

A forced check can increase boot time substantially, particularly on large filesystems. Persistent settings also make every subsequent boot subject to the same behavior.

For troubleshooting, a temporary boot parameter or an offline recovery check is preferable.

Method 2: Check an ext4 Filesystem from a Recovery Environment

For an ext4 root filesystem, an offline check is the more direct option when you need to investigate or repair filesystem inconsistencies.

First, identify the correct device:

$ lsblk -f

For example, suppose the root filesystem is /dev/sda2. Do not copy this device name blindly; confirm the actual device on your server.

Boot into a suitable recovery environment or Ubuntu live environment, and make sure the target filesystem is not mounted.

Then perform a check without making changes:

$ sudo e2fsck -f -n /dev/sda2

The options mean:

• -f forces a check even if the filesystem appears clean.
• -n answers no to repair questions, allowing a read-only assessment.

Review the output carefully. The -n option is useful for diagnosis, but it is not a repair operation.

If repairs are needed, ensure you have a suitable backup and understand the reported problems before proceeding. For an offline ext4 filesystem, an interactive repair can be initiated with:

$ sudo e2fsck -f /dev/sda2

Follow the prompts and review each proposed action.

Never run e2fsck against a mounted, writable filesystem.
Doing so can produce misleading results or cause filesystem damage.

Verify Whether a Filesystem Check Ran

After rebooting, you can inspect systemd's filesystem-check messages:

$ sudo journalctl -b | grep -iE 'fsck|filesystem check'

To inspect messages from the previous boot:

$ sudo journalctl -b -1 | grep -iE 'fsck|filesystem check'

The second command depends on the previous boot's journal being available. If persistent journaling is disabled or the relevant messages were recorded only during initramfs startup, the output may not contain the information you need.

For an initramfs check, inspect its filesystem-check log when available:

$ sudo cat /run/initramfs/fsck.log

This file is runtime data and may not exist or remain available on every system. Its presence and contents depend on the boot process.

Do not conclude that a filesystem was checked merely because the server rebooted successfully. Confirm the actual check results and the filesystem that was examined.

Filesystem-Specific Considerations

The correct checking and repair procedure depends on the filesystem type.

ext2, ext3, and ext4: Use the appropriate e2fsck utility. For root filesystems, use a suitable offline or recovery environment when a full check is required.

XFS: fsck.xfs does not perform a conventional filesystem consistency scan. XFS has its own recovery and repair tooling, including xfs_repair for appropriate offline repair scenarios.

Btrfs: Use Btrfs-specific diagnostic and recovery tools. Do not assume that conventional fsck repair options apply.

ZFS: Use ZFS-specific status and pool-management tools to investigate integrity problems.

The generic fsck command is a front end; it does not mean that every filesystem is checked or repaired identically. Ubuntu Manpages

While the traditional sudo touch /forcefsck trick often fails on modern Ubuntu Server, systemd-based systems support fsck.mode=force to trigger a forced check at boot. Note that Ubuntu's initramfs may execute this check before the main system starts. For a definitive check on ext4 filesystems, booting into a recovery environment with the filesystem unmounted remains the most reliable method.

Thanks for following along.