docker-compose command not found

[daeho-ro]

Description

When upgrade docker to 4.32.0, there is no docker-compose command and I confirmed that the .app package does not have one.

I am not sure if this change is intentional or if it is a side effect of removing com.docker.cli. Can anyone confirm this?

Reproduce

docker-compose
zsh: command not found: docker-compose

Expected behavior

No response

docker version

Client:
 Version:           27.0.3
 API version:       1.46
 Go version:        go1.21.11
 Git commit:        7d4bcd8
 Built:             Fri Jun 28 23:59:41 2024
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.32.0 (157355)
 Engine:
  Version:          27.0.3
  API version:      1.46 (minimum version 1.24)
  Go version:       go1.21.11
  Git commit:       662f78c
  Built:            Sat Jun 29 00:02:44 2024
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.7.18
  GitCommit:        ae71819c4f5e67bb4d5ae76a6b735f29cc25774e
 runc:
  Version:          1.7.18
  GitCommit:        v1.1.13-0-g58aa920
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Version:    27.0.3
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.15.1-desktop.1
    Path:     /Users/daeho.ro/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.28.1-desktop.1
    Path:     /Users/daeho.ro/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.32
    Path:     /Users/daeho.ro/.docker/cli-plugins/docker-debug
  desktop: Docker Desktop commands (Alpha) (Docker Inc.)
    Version:  v0.0.14
    Path:     /Users/daeho.ro/.docker/cli-plugins/docker-desktop
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.2
    Path:     /Users/daeho.ro/.docker/cli-plugins/docker-dev
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.25
    Path:     /Users/daeho.ro/.docker/cli-plugins/docker-extension
  feedback: Provide feedback, right in your terminal! (Docker Inc.)
    Version:  v1.0.5
    Path:     /Users/daeho.ro/.docker/cli-plugins/docker-feedback
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.3.0
    Path:     /Users/daeho.ro/.docker/cli-plugins/docker-init
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/daeho.ro/.docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.10.0
    Path:     /Users/daeho.ro/.docker/cli-plugins/docker-scout

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 1
 Server Version: 27.0.3
 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: 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
 Swarm: inactive
 Runtimes: runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: ae71819c4f5e67bb4d5ae76a6b735f29cc25774e
 runc version: v1.1.13-0-g58aa920
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
  cgroupns
 Kernel Version: 6.6.32-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 11
 Total Memory: 7.657GiB
 Name: docker-desktop
 ID: 83b2b64d-8962-4ad5-baea-0fdfbf26df59
 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:///Users/daeho.ro/Library/Containers/com.docker.docker/Data/docker-cli.sock
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Live Restore Enabled: false

Diagnostics ID

67E16B9B-A03B-4D9E-8809-F784135F4E3D/20240707071016

Additional Info

No response

[daeho-ro]

Homebrew/homebrew-cask#178583

[dgageot]

