High Disk Usage after updating to 4.27.1 on Mac M2

[arun-vasudevan-nair]

Description

Disk Usage shows 5.60 GB available of 196.53 GB.

I deleted all images except moby/buildkit which is around 250MB.

Still no disk space is freed.

Reproduce

1. Run docker buildx build --platform=linux/amd64,linux/arm64 --push -t test-name .
2. Repeat above for at least six different images
3. Delete images
4. Check Disk Usage in docker desktop

Expected behavior

I should get back at least 50 GB, but currently I only have around 5 GB left.

docker version

Client:
 Cloud integration: v1.0.35+desktop.10
 Version:           25.0.2
 API version:       1.44
 Go version:        go1.21.6
 Git commit:        29cf629
 Built:             Thu Feb  1 00:18:45 2024
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.27.1 (136059)
 Engine:
  Version:          25.0
  API version:      1.44 (minimum version 1.24)
  Go version:       go1.21.6
  Git commit:       fce6e0ca9bc000888de3daa157af14fa41fcd0ff
  Built:            Thu Feb  1 00:15:46 2024
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.6.28
  GitCommit:        ae07eda36dd25f8a1b98dfbf587313b99c0190bb
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Version:    25.0.2
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.12.1-desktop.4
    Path:     /Users/removed/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.24.3-desktop.1
    Path:     /Users/removed/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container. (Docker Inc.)
    Version:  0.0.22
    Path:     /Users/removed/.docker/cli-plugins/docker-debug
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.0
    Path:     /Users/removed/.docker/cli-plugins/docker-dev
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.21
    Path:     /Users/removed/.docker/cli-plugins/docker-extension
  feedback: Provide feedback, right in your terminal! (Docker Inc.)
    Version:  v1.0.4
    Path:     /Users/removed/.docker/cli-plugins/docker-feedback
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.0.0
    Path:     /Users/removed/.docker/cli-plugins/docker-init
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/removed/.docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.3.0
    Path:     /Users/removed/.docker/cli-plugins/docker-scout
WARNING: Plugin "/Users/removed/.docker/cli-plugins/docker-scan" is not valid: failed to fetch metadata: fork/exec /Users/removed/.docker/cli-plugins/docker-scan: no such file or directory

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 1
 Server Version: 25.0
 Storage Driver: stargz
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: runc sysbox-runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
  cgroupns
 Kernel Version: 6.6.12-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 7.756GiB
 Name: docker-desktop
 ID: 7e5c02f6-d223-491b-82d3-cbef7cd03aed
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: daemon is not using the default seccomp profile

Diagnostics ID

D4A6E2E8-9D29-4913-B90C-A41CF33B1B1D/20240214095630

Additional Info

No response

[bsousaa]

have you enabled the containerd image store (Under Settings > General)? When you activate this feature you have a second image store, so you may (de)activate to switch to the other store and verify if you have images there.

[benz0li]

I encounter the same with v4.28.0 on a Mac mini M1.

Just pull some heavy images and delete them afterwards. 👉 If you repeat this multiple times, the [VMs] disk[^1] is full at some point.

[^1]: In my case 64 GB

---

docker system df reports something different, though:

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          12        12        27.3GB    5.749GB (21%)
Containers      13        4         575.3kB   0B (0%)
Local Volumes   1         1         48.77MB   0B (0%)
Build Cache     0         0         0B        0B

[benz0li]

This happens both using virtualization framework and QEMU for creating and managing Docker Desktop Linux VM.

[benz0li]

@bsousaa I Use containerd for pulling and storing images now.

The containerd image store is not affected by this issue.

[benz0li]

so you may (de)activate to switch to the other store and verify if you have images there.

I had to execute Clean / Purge Data multiple times with Docker Desktop versions ≥ 4.27.1 over the past months to start from scratch - i.e. with a new [Docker Machine] Linux VM.

@bsousaa IMHO docker image rm (or any command invoking it) does not reclaim space when using the default image store with Docker Desktop versions ≥ 4.27.1.

[benz0li]

I was mistaken: The containerd image store is also affected by this issue.

[bsousaa]

@benz0li is it possible that you are deleting the images in one store but not the other? Basically, you have now the classic image store plus the containerd one - but only one is activated at a time. So when you are pruning your images you are cleaning one of the stores, and you have to switch to the other one to prune and reclaim your entire disk space.

Is this the case?

[benz0li]

@benz0li is it possible that you are deleting the images in one store but not the other?

@bsousaa No. I always Clean / Purge Data before [and also after] switching the image store and then stay with that image store.

At some point, the [Docker Machine] Linux VM's disk is full and I have to Clean / Purge Data again.

[benz0li]

@bsousaa ℹ️ I downgraded to v4.26.1, unticked both Automatically check for updates and Always download updates at Settings > Software updates and everything is back to normal.