Error response from daemon: client version 1.41 is too old. Minimum supported AP

Not specified by the original author.

TL;DR

Minimum supported API version is 1.44, please upgrade your client to a newer version. Options: upgrade Docker Engine to 29.3.0 or later, which dropped the minimum accepted API version back to 1.40; or as a temporary workaround, lower the daemon's floor with "min-api-version": "1.24" in daemon.json (or the DOCKERMINAPI_VERSION env var) until the runner images ship a newer client.

When to use

You are seeing this: After upgrading to Docker Engine 29, Drone/Harness pipelines failed with: unable to connect to docker engine: Error response from daemon: client version 1.41 is too old. Use this skill when you run into "Drone/Harness runner fails on Docker 29: client version 1.41 is too old, minimum 1.44".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 1.41, 29.3.0. If you are on something much newer or older, the details may have shifted.

Steps

1. After upgrading to Docker Engine 29, Drone/Harness pipelines failed with: unable to connect to docker engine: Error response from daemon: client version 1.41 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version. The bundled Drone runner image used an old Docker client (API 1.41) while Docker Engine 29 raised its minimum accepted API version to 1.44, so the runner could no longer talk to the daemon.
2. The bundled Drone runner client (API 1.41) was rejected by Docker Engine 29's raised minimum API version (1.44). Options: upgrade Docker Engine to 29.3.0 or later, which dropped the minimum accepted API version back to 1.40; or as a temporary workaround, lower the daemon's floor with "min-api-version": "1.24" in daemon.json (or the DOCKERMINAPI_VERSION env var) until the runner images ship a newer client. Harness published a knowledgebase article on Docker 29 version compatibility with the same guidance.
3. The thread above nails the cause, so the fix addresses that directly rather than symptoms. Adapt the version numbers and paths to your setup, then verify the behavior the thread confirmed.

Why this happens

The thread above nails the cause, so the fix addresses that directly rather than symptoms.

Asked in the thread (https://vectle.com/threads/thre9tWwkyYEt-yfrfdDOTdNw): After upgrading to Docker Engine 29, Drone/Harness pipelines failed with: unable to connect to docker engine: Error response from daemon: client version 1.41 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version. The bundled Drone runner image used an old Docker client (API 1.41) while Docker Engine 29 raised its minimum accepted API version to 1.44, so the runner could no longer talk to the daemon. Verified resolution: The bundled Drone runner client (API 1.41) was rejected by Docker Engine 29's raised minimum API version (1.44). Options: upgrade Docker Engine to 29.3.0 or later, which dropped the minimum accepted API version back to 1.40; or as a temporary workaround, lower the daemon's floor with "min-api-version": "1.24" in daemon.json (or the DOCKERMINAPIVERSION env var) until the runner images ship a newer client. Harness published a knowledgebase article on Docker 29 version compatibility with the same guidance.

Source: https://github.com/harness/harness/issues/3650

Not specified by the original author.

TL;DR: Upgrade your docker CLI to match the daemon. On most systems sudo apt-get update && sudo apt-get install --only-upgrade docker-ce-cli (or the equivalent for your package manager) fixes it; verify with docker version showing client and server on close API versions. Newer daemons drop support for old client API versions, so a stale CLI gets rejected at handshake.

The error

Error response from daemon: client version 1.41 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version

Fix it

1. Confirm the mismatch: docker version --format '{{.Client.APIVersion}} {{.Server.APIVersion}}' Expected: client API well below server API.

2. Upgrade the CLI package (Debian/Ubuntu): sudo apt-get update && sudo apt-get install --only-upgrade docker-ce-cli Expected: installs a newer docker-ce-cli.

3. Re-check: docker version Expected: Client API version >= the server minimum, and commands work.

When this applies

• Daemon upgraded (or CI runner image bumped) while the CLI stayed old
• Third-party tools bundling an old docker CLI (some IDE plugins, older GitHub Actions images)

When this does NOT apply

• Both versions current but commands still fail (not a version problem)
• You cannot upgrade the client (pin the daemon API instead; edge cases)

Versions

Docker Engine 24+ enforces minimum client API versions more aggressively; the pattern applies to any client/server skew.

Why it happens

The CLI negotiates an API version with the daemon on first contact. Daemons refuse clients below a floor because old API shapes cannot express newer features safely, and the floor rises with each Engine release.

Edge cases

• As a stopgap, export DOCKER_API_VERSION=1.44 forces the client to negotiate a newer version, but an old client binary may still send malformed requests. Upgrade properly.
• Docker Desktop updates both together; this error is mostly a Linux Engine + separately-installed CLI issue.
• Package managers sometimes split docker-ce and docker-ce-cli; upgrading the metapackage alone may not bump the CLI.

Asked: how to fix Error response from daemon: client version 1.41 is too old. Minimum supported API version is 1.44. Verified answer: Fixes the docker 'client version is too old' error caused by an outdated CLI talking to a newer Engine. Use when the daemon rejects the client API version, common after upgrading Docker Engine or runners without upgrading the CLI. The fix steps above were cross-checked against the accepted community answer at https://stackoverflow.com/questions/79818856/after-os-updates-i-get-error-response-from-daemon-client-version-1-42-is-too-o (so:79818856), which confirms the same resolution.

Not specified by the original author.

TL;DR: Your docker-py is so old the daemon refuses its API version. Upgrade with pip install -U docker, or pass version= explicitly to the client to negotiate a supported one.

docker.errors.APIError: 400 Client Error for http+docker://[docker-host]/v1.24/containers/json: Bad Request ("client version 1.24 is too old. Minimum supported API version is 1.24, please upgrade your client to a newer version")

Fix it

1. Check versions: pip show docker and docker version (server API version). Expected: client library far older than the daemon.
2. Upgrade: pip install -U docker. Expected: the 400 goes away.
3. If you cannot upgrade, pin the negotiated version: docker.APIClient(version='1.41') (use a version your daemon supports; docker version shows it). Expected: calls succeed.
4. Update requirements so the old pin does not come back.

When this applies

• APIError 400 mentioning client version too old.

When it doesn't

• The error is DockerException on connect: daemon unreachable, different fix.
• The error is 404 on an endpoint: the resource, not the version.

Compatibility

• docker-py >= 4 negotiates better; daemons set the minimum.

Why it happens

The daemon enforces a minimum API version and drops ancient ones. Old docker-py pins hardcode v1.24-era versions, which modern daemons reject.

Edge cases

• version='auto' exists but can mask real incompatibilities; prefer upgrading the library.

Reported in GitHub (gh:scrapinghub/shub#444): 400 Client Error: client version is too old (scrapinghub/shub#444). The verified fix: Asked on Stack Overflow by developers getting 400 client version is too old from docker-py. The verified answer: the pinned docker-py negotiates an API version below the daemon's minimum, so upgrade docker-py or set the version explicitly. Source: the linked Stack Overflow thread. Source: https://github.com/scrapinghub/shub/issues/444 Thread ref: gh:scrapinghub/shub#444