@daeho-ro have you tried docker compose instead? (see https://docs.docker.com/compose/migrate/)

[daeho-ro]

@dgageot It is, of course working but my question is why it is deleted even if the command is deprecated. I cannot find any statement and just want to know what happen.

[dgageot]

@daeho-ro I understand. @glours @ndeloof, was the removal planned? Should it have been listed in the release notes?

[jbernardo95]

+1, running into this issue too 🙏

[LikeAJohny]

Same here.
I used to work around this (or rather towards the deprecation) by creating a script /usr/local/bin/docker-compose simply running

docker compose "$@"

This however is now erroring as well:

Error: spawn Unknown system error -8
Code: Unknown system error -8

[ndeloof]

Compose v2 can run standalone as docker-compose and AFAICT this should be the case within Docker Desktop, but maybe recent removal for legacy compose-cli broke this ?

[glours]

@dgageot there is something wrong in the update process, the symlink should now point to the CLI plugin binary. I'll work with the Stability team to fix this

[glours]

As a workaround you can run the following command:

sudo ln -sf /Applications/Docker.app/Contents/Resources/cli-plugins/docker-compose /usr/local/bin/docker-compose

[LikeAJohny]

While this fixes the problem with running docker-compose at all, my projects now refuse to start due to undefined networks. Since the networks exist prefixed with the project name (just as before) I assume there's something else going wrong with the cli plugin.

[ndeloof]

@LikeAJohny please report error running you application on github.com/docker/compose with error details so we can investigate

[LikeAJohny]

@ndeloof Did so 👍

[LikeAJohny]

Closed the bug ticket since the error originated from an error on my behalf, sorry!

[sc250024]

Getting this too!

[Chienle]

As a workaround you can run the following command:

sudo ln -sf /Applications/Docker.app/Contents/Resources/cli-plugins/docker-compose /usr/local/bin/docker-compose

Thank you so much !

[pepijn-vanvlaanderen]

Is this really an issue or should we just start using docker compose instead? And if you like to use the dashed command you can ofc create an alias to this as well.

[dotconde]

I'm following along with this question ☝🏻.

[kingtistel]

Is this really an issue or should we just start using docker compose instead? And if you like to use the dashed command you can ofc create an alias to this as well.

We have a bunch of scripts executing docker-compose in our CI/CD.
And shell aliases (depending on how IT sets it up) are usually only loaded in interactive shells.

[brock-bouchard]

Are there plans to fix this? I understand there may be intent for users to migrate to docker compose, but isn't that a breaking change that should be go in a major version bump (e.g. 5.0.0)?

[bsousaa]

this should be fixed soon with Desktop 4.33

[glours]

Is this really an issue or should we just start using docker compose instead? And if you like to use the dashed command you can ofc create an alias to this as well.

@pepijn-vanvlaanderen this could be an issue for users who have existing scripts for example, but if you're just running compose commands from your terminal you can safely use docker compose

[p-linnane]

This is not fixed in v4.33.0. See: https://github.com/Homebrew/homebrew-cask/actions/runs/10102090229/job/27937030651?pr=180652

Correction: it is fixed. Looks like it's now in cli-plugins rather than bin.

[omgftw]

I would not consider this fixed. The update (and even re-installing) did not seem to update the symlink in usr/local/bin (it points to the bin location that no longer exists). Meaning that without further user intervention, docker-compose still isn't working.

[theo-staizen]

this should be fixed soon with Desktop 4.33

Updated to 4.33.0 but I still had to manually run the following command to update the symlink

ln -sf /Applications/Docker.app/Contents/Resources/cli-plugins/docker-compose /usr/local/bin/docker-compose

[mm-matthias]

Can confirm the issue still exists with 4.33.0.

[Xeeynamo]

Do you have the option "Automatically check configuration" enabled under Settings > General?

Docker Desktop no longer requires the Administrator password to update. But if you have it installed on a System level (do a cat ~/Library/Group\ Containers/group.com.docker/settings.json | grep dockerBinInstallPath to confirm that) then you need to rely on the configuration check to suggest you any symlink that needs to be re-configured.

This recent blog post should give you a bit more information.

[katcaola]

I ran into the issue myself this morning and stumbled on this stack overflow answer that fixed the issue for me (I'm on 4.32.0 because my Docker Desktop auto updated): https://stackoverflow.com/a/78834693/8184374

Figured I'd post here to be helpful:

I encountered this as a bug after last update (been using Docker often on my machine before)

I fixed it by going to Docker app -> settings -> Advanced

In advanced I had to check off:

Allow the default Docker socket to be used (requires password)
Allow privileged port mapping (requires password)

Click Apply & Restart

And enable again options:

Allow the default Docker socket to be used (requires password)
Allow privileged port mapping (requires password)

And click Apply & Restart

That fixed it for me in terminal

[ndeloof]

Docker Desktop setup creates symlink /usr/local/bin/docker-compose -> /Applications/Docker.app/Contents/Resources/cli-plugins/docker-compose. docker-compose binary can both be used as a CLI plugin (i.e. docker compose ... or standalone for backward compatibility

This issue should be closed AFAICT

[brock-bouchard]

I still experience this problem when I upgrade.

[ndeloof]

After docker compose v1 was eventually declared End of Life, we removed the feature for user to select compose v1 vs v2 as they run docker-compose. The side-effect is that docker-compose command symlink points to a distinct target (/Applications/Docker.app/Contents/Resources/cli-plugins/docker-compose)

During an upgrade, Docker Desktop doesn't run a full installation, so user don't get disturbed by requirement to enter admin/root credentials. This limitation makes it impossible for the update script to change the symlink target.
Recommended workaround is for you to manually recreate the /usr/local/bin/docker-compose symlink

[brock-bouchard]

Are we going to have to recreate this symlink after every upgrade?

[ndeloof]

nope, this is only required after first upgrade to remove compose v1/v2 switch option, which require symlink to change target.

[Xeeynamo]

As mentioned in the Release Notes for Docker Desktop 4.32.0:

For Mac
When running docker-compose after an update, it will return command not found. As a workaround, you can create the following symlink: sudo ln -sf /Applications/Docker.app/Contents/Resources/cli-plugins/docker-compose /usr/local/bin/docker-compose

Docker Desktop also provides some UI to resolve symlink mismatches. Please read my comment above: #7345 (comment).

Are we going to have to recreate this symlink after every upgrade?

No, this was a one-time change.

[mm-matthias]

During an upgrade, Docker Desktop doesn't run a full installation, so user don't get disturbed by requirement to enter admin/root credentials. This limitation makes it impossible for the update script to change the symlink target.
Recommended workaround is for you to manually recreate the /usr/local/bin/docker-compose symlink

Just some feedback from a user of Docker: This decision cost us a lot of time and annoyance. It would've been much better to just prompt for the admin/root credentials instead of having to fiddle around with some Docker internals that I as a user should not have to fiddle around with. The problem occurred for every developer in our group which just multiplied the issue.

If you do another upgrade like this please decide to release a working app instead of a subtly broken one.

[jaygooby]

TLDR; In Settings, Advanced, toggle from System (requires password) to User, click Apply & restart. Then toggle back to System (requires password) and click Apply & restart again.

In a new terminal session you'll see the docker and docker-compose symlinks are correctly placed in /usr/local/bin