I want to run periodically the fsck Terminal command, so it will run, let's say, every Friday at 10 am. Also, I'd like it to run in background and save the output in file, let's say, ~/Documents/errors.log.

I'm using Ubuntu 18.04.3 LTS that runs as Live Ubuntu with Persistent Storage from USB stick.

Can I do it? How?

  • 3
    Not while the system is running, no, because it's a 'mounted file system' that fsck can't reliably check.
    – Thomas Ward
    Commented Nov 15, 2019 at 19:14
  • 2
    1 way would be to use cron to do a touch /forcefsck and then schedule a reboot.
    – Rinzwind
    Commented Nov 15, 2019 at 19:18
  • @ThomasWard: Right, all partitions are mounted once Ubuntu is running on my machine. But I didn't know that even fsck -N ("do not execute, just show" mode) is not reliable in checking files or partitions.
    – BlueSkies
    Commented Nov 15, 2019 at 21:45

1 Answer 1


The Myth - "NO it can't be done"

All these most popular google search hits ignore the question or say NO it can't be done. That isn't true though. fsck is scheduled to run during boot before the filesystem is mounted as rw (read/write). As such most answers says it can't be run after system is fully booted:

Why it needs to be done

This is a good question for some types of users.

  • Sometimes I can go weeks before rebooting my laptop and will not get the benefit of fsck regularly.
  • Other times I can reboot dozens of times an hour as I try out a new grub theme or switch between distributions to compare functionality. In this case I don't want to wait the extra 30 seconds for fsck to run. As such I have it disabled during boot.

What the manual says about how it can be done

You can run fsck -n but it won't accurately report errors for ReiserFS (whatever that filesystem is). There is another obscure file system called it refuses to check altogether.

$ man fsck

FSCK(8)                              System Administration                             FSCK(8)

       fsck - check and repair a Linux filesystem

       fsck  [-lsAVRTMNP]  [-r  [fd]] [-C [fd]] [-t fstype] [filesystem...] [--] [fs-specific-

       fsck is used to check and optionally repair one or more Linux filesystems.  filesys can
       be a device name (e.g.  /dev/hdc1, /dev/sdb2), a mount point (e.g.  /, /usr, /home), or
       an ext2 label or UUID  specifier  (e.g.   UUID=8868abf6-88c5-4a83-98b8-bfc24057f7bd  or
       LABEL=root).   Normally,  the  fsck program will try to handle filesystems on different
       physical disk drives in parallel to reduce the total amount of time needed to check all
       of them.

       If  no  filesystems  are specified on the command line, and the -A option is not speci‐
       fied, fsck will default to checking filesystems in /etc/fstab serially.  This is equiv‐
       alent to the -As options.

       The exit code returned by fsck is the sum of the following conditions:

              0      No errors
              1      Filesystem errors corrected
              2      System should be rebooted
              4      Filesystem errors left uncorrected
              8      Operational error
              16     Usage or syntax error


       -n     For some filesystem-specific checkers, the -n option will cause the  fs-specific
              fsck to avoid attempting to repair any problems, but simply report such problems
              to stdout.  This is however not true for all filesystem-specific  checkers.   In
              particular,  fsck.reiserfs(8)  will  not  report  any  corruption  if given this
              option.  fsck.minix(8) does not support the -n option at all.

What it looks like checking mounted partitions

I have three partitions; Old (broken) Ubuntu 16.04, Ubuntu 19.04 (called Ubuntu 18.04) and New Ubuntu 16.04. When running fchk they look like this:

$ sudo fsck -n /dev/nvme0n1p7
fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
Warning!  /dev/nvme0n1p7 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Old_Ubuntu_16.04 has been mounted 358 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Old_Ubuntu_16.04: 433493/1515520 files (0.8% non-contiguous), 4956946/6061568 blocks

$ sudo fsck -n /dev/nvme0n1p10
fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
Warning!  /dev/nvme0n1p10 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Ubuntu_18.04: clean, 719735/1782368 files, 5770105/7129088 blocks

$ sudo fsck -n /dev/nvme0n1p6
fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
Warning!  /dev/nvme0n1p6 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
New_Ubuntu_16.04: clean, 833786/2953920 files, 8256858/11829504 blocks

As you can see fsck is telling us Old Ubuntu 16.04 requires a real fsck be run with system mounted in ro (read only mode) so fixes can be applied if necessary. However I already know it is broken.

Later I'll update this answer with a cron weekly job that runs fsck on three mounted Ubuntu partitions in check only mode.

  • I assume you actually did read the man page for e2fsck. Particularly the statement the results printed by e2fsck are not valid if the filesystem is mounted. If Ts'o doesn't think his own program can reliably check mounted file systems, he is probably right.
    – doneal24
    Commented Nov 16, 2019 at 2:11
  • @doneal24 I read the fsck man page which is quoted above and which this question asks. I also know my "Old Ubuntu 16.04" doesn't boot. And I see above lots of extra messages reported by fsck for it that don't appear on the two partitions that do boot. I do appreciate fsck is a wrapper for efsck and others but the man page for fsck does explicitly state with filesystems it won't work with when mounted rw. I think the real life 'fsck -n` checks above are a good example to show problems exist and how a real fsck is warranted. Commented Nov 16, 2019 at 2:17
  • So you trust a "generic" man page for the fsck wrapper more than you trust the words of the developer of the userspace tools for the ext file systems? I'm glad it works for you, but I certainly would not trust this process for my production systems.
    – doneal24
    Commented Nov 16, 2019 at 2:21
  • @doneal24 Production systems with paid IT staff is not the same thing as a home computer user. The former would likely be using RAID and read after write checking which makes fsck look like child's play. The latter buy new systems every two to five years long before the life span of long-term storage runs out. Commented Nov 16, 2019 at 2:25
  • @doneal24 Bottom line is this: for people who turn off fsck totally to save on boot time, a little fsck is better than no fsck. Commented Nov 16, 2019 at 2:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .