Docker CLI: docker image prune --all --force is failing in Version 25.0.1

[shabeebk]

Description

We have the latest docker installed in our production systems. We were trying to run the image prune command to clean up the images. However, it fails with this error message: "image prune" requires API version 1.25, but the Docker daemon API version is 1.24

Reproduce

1. Get some images in the host machine.
2. Start some containers and leave some images without attaching them to containers.
3. Run docker image prune --all --force to prune all the images.

Expected behavior

E.g. docker image prune --all --force should remove all images which are not associated with any of the running containers.

docker version

Client: Docker Engine - Community
 Version:           25.0.1
 API version:       1.44
 Go version:        go1.21.6
 Git commit:        29cf629
 Built:             Tue Jan 23 23:09:52 2024
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          25.0.1
  API version:      1.44 (minimum version 1.24)
  Go version:       go1.21.6
  Git commit:       71fa3ab
  Built:            Tue Jan 23 23:09:52 2024
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.6.27
  GitCommit:        a1496014c916f9e62104b33d1bb5bd03b0858e59
 runc:
  Version:          1.1.11
  GitCommit:        v1.1.11-0-g4bccb38
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client: Docker Engine - Community
 Version:    25.0.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.12.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.24.2
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 16
  Running: 16
  Paused: 0
  Stopped: 0
 Images: 48
 Server Version: 25.0.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: a1496014c916f9e62104b33d1bb5bd03b0858e59
 runc version: v1.1.11-0-g4bccb38
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 5.10.0-27-amd64
 Operating System: Debian GNU/Linux 11 (bullseye)
 OSType: linux
 Architecture: x86_64
 CPUs: 12
 Total Memory: 61.32GiB
 Name: docker-2-<REDACTED>
 ID: <REDACTED>
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional Info

No response

[thaJeztah]

is the CLI used to connect with the engine also v25 (as shown in the docker version) output above, or is that an older version? Is the production server running locally, or are you connecting to a remote engine from a local CLI?

[shabeebk]

I am executing the command from the production host itself. So, the answer is yes. I have connected to the host machine and ran all these commands there.

[craeckor]

Same problem here.
I freshly installed Debian 12 with official Docker installation instructions and I get the same error.

[thaJeztah]

I tried reproducing, but wasn't able to.

docker image prune --all --force
Deleted Images:
untagged: foo:latest
deleted: sha256:8751eb43d4ff5d968dab6859b657f6986811def9763b058cd14d38844c91f147
deleted: sha256:95cf88e6d656bf67a2d19979611e3c338274dab05b0569ca87fd767397447e20
deleted: sha256:b0b5ee2acc6c3fb75a530512a9dce2b37a3ce92e3bb78fc41d940316f6ca4dce
deleted: sha256:b98766d04d77bda62a67edced5d7b7fcfb5aec94a239674e85dd63a4e48831ad
untagged: alpine:latest
untagged: alpine@sha256:51b67269f354137895d43f3b3d810bfacd3945438e94dc5ac55fdac340352f48
deleted: sha256:f8c20f8bbcb684055b4fea470fdd169c86e87786940b3262335b12ec3adef418
untagged: busybox:latest
untagged: busybox@sha256:6d9ac9237a84afe1516540f40a0fafdc86859b2141954b4d643af7066d598b74
deleted: sha256:3f57d9401f8d42f986df300f0c69192fc41da28ccc8d797829467780db3dd741
deleted: sha256:2e112031b4b923a873c8b3d685d48037e4d5ccd967b658743d93a6e56c3064b9

Total reclaimed space: 4.262MB

The error indicates that either

• the client is connected with an older version of the daemon that does not support newer versions of the API
• the CLI tried to connect with the API to perform API-version negotiation (for which it uses the /_ping endpoint using HEAD -> GET), and that failed (in which case it falls back to the 1.24 API version)
• or the CLI / client was configured to be pinned to a specific API version.

For that last option, make sure that the DOCKER_API_VERSION environment variable is not set in the environment where you run the CLI. That env-var manually overrides the API version used;

For example;

DOCKER_API_VERSION=1.24 docker image prune --all --force
docker image prune requires API version 1.25, but the Docker daemon API version is 1.24

So it's worth checking;

• if that env-var is set (printenv DOCKER_API_VERSION)
• if you're using sudo to run the docker CLI, note that the command executed runs as a different user, so depending on what options were used to invoke sudo, may (e.g.) be using a different HOME-directory (and ~/.docker/config.json etc).
• also check if you don't happen to have an alias defined for the docker command (command -v docker should show if it's an alias).

[archHavik]

I was able to reproduce this bug. It turns out the docker service was not running. Once I ran

systemctl start docker

It pruned my system without issue. Give that a try?

[shabeebk]

@thaJeztah Thanks for the detailed suggestion. Yes, you are right. The home used by the sudo command was different, and the docker used an old version from the root. It worked as expected when I tried with a docker user (with a su to a user from the docker group).

[neersighted]

Closing as a question/usage error.

[mnvr]

For what it's worth, I came here after being a bit lost why my docker system prune wasn't working, and @archHavik's "It turns out the docker service was not running." helped me realise my mistake. So while it is a question/usage error, I feel the current error message could be better - the actual problem is that it cannot connect to the service, not that the service has an incompatible version.

[neersighted]

That constitutes a bug we fixed; I thought we linked to it from the relevant PR, but clearly not. In any case, yes, the bug is fixed in moby/moby#47440.

I closed this issue as the bug component was already tracked at #4890.

[mnvr]

Great! And thank you 💯