Docker Compose: docker endpoint for "default" not found

Docker Desktop
, ,
1

Howdy!

I am on Windows Server 2019 using Docker Desktop 4.16.3 (96739).

In preparation for a side project I test built a Docker project consisting of a Go-base API server and Caddy. I created my files, my volume and ran docker compose up and was off to the races. Now it was time to do the same thing for the real project so I copied my working files, did a few tweaks, and repeated the process only to receive:

docker endpoint for "default" not found

I searched around for a solution, tried a few like deleting my .docker folder, even deleted every container, image and volume, but keep getting the same error. I can go back to my original project and rebuild it with no issue so Iā€™m at a loss especially since I donā€™t even understand what that message means :stuck_out_tongue:

Here is my Dockerfile:

FROM golang:1.19

WORKDIR /app

RUN go install github.com/cosmtrek/air@latest

COPY go.mod ./
RUN go mod download

CMD ["air", "-c", ".air.toml"]

Here is my docker-compose.yml:

version: "3.8"
services:
  go:
    build: ./
    ports:
      - "3000"
    volumes:
      - ./:/app
  caddy:
    image: caddy:latest
    restart: on-failure
    ports:
      - "2015:2015"
      - "2019:2019"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./public:/srv
      - caddy_data:/data
      - caddy_config:/config
volumes:
  caddy_data:
    external: true
  caddy_config:

Itā€™s important to note that if I remove the 6 lines related to go under services Docker will build and run Caddy with no issue. If I run docker build .\ I get no errors so I have to assume thereā€™s some disconnect in the go part of services.

Any help is greatly appreciated!
Chris

2

Docker Desktop is still not officially supported on Windows Server. so for me it is surprising that it starts at all

As for the endpoint, if you run

docker context ls

you will see the contexts and the endpoints.

3

I had the same issue and what I did was to remove ~/.docker/contexts. In my case it was a symlink from a previous installation. I was able to recreate the context using docker context create.

1 Like
4

Thanks for the advice. Turns out this GitHub issue has the solution:

The relevant fix from that thread for me was removing ~/.docker/contexts/meta/(some sha256)/meta.json and then I could compose away.