Docker hosed 15 characters

General
,
1

My Docker Desktop space recently became full, coincidentally around the same time as the Docker Desktop 4.62.0 version released.

Getting all kinds of random errors when building images or running containers.

Tried docker {system, buildx} prune, but they kept claiming to restore 150 GB of space, over and over.

Tried rebooting.

Tried deleting Docker Desktop data.

Tried Docker Desktop factory restore.

Tried reinstalling Docker Desktop.

Now, I can’t even build images reliably:

ERROR: failed to build: failed to solve: rpc error: code = Unknown desc = io: read/write on closed pipe

macOS Tahoe, Apple Silicon.

4

Could 4.62.0 have triggered this deep, systemic Docker state corruption? I’ve already lost two hours of work to Docker screwing up.

5

macOS showed a very belated warning about the host TiB disk getting full. Hopefully that is the root cause. Planning to re-reinstall Docker Desktop after that, just in case.

6

Okay, Docker Desktop is to blame here.

After factory restore, it insisted on allocating 99% of my host disk for Docker internals. This soon triggered a macOS prompt about disk space getting low.

Originally, I had that resource pegged to around 200 GB, not 926.35 GB. WTF, Docker.

7

abuild in Alpine Linux consistently triggers disk space capacity errors in Docker 4.26.0. With Disk usage limit set to 512 GB. On a 1 TiB host mount with 300 GB unused.

I can’t do my work. So pissed that I decided to blindly apply the Docker update. It broke everything, and there’s no way to run my containers anymore.

8

There are a ridiculous number of problems with this version of Docker Desktop. On top of everything else, factory reset ALWAYS forces the virtual disk to 99% of my 1 TiB host, causing cascading problems for the host OS. FFS.

9

The uninstaller isn’t actually removing 100% of Docker components.

In fact, we have file paths that sudo isn’t able to get rid of.

% sudo rm -rf ~/Library/Containers/com.docker.docker
Password:
rm: cannot remove '/Users/andrew/Library/Containers/com.docker.docker/.com.apple.containermanagerd.metadata.plist': Operation not permitted

This seems to be a problem where iTerm2 lacks the Full Disk permission… macOS fails to present a graphical notice about this missing permission… and iTerm2 never prompts to request the permission.

Curious if Tahoe may have altered RBAC in a way that Docker Desktop hasn’t accounted for.

In any case, the official Docker Desktop uninstall feature is silently leaving behind many components, which explains why reinstalling does nothing to fix the virtual disk problems.

10

Fresh installs are also greedy, attempting to allocate the entire host 1 TiB disk, instead of selecting a reasonable value.

Don’t grab more than 128 GiB by default, please. You end up wrecking the host operating system.

Manually deleted ~/Library/Containers/com.docker.docker, ~/.docker, and ~/Library/Group\ Containers/group.com.docker. Going for my third or fourth Docker Desktop install today.

1 Like
11

Update:

abuild in library/alpine:3.23 specifically appears to be triggering Docker Desktop virtual disk filling up somehow.

This started happening today.

12

The stalling behavior was caused by rsubst silently treating an unexported shell variable as blank, which was creating a cp -r… command in the container to copy the system inside itself, filling up disk.

Found my typo. Yay.

13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.