> ## Content Index
> Fetch the complete content index at: https://snubmonkey.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to Force fsck on Ubuntu Server Using /forcefsck.
- URL: https://snubmonkey.com/force-filesystem-check-linux/
- Published: 2026-03-16T15:31:05.000Z
- Updated: 2026-10-12T23:03:09.000Z
- Description: Learn how to force a filesystem check on Ubuntu Server, understand /forcefsck, use systemd boot parameters, and verify filesystem-check results safely.
- Author: yannick Coffi
- Tags: how to 🪄

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](https://manpages.ubuntu.com/manpages/jammy/man8/systemd-fsck.8.html?utm%5Fsource=chatgpt.com)

##   
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](https://manpages.ubuntu.com/manpages/jammy/man8/systemd-fsck.8.html?utm%5Fsource=chatgpt.com)

### 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
```

1. 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](https://lists.ubuntu.com/archives/ubuntu-users/2024-November/313419.html?utm%5Fsource=chatgpt.com)

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](https://manpages.ubuntu.com/manpages/jammy/man8/systemd-fsck.8.html?utm%5Fsource=chatgpt.com)

## 

  
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.