Repository navigation
Open
Labels
Description
Description
For a few days already I've been facing this weird issue. Anytime I want to run docker compose up I'm given the following error:
Network midas_default Created 0.0s
✔ Container ea85756a438f Removed 0.0s
✘ Container 44b9cb711bf2 Error response from daemon: No such container: 44b9cb711bf25a3d19ef8a5254c0... 0.2s
Error response from daemon: No such container: 44b9cb711bf25a3d19ef8a5254c08df820f22f72a98464e4d17beb6156dbbeb0
The id of this container remains the same across restarts of the docker engine, docker desktop app, and system reboots.
The docker ps -a command shows that the container causing the problem is already exited.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
44b9cb711bf2 postgres:17.6-alpine3.22 "docker-entrypoint.s…" 3 weeks ago Exited (0) 3 weeks ago
ea85756a438f postgres:17.6-alpine3.22 "docker-entrypoint.s…" 5 weeks ago Exited (0) 5 weeks ago
cbfecd6aedec 88e904502786 "docker-entrypoint.s…" 2 months ago Exited (128) 2 months ago
I've tried running:
docker compose down --remove-orphansdocker system prune -fdocker rm 44b9cb711bf2 ea85756a438fdocker volume prune -fdocker network prune -f
but none worked out.
Reproduce
There's no such list of steps I've done to get to this issue. The fact that it says that the problematic container is exited 3 weeks ago, I doubt I could remember any.
The only thing that comes to my mind is I probably shut down the computer with the containers running.
Expected behavior
docker compose up should start my application normally.
docker version
Client:
Version: 28.4.0
API version: 1.51
Go version: go1.24.7
Git commit: d8eb465
Built: Wed Sep 3 20:56:28 2025
OS/Arch: linux/amd64
Context: desktop-linux
Server: Docker Desktop 4.54.0 (212467)
Engine:
Version: 29.1.2
API version: 1.52 (minimum version 1.44)
Go version: go1.25.5
Git commit: de45c2a
Built: Tue Dec 2 21:55:26 2025
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v2.2.0
GitCommit: 1c4457e00facac03ce1d75f7b6777a7a851e5c41
runc:
Version: 1.3.4
GitCommit: v1.3.4-0-gd6d73eb8
docker-init:
Version: 0.19.0
GitCommit: de40ad0docker info
Client:
Version: 28.4.0
Context: desktop-linux
Debug Mode: false
Plugins:
ai: Docker AI Agent - Ask Gordon (Docker Inc.)
Version: v1.17.0
Path: /home/detectivekaktus/.docker/cli-plugins/docker-ai
buildx: Docker Buildx (Docker Inc.)
Version: v0.30.1-desktop.1
Path: /home/detectivekaktus/.docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.40.3-desktop.1
Path: /home/detectivekaktus/.docker/cli-plugins/docker-compose
debug: Get a shell into any image or container (Docker Inc.)
Version: 0.0.45
Path: /home/detectivekaktus/.docker/cli-plugins/docker-debug
desktop: Docker Desktop commands (Docker Inc.)
Version: v0.2.0
Path: /home/detectivekaktus/.docker/cli-plugins/docker-desktop
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.31
Path: /home/detectivekaktus/.docker/cli-plugins/docker-extension
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.4.0
Path: /home/detectivekaktus/.docker/cli-plugins/docker-init
mcp: Docker MCP Plugin (Docker Inc.)
Version: v0.28.0
Path: /home/detectivekaktus/.docker/cli-plugins/docker-mcp
offload: Docker Offload (Docker Inc.)
Version: v0.5.29
Path: /home/detectivekaktus/.docker/cli-plugins/docker-offload
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: /home/detectivekaktus/.docker/cli-plugins/docker-sbom
scout: Docker Scout (Docker Inc.)
Version: v1.18.3
Path: /home/detectivekaktus/.docker/cli-plugins/docker-scout
Server:
Containers: 11
Running: 0
Paused: 0
Stopped: 11
Images: 3
Server Version: 29.1.2
Storage Driver: overlayfs
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
CDI spec directories:
/etc/cdi
/var/run/cdi
Discovered Devices:
cdi: docker.com/gpu=webgpu
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:
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.12.54-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.747GiB
Name: docker-desktop
ID: 5451c208-2b4c-4661-bd3e-30265731c491
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
Labels:
com.docker.desktop.address=unix:///home/detectivekaktus/.docker/desktop/docker-cli.sock
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
::1/128
127.0.0.0/8
Live Restore Enabled: falseDiagnostics ID
74C1C55D-8CDA-4775-B05D-BCF8BF2D8C57/20251215172806
Additional Info
No response
Reacted by Zen Voich
Activity
akerouanton commentedon Dec 15, 2025
Thanks for reporting @detectivekaktus. I've opened moby/moby#51724 to fix the symptoms. With that fix, you should be able to remove that otherwise unremovable container.
lukasz-matter commentedon Jan 14, 2026
I'm also affected by this issue. Are there any known workarounds? I'd very much like to have my
docker-composeenvironment to work 😅EDIT: changing the name of the affected service in the
docker-compose.yamlfile is a workaround for this issue. Thedocker compose down --remove-orphansfails, but removes all the containers it can before.detectivekaktus commentedon Jan 28, 2026
Any updates on this one?
The @lukasz-matter fix worked for a long time but now docker completely ignores renaming and still doesn't want to start the containers.
raweber42 commentedon Jan 30, 2026
Is there any way to mitigate this? I am stuck with this error, tried rebooting, deleting containers etc, nothing helped
detectivekaktus commentedon Jan 31, 2026
I'm not sure if this behavior is anyhow related to the issue but sometimes Docker desktop just starts shutting down infinitely. Only killing the process resolves the issue. It doesn't matter if there were or weren't containers running, it randomly decides to enter this infinite shutting down state.
alpet83 commentedon Feb 5, 2026
I have same issue, after moving /var/containerd content to dedicated partition without stopping service containerd. Solving are easy - for each container hash need remove same entry from /var/lib/docker/containers and restart docker service.
raweber42 commentedon Feb 9, 2026
I fixed this by shutting down docker compose (
docker compose down), copying thedocker-compose.ymlfile to another folder and bringing itdocker compose up -dagain.Of course, if you have volumes, some adjustments need to be made, but this workaround did it for me.
dabde commentedon Feb 10, 2026
Another way to fix this (debian).
Had 6 Container define under
docker ps -aasDead, all related IDs had to start with docker compose. So looks like a broken reference or so and happen for me after anapt upgrade.To solve:
Deadand remove related Container under/var/lib/docker/containers/detectivekaktus commentedon Feb 17, 2026
Can this be closed since y'all found workarounds and there seems to be no reaction from the devs?
homersimpsons commentedon May 11, 2026
From what I understand this should now be fixed by (allowing removal) with moby/moby#51724 (released on 29.4.0 according to milestones). I know a developer on 29.4.1 that still have the issue though.
Note that a lighter alternative for the issue that works is to set a different
container_namefor the offending container:services: mysql: image: mysql:8.0 + container_name: my_awesomeapp2_mysql(alternatively, setting a
COMPOSE_PROJECT_NAMEworks but re-creates everything including volumes so that may not be desirable)