Docker buildx and compose commands not found

Help
1

Maybe about a month or so ago, the Docker buildx (docker buildx) and compose (docker compose) commands were working for me, but today I noticed that I was getting some unknown command errors (e.g., docker: unknown command: docker buildx).

Here’s the relevant part of my configuration, which I have not changed at all.

virtualisation.docker = {
    enable = true;
    rootless = {
      enable = false;
      setSocketVariable = false;
    };
  };

Running docker info seems to show that the plugins are being noticed.

Client:
 Version:    28.3.2
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.25.0
    Path:     /nix/store/ypndr8cz6f3v90m5m380nwisrwgwf063-docker-plugins/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  2.38.1
    Path:     /nix/store/ypndr8cz6f3v90m5m380nwisrwgwf063-docker-plugins/libexec/docker/cli-plugins/docker-compose

I’m on NixOS unstable branch (25.11.20250728.dc96378 (Xantusia)). Just wanted to know if I perhaps did something on my end, or if it’s something I would need to wait for a fix. I’m not too much of an expert on either NixOS or Docker.

1 Like
2

Tried using an overlay to use the nixos-25.05 branch for Docker, but still getting unknown command errors with docker compose and docker buildx after rebuilding. Doing docker info still shows like it’s there.

Client:
 Version:    27.5.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.23.0
    Path:     /nix/store/n1xyy00gjxy4vlmjgfcj64kngz1jz9n4-docker-plugins/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  2.36.0
    Path:     /nix/store/n1xyy00gjxy4vlmjgfcj64kngz1jz9n4-docker-plugins/libexec/docker/cli-plugins/docker-compose

Not sure what the issue might be.

3

This is nixpkgs section of my flake.lock file, with docker CLI still working as expected for HEAD of ref nixos-25.05:

    "nixpkgs": {
      "locked": {
        "lastModified": 1753749649,
        "narHash": "sha256-+jkEZxs7bfOKfBIk430K+tK9IvXlwzqQQnppC2ZKFj4=",
        "owner": "nixos",
        "repo": "nixpkgs",
        "rev": "1f08a4df998e21f4e8be8fb6fbf61d11a1a5076a",
        "type": "github"
      },
      "original": {
        "owner": "nixos",
        "ref": "nixos-25.05",
        "repo": "nixpkgs",
        "type": "github"
      }
    },

# docker.nix
{ config, lib, pkgs, ... }:
{
  config.virtualisation.docker = {
    enable = true;
    
  };
}

> docker info
Client:
 Version:    27.5.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.23.0
    Path:     /nix/store/n1xyy00gjxy4vlmjgfcj64kngz1jz9n4-docker-plugins/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  2.36.0
    Path:     /nix/store/n1xyy00gjxy4vlmjgfcj64kngz1jz9n4-docker-plugins/libexec/docker/cli-plugins/docker-compose

Server:
...
 Server Version: 27.5.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: journald
 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: runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: refs/tags/v2.1.3
 runc version: 
 init version: 
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.12.37
 Operating System: NixOS 25.05 (Warbler)
 OSType: linux
 Architecture: x86_64
...
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
...

Although, it looks like I’m a major version behind. Any notable changed from git blame?

4

Thanks for the reply! I have the same hash for my stable nixpkgs input and tried seeing if commenting out the rootless section in my config would maybe do something (didn’t think it would, but I’m trying anything). Still getting the error:

> docker compose version
docker: 'compose' is not a docker command.
See 'docker --help'

> docker buildx version
docker: 'buildx' is not a docker command.
See 'docker --help'

Some of my current outputs/config to compare:

"nixpkgs-stable": {
      "locked": {
        "lastModified": 1753749649,
        "narHash": "sha256-+jkEZxs7bfOKfBIk430K+tK9IvXlwzqQQnppC2ZKFj4=",
        "owner": "nixos",
        "repo": "nixpkgs",
        "rev": "1f08a4df998e21f4e8be8fb6fbf61d11a1a5076a",
        "type": "github"
      },
      "original": {
        "owner": "nixos",
        "ref": "nixos-25.05",
        "repo": "nixpkgs",
        "type": "github"
      }
    },

virtualisation.docker = {
    enable = true;
    # rootless = {
    #   enable = false;
    #   setSocketVariable = false;
    # };
  };

Client:
 Version:    27.5.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.23.0
    Path:     /nix/store/n1xyy00gjxy4vlmjgfcj64kngz1jz9n4-docker-plugins/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  2.36.0
    Path:     /nix/store/n1xyy00gjxy4vlmjgfcj64kngz1jz9n4-docker-plugins/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 3
 Server Version: 27.5.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: journald
 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: refs/tags/v2.1.3
 runc version: 
 init version: 
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.12.40
 Operating System: NixOS 25.11 (Xantusia)
 OSType: linux
 Architecture: x86_64
