Repository navigation
Bug: Error while fetching server API version #757
Description
Describe the bug
The library is raising a DockerException when trying to fetch the server version. I saw multiple older issues related to this issue, but it's now repeating.
To Reproduce
def create_container():
container = PostgresContainer("pgvector/pgvector:pg17", driver=None)
container.start()Runtime environment
- M1 Pro
- Python 3.12.8
- Docker Desktop 4.37.2 (179585)
- Testcontainers 4.9.0 installed via uv
Results of running docker context ls:
NAME DESCRIPTION DOCKER ENDPOINT ERROR
default Current DOCKER_HOST based configuration unix:///var/run/docker.sock
desktop-linux * Docker Desktop unix:///Users/naamanhirschfeld/.docker/run/docker.sock
Activity
techanfa commentedon Jan 12, 2025
Same issue for
M3 chip,
Docker desktop 4.37.1
testcontainers 4.9.0 installed via poetry.
Same output from
docker context lsalexanderankin commentedon Jan 13, 2025
My guess is that this is happening with one of the components maintained by docker, either docker desktop or the python docker client, we don't really have docker desktop in the cicd, it's not so easy to install there. I'll try to take a look if it's that, see if upgrading the python docker client helps, in case it's not the latest or something. There have been instances of python requests library causing issues as well
Goldziher commentedon Jan 13, 2025
Thank you. I reinstalled docker desktop, cleaned everything up, and restarted, and... It magically resolved.
I hate it when things are so obscure, but at least my tests are passing again.
I imagine it is something in docker desktop that is fucking things up.
Weirdly though, I was able to communicate with docker normally even when the test container library was not.
jacobmiller22 commentedon Jan 13, 2025
Same issue, had to reinstall docker desktop after macos Sequoia update.
laurens-teirlynck commentedon Feb 11, 2025
I've also managed to fix the same issue by re-installing Docker after a Mac update. Maybe this issue can be closed since it doesn't seem to be caused by
testcontainersitself.levrik commentedon Apr 1, 2025
I compared the locations of the
.sockfiles of both pre-configured contexts between my system and the one of a colleague who doesn't have this issue. For him there's a symbolic link from/var/run/docker.sock(defaultcontext) to~/.docker/run/docker.sock(linux-desktopcontext) which is missing from my system.I manually created it on my machine via
sudo ln -s ~/.docker/run/docker.sock /var/run/docker.sockwhich fixes the issue. No re-install needed.Goldziher commentedon Apr 1, 2025
I switched to using colima, and test-containers completely fails.
vemonet commentedon Apr 28, 2025
@levrik solution works
There was issues with testcontainers not capable of finding the docker socket if it was not in the traditional path
/var/run/docker.sockIt was recently fixed here: 6817582 it might work out of the box since this change, but it has not yet been released
kiview commentedon Apr 28, 2025
For better triaging and debugging (for users, but also us maintainers), it seems useful to fail with a clearer error message, if there are issues when communicating (or even finding) the right Docker socket.
peacefulseeker commentedon Jun 3, 2026
In case anyone else uses Rancher Desktop,
the symlink approach seems quickest to fix the issue raised here:
sudo ln -sf /Users/$USER/.rd/docker.sock /var/run/docker.sockTranquility2 commentedon Jun 6, 2026
This is likely worth re-checking now that a couple of relevant changes have landed for 4.15.0:
DOCKER_HOSTfrom the activedocker context.In the original report the active context is
desktop-linux(pointing at~/.docker/run/docker.sock), so testcontainers should now use that socket automatically instead of falling back to/var/run/docker.sock, which removes the need for theln -sworkaround.This should also cover the Colima case from the later comment, since Colima registers its own
docker contextpointing at~/.colima/default/docker.sock.These build on the earlier rootless-socket fix (#779).
So for anyone still hitting this: could you retry on 4.15.0 (once released) and report back?
One caveat: the context auto-detection only kicks in when your active context is non-
default. A misconfigureddefaultcontext still relies on the rootless-socket handling from #779.fix(core): make is_podman respect resolved docker host (#1048)