Docker Space issues on USB flash drive. /var/lib/containerd taking up space on drive

Quote from redneckgamer88

Interesting. Try running the following in terminal and post the results.

Code

docker info | grep "Storage Driver"

fred@omv:~$ docker info | grep "Storage Driver"

Storage Driver: overlay2

I have this issue too. Started yesterday after everything running fine for months on my prod system.

I am getting my logs filled with these messages - literally 10 plus logs per second

2/1/2025, 4:47:21 PM
containerd[19150]: time="2025-12-01T16:47:21.849619415+11:00" level=error msg="unable to parse \"max 0\" as a uint from Cgroup file \"/sys/fs/cgroup/system.slice/docker-fc3b3f825c60e54c614cd7e14e02458d18833d3a2a90cb5612832a4248afa658.scope/hugetlb.1GB.events\""

I have googled this error to death but I can't find anything that fixes this issue.

Looking at my omv-os disk it is half full but seems to have stabilised but this is not good - 13GB in io.containerd.snapshotter.v1.overlayfs

OP can you step me through the issue and solution so I can see if I can fix this?

I have replicated this issue on a clean installation - I thought it might be hardware issue but looks like I can fix it

Downed/stopped all containers

Stopped docker service

Deleted containerd directory

Deleted docker storage location on ssd

Reinstalled docker using location on system disk (SSD - not omv install disk)

started one container - dozzle and same issue

noted the following when reinstalling docker (in omv reinstall window) but not sure if this is a clue...

Have replicated this issue with omv7 and a clean omv8 install.

Package 'docker.io' is not installed, so not removed
Package 'containerd' is not installed, so not removed
Package 'docker-compose' is not installed, so not removed

docker info

root@minipc:~# docker info
Client: Docker Engine - Community
 Version:    29.1.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.30.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.40.3
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 29.1.1
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1c4457e00facac03ce1d75f7b6777a7a851e5c41
 runc version: v1.3.4-0-gd6d73eb8
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.14.11-4-pve
 Operating System: Debian GNU/Linux 13 (trixie)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 15.37GiB
 Name: minipc
 ID: 28e9a182-f9ae-4e82-9825-aa4062345e81
 Docker Root Dir: /srv/dev-disk-by-uuid-615ffa8d-af1c-4533-89ed-59c405de5dfa/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

Thank you redneckgamer88. I will try again making the change to the storage driver.

My system minipc does not seem to have containerd installed on omv8