---
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

I suppose the most notable difference I can see is my kernel version and NixOS version. I don’t think I saw anything too standout from the git blame, although interpreting it is not my best. I don’t think some other program or config would’ve caused the issue, but I could be wrong.

5

Another guess, but could it be something about your home user config? Try creating a new blank user, adding it to the docker user group, then logging into it via clean tty. May also want to reboot just to guarantee the docker damon and systemd service have rolled over to the latest generation. Although, you’re CLI issues seem more docker client related.

6

There are three aspects I can comment on for the symptoms you describe:

  1. Rootless docker on NixOS would be lovely, but it has so many rough edges still that it’s just painful to use. Especially networking issues are what you’re likely to be facing a lot.
  2. You haven’t mentioned anything about adding your user to the docker group. Unless you’re happy to run all docker commands with sudo – with all its implications regarding ownership – you might want to consider this tradeoff.
  3. The missing docker buildx is a result of buildx having to be installed as a separate package. My relevant configuration for Docker looks like this:
  virtualisation.docker = {
    enable = true;
    extraPackages = [ pkgs.docker-buildx ];
  };
  users.users.peter.extraGroups = [ "docker" "networkmanager" "wheel" ];

The docker buildx command is then available. Interestingly, when I run docker compose build I still get the following warning, despite apparently parallel builds being executed:

WARN[0000] Docker Compose is configured to build using Bake, but buildx isn't installed

I can also run bake, which reads the compose file for its builds as hinted on:

$ docker buildx bake
 => [internal] load local bake definitions
 => => reading docker-compose.yaml 5.26kB / 5.26kB
...

Not cool yet

I have to add that the Docker experience is still not en par with other mainstream distros, such as Ubuntu, and macOS. Mostly the network settings (firewalling) are too restrictive for software development.

Safety is fine, but when a compose setup suggested by the official Docker documentation works everywhere but on NixOS – where internal traffic is partly blocked – there’s probably some conceptual misunderstanding of what the “Docker promise” is about. We should be able to take a uniform behavior for granted across operating systems and distros.

Yes, I’m on unstable, too.

$ nixos-version
25.11.20250728.dc96378 (Xantusia)
3 Likes
7

If I’m parsing the default nix file correctly, isn’t the buildx and compose plugin supported by default?

8

Yeah, I think I initially tried to use rootless Docker, but faced a number of issues that I kinda put a hold on that. I also tried installing the separate packages, but that didn’t make a difference.

I was doubly sure my user was in the docker group, and I verified again that the issue occurred even when that was set properly (and I restarted). What was confusing me was that other Docker commands like docker ps were working just fine without sudo.

users = {
    users = {
      ${user.username} = {
        description = user.name;
        isNormalUser = true;
        shell = pkgs.zsh;

        extraGroups = [
          "wheel"
          "networkmanager"
          "docker"
          "libvirtd"
          "openrazer"
          "wireshark"
        ];
      };
    };
  };

> groups
users wheel networkmanager libvirtd docker wireshark openrazer

However, @ruffsl 's suggestion to make a blank user gave me the idea to see what would happen if I did sudo docker compose version and sudo docker buildx version, and sure enough, it works when done like that.

For now, I have found that this symlink workaround works for me. It’s obviously not the prettiest fix, though.

mkdir -p ~/.docker/cli-plugins

ln -sf /nix/store/ypndr8cz6f3v90m5m380nwisrwgwf063-docker-plugins/libexec/docker/cli-plugins/docker-compose ~/.docker/cli-plugins/docker-compose
ln -sf /nix/store/ypndr8cz6f3v90m5m380nwisrwgwf063-docker-plugins/libexec/docker/cli-plugins/docker-buildx ~/.docker/cli-plugins/docker-buildx

After that, docker compose and docker buildx are now working as I expected and without sudo. (I also switched back to the unstable version for now, and it continues to work.)

I appreciate the segment on Docker and NixOS. I’ll keep that in mind. I don’t think my Docker use cases are that complex (yet), and I have a macOS machine if anything. If others aren’t having my same issue despite the same Docker configuration, then maybe something else in my configuration might be the culprit (here if interested). I don’t currently have a clue as to what might be a suspicious area, though.

1 Like
9

That’s a good question. I can see docker-buildx goes as a package name into the buildInputs, so it might be installed?

I suspect the warning being displayed (as mentioned above) means that the plugin isn’t installed correctly. Then again, the extraPackages option description says:

Extra packages to add to PATH for the docker daemon process.

Maybe that’s the clue. The plugin may not be on the PATH for the daemon by default. :person_shrugging: