Why does apt run out of space inside a Docker build on macOS?

The free space reported by macOS is not the space available inside the Linux VM used by Docker Desktop. The build runs in that VM and may also be constrained by the selected builder or its filesystem quota. Check the space from inside the build with commands such as `df -h` and `df -i`, and inspect Docker Desktop’s VM or disk-image usage rather than relying on the host’s `df` output. Increase the Docker Desktop disk limit or recreate/clean the builder if its virtual filesystem has reached its quota. A multi-platform build can consume space for both architectures.

`docker buildx du` only shows BuildKit’s tracked cache; it does not necessarily explain every filesystem limit encountered by a running build. Also, a single large RUN instruction can temporarily require space for downloaded archives, unpacked packages, intermediate files, PHP-extension builds, and the resulting image layer at the same time. Avoid `apt upgrade` unless it is truly needed, use `--no-install-recommends`, and clean up in the same layer after installation: remove `/var/lib/apt/lists/*`, clear `/var/cache/apt/archives/*`, and delete compiler/build artifacts. You can also use a cache mount for apt or separate build and runtime stages.

For troubleshooting, temporarily add `RUN df -h; df -i; du -xhd1 /var /usr 2>/dev/null | sort -h` before the failing install. That will show whether bytes or inodes are exhausted and which directory is responsible. Because the build targets two platforms, test each platform separately first. If each succeeds alone but the combined build fails, the additional BuildKit and per-platform temporary storage is the likely cause.

The error occurring while creating `/var/cache/apt/archives/partial` and its lock confirms that the Linux filesystem available to the build is full, not that the package count itself is invalid. Since pruning did not help, check the actual builder with `docker buildx inspect --bootstrap`, verify which builder is active, and examine Docker Desktop’s disk-image allocation. If the VM has a small fixed filesystem or stale builder data, increasing the disk allocation alone may not change that existing filesystem; resetting or recreating the builder can be necessary. Recheck with `df -h` and `df -i` during the failing step to rule out inode exhaustion.