I have omv8 with docker on a rpi5 but don’t have this issue. [edit - actually I do have the issue but I only run 2 containers on it so hadn't noticed disk usage]

Not sure what’s going on here but very strange and thanks for your help

So just checked all of my omv systems running docker. Results below.

Looks like a recent change to docker defaults but maybe only applied to new installs?

rpi4 - omv7 (have not reinstalled or changed docker for ages)

• Architecture: aarch64
• Storage Driver: overlay2
• driver-type: n/a

rpi5 - omv8 (clean install of omv8 so docker install very recent)

• Architecture: aarch64
• Storage Driver: overlayfs
• driver-type: io.containerd.snapshotter.v1

minipc - omv8 (clean install of omv8 so docker install very recent)

• Architecture: x86_64
• Storage Driver: overlayfs
• driver-type: io.containerd.snapshotter.v1

I can confirm the issue and fix is to change storage driver in daemon.json

I can see that containerd snapshotter is false when docker starts from my logs after changing the storage driver

So I think this might cause some issues for new installs of docker/compose plugin

dockerd[227333]: time="2025-12-02T07:32:21.347650513+11:00" level=info msg="Docker daemon" commit=9a84135 containerd-snapshotter=false storage-driver=overlay2 version=29.1.1

Quote from ryecoaaron

I hope omv7 doesn't have this issue

Understood. I have only seen this on omv8 but have not tried re-installation of docker or clean install of omv7 recently.

I’m also seeing this on a fresh Debian 13.2 install with Docker 29.1.1. Journalctl is getting flooded with errors like:

Dec 02 08:14:24 firebat containerd[738]: time="2025-12-02T08:14:24.846853387+01:00" level=error msg="unable to parse \"max 0\" as a uint from Cgroup file \"/sys/fs/cgroup/system.slice/docker-140e0740e7d1bce6a88e3288e95fe7e6f3a358423097999195249672af19b6ba.scope/hugetlb.2MB.events\""
Dec 02 08:14:24 firebat containerd[738]: time="2025-12-02T08:14:24.847152514+01:00" level=error msg="unable to parse \"max 0\" as a uint from Cgroup file \"/sys/fs/cgroup/system.slice/docker-140e0740e7d1bce6a88e3288e95fe7e6f3a358423097999195249672af19b6ba.scope/hugetlb.1GB.events\"

They repeat constantly for every running container.

I already switched the Docker storage driver to overlay2 (confirmed in docker info), but the errors continue. My system is using:

Quote

Client: Docker Engine - Community

Version: 29.1.1

Context: default

Debug Mode: false

Plugins:

buildx: Docker Buildx (Docker Inc.)

Version: v0.30.1

Path: /usr/libexec/docker/cli-plugins/docker-buildx

compose: Docker Compose (Docker Inc.)

Version: v2.40.3

Path: /usr/libexec/docker/cli-plugins/docker-compose

model: Docker Model Runner (Docker Inc.)

Version: v1.0.2

Path: /usr/libexec/docker/cli-plugins/docker-model

Server:

Containers: 28

Running: 27

Paused: 0

Stopped: 1

Images: 28

Server Version: 29.1.1

Storage Driver: overlay2

Backing Filesystem: extfs

Supports d_type: true

Using metacopy: false

Native Overlay Diff: true

userxattr: false

Logging Driver: json-file

Cgroup Driver: systemd

Cgroup Version: 2

Plugins:

Volume: local

Network: bridge host ipvlan macvlan null overlay

Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog

CDI spec directories:

/etc/cdi

/var/run/cdi

Swarm: inactive

Runtimes: io.containerd.runc.v2 runc

Default Runtime: runc

Init Binary: docker-init

containerd version: 1c4457e00facac03ce1d75f7b6777a7a851e5c41

runc version: v1.3.4-0-gd6d73eb8

init version: de40ad0

Security Options:

apparmor

seccomp

Profile: builtin

cgroupns

Kernel Version: 6.12.57+deb13-amd64

Operating System: Debian GNU/Linux 13 (trixie)

OSType: linux

Architecture: x86_64

CPUs: 4

Total Memory: 15.4GiB

Name: firebat

ID: 6d23ec60-1065-442a-bcbe-cf259915f57e

Docker Root Dir: /var/lib/docker

Debug Mode: false

Experimental: false

Insecure Registries:

::1/128

127.0.0.0/8

Live Restore Enabled: false

Firewall Backend: iptables

Display More

Quote from Korveck

I’m also seeing this on a fresh Debian 13.2 install with Docker 29.1.1. Journalctl is getting flooded with errors like:

Code

Dec 02 08:14:24 firebat containerd[738]: time="2025-12-02T08:14:24.846853387+01:00" level=error msg="unable to parse \"max 0\" as a uint from Cgroup file \"/sys/fs/cgroup/system.slice/docker-140e0740e7d1bce6a88e3288e95fe7e6f3a358423097999195249672af19b6ba.scope/hugetlb.2MB.events\""
Dec 02 08:14:24 firebat containerd[738]: time="2025-12-02T08:14:24.847152514+01:00" level=error msg="unable to parse \"max 0\" as a uint from Cgroup file \"/sys/fs/cgroup/system.slice/docker-140e0740e7d1bce6a88e3288e95fe7e6f3a358423097999195249672af19b6ba.scope/hugetlb.1GB.events\"

They repeat constantly for every running container.

I already switched the Docker storage driver to overlay2 (confirmed in docker info), but the errors continue. My system is using:

This issue is unrelated to the overlayfs issue. My mistake for thinking they were.

This issue is a bug with containerd and is being looked at by containerd devs. I posted a new thread on the forum on the containerd bug

ryecoaaron - I think this issue is with containerd 2.2

I am already on 2.2 and have the issue

One temporary solution I have seen on github is to install 2.1.5 but I haven't tried this

Does anyone have a shell command or other action that can be used to reliably trigger this journal flooding on demand?

Quote from gderf

Does anyone have a shell command or other action that can be used to reliably trigger this journal flooding on demand?

I know that dozzle container with a standard setup triggers it.

more info here... bug in containerd impacting dozzle and potentially other containers

The issue on github dozzle linked above has some useful links to the containerd issue