Why "fstrim" isn't triggering automatically?

Hi community,

I’m running HAOS in a VM, like many others, and recently started encountering issues with my disk running out of space. I began by adding more storage, but when I had to increase it from 90GB to 160GB in just a few weeks, I suspected something was wrong.

I looked around in the community, and people suggested running fstrim -v /mnt/data or systemctl start fstrim.service. Running this manually immediately took my disk usage from 160GB down to 34GB, which seems much more accurate. This confirms that my VM environment is correctly passing through TRIM commands and fstrim itself is working.

I’m puzzled as to why I suddenly started experiencing this issue. My installation has been running for years, and this problem only began recently, without me adding a significant number of new integrations.

I’ve checked, and the fstrim.timer service is enabled and shows as active (waiting) on my HAOS instance, scheduled to run weekly on Mondays. However, despite the timer being active, my disk space hasn’t been reclaimed automatically for at least two weeks (since I last ran it manually). If I manually execute systemctl start fstrim.service, the space is freed up successfully. This suggests the automatic run isn’t happening, or it’s failing silently.

My question then is this: If the fstrim.timer is enabled and the manual fstrim.service works perfectly, what could be preventing the automatic weekly trim from executing or succeeding on HAOS? I really don’t feel like this should be an end-user task to constantly monitor and set up automations for; it seems like a fundamental OS maintenance task that isn’t reliably completing.

Can anyone shed some light on this, or suggest how I can further diagnose why the fstrim.timer isn’t effectively triggering the trim? Perhaps I’ve misunderstood something, but it appears the automated process isn’t functioning as expected.

Thanks.

No necessarily your answer but I would also suggest looking at the resocrder settings, and blocking out history for those things that do not matter to you

Thanks for the suggestion. I already went through that, as that was the first suggestion that came up when I searched around.
But even after that change, disk usage was still rising pretty fast. Looking in HA itself, it also reported that I only used around 30 GB, even though my VM disk usage was over 100 GB, so it is only a matter of the disk usage isn’t reclaimed on a disk level, and not the actual size size of files on disk.

You didn’t say which virtualisation engine you have used not VirtualBox is it? Apparently a known issue with not reclaiming disc space see the installation instructions. Not sure if this is just on the host though.

Good point. I’m running the VM on a Synology. I only know it is QEMU, not sure if there is something more specific to add here.

What does it look like when you check the status with…
systemctl status fstrim

This is what i got from todays run:

○ fstrim.service - Discard unused blocks on filesystems from /etc/fstab
     Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static)
     Active: inactive (dead) since Mon 2025-06-02 01:36:31 UTC; 17h ago
TriggeredBy: ● fstrim.timer
       Docs: man:fstrim(8)
    Process: 471253 ExecStart=/usr/sbin/fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported (code=exited, status=0/SUCCESS)
   Main PID: 471253 (code=exited, status=0/SUCCESS)
        CPU: 356ms

Jun 02 01:36:30 HAOS-VM systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
Jun 02 01:36:31 HAOS-VM fstrim[471253]: /tmp: 9 MiB (9474048 bytes) trimmed on /dev/zram2
Jun 02 01:36:31 HAOS-VM fstrim[471253]: /mnt/data: 23.2 GiB (24864776192 bytes) trimmed on /dev/sda8
Jun 02 01:36:31 HAOS-VM fstrim[471253]: /mnt/overlay: 83.9 MiB (87988224 bytes) trimmed on /dev/sda7
Jun 02 01:36:31 HAOS-VM fstrim[471253]: /mnt/boot: 31.2 MiB (32696320 bytes) trimmed on /dev/sda1
Jun 02 01:36:31 HAOS-VM systemd[1]: fstrim.service: Deactivated successfully.
Jun 02 01:36:31 HAOS-VM systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.

Yeah, so, there are two things to look at here, apparently, and they confuse me even more.

systemctl status fstrim

systemctl status fstrim.timer

So, I guess that you are looking if fstrim is running with your command, and the fstrim.timer is the schedule that triggers the fstrim service. So that might explain why you see it as dead.
What does your fstrim.timer say?

systemctl status fstrim.timer

● fstrim.timer - Discard unused filesystem blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; preset: enabled)
     Active: active (waiting) since Fri 2025-05-30 09:53:54 UTC; 3 days ago
    Trigger: Mon 2025-06-09 00:46:49 UTC; 6 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim

May 30 09:53:54 HAOS-VM systemd[1]: Started Discard unused filesystem blocks once a week.

The time ‘since’ is the time when my HA-OS VM was last restarted.

Hi pelleravn,

I am experiencing exactly the same problems as you.
I am running HA now for at least 1,5 years on a Proxmox VM.
This setup ran smoothly for about 1 year, and since the beginning of this year I am running into problems with HA.
It took me a while before I knew it was SSD related and that fstrim would solve it.
Since I have enabled the fstrim service (and timer) multiple times, and thinking that all was solved, only to be running into issues again. (this weekend I had another episode).

I have the feeling that something may go wrong with fstrim scheduling and the HAOS or HA updates, as the scheduling seems to work for sometime and then suddenly breaks.
If things break they break badly, as HA will be inoperable its running but is no longer accessible even via the console. Restarting etc. will not work. Fortunately I do make VM backups daily, and restoring the one from the prev. day allows me to run the fstrim.

I would like to know if there is anyway on how I can monitor the following in HA:

  1. fstrim timer state (running, next run)
  2. Diskusage (files)
  3. Free Diskspace
  4. Free unused blocks (iow when does fstrim need to be run)
  5. execute fstrim for an automation

It would be nice to have a headsup that something is about to go wrong.
And better yet fix it automatically.

BTW: I checked the link to Alternative installations, but did not find any related info.

I really love HA, but this is getting a bigger concern.
Hope someone can help.

Best Regards,

Robin