Question posted in
The official documentation can be found here.

Docker Compose up causes "Conflict. The container name is already in use by container"?

I found a lot of questions about this error, but none of them were specifically about using docker compose up. I updated Docker Compose to v2.21.0 recently, so it’s probably the cause.

I’d run docker compose up multiple times and everything works as expected, but occasionally it’ll throw:

Error response from daemon: Conflict. The container name "/e752d663bd1a_foo" is already in use by container "e672c49f717291b19dbad4a25a372f96b6af5c7cbe70d50d5f169adf09dcb495".
You have to remove (or rename) that container to be able to reuse that name.

I didn’t change the Docker Compose config or start any new containers, etc. Docker should be able to identify that the container was started by Docker Compose previously, so it can reuse that container. However, I think Docker thinks the container isn’t part of the Docker Compose config?

Here’s the relevant part of my config:

  foo:
    image: server
    container_name: foo
    depends_on:
      - broker
      - schema-registry
      - connect
      - redis
    restart: always
    user: root
    environment:
      - SERVER=production
      - NODE_ENV=production
    command:
      - node
      - '--experimental-specifier-resolution=node'
      - '--no-warnings'
      - build/production/server-script/foo.js
    volumes:
      - ./env:/usr/src/env
      - ./.env:/usr/src/.env
      - /var/run/docker.sock:/var/run/docker.sock
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 2G

And the command I’m using:

node ./docker-compose.js | docker compose -f - -p foo --compatibility up -d --remove-orphans

Oddly, it’s always the same "foo" container that’s causing the error, even though there are ~10 containers in the config.

Tags:

2

Answers


  1. 0

    The error message shows a container name that does not match the usual naming pattern of Docker Compose or the container_name you have specified. That could indicate an external process or script affecting container management, leading to naming conflicts.

    As per BMitch‘s advice, the first test is to remove the container_name: foo line from your Docker Compose configuration. Let Docker Compose handle naming to avoid conflicts, especially during rapid start/stop cycles.

    services:
  foo:
    image: server
    # Removed container_name: foo
    depends_on:
    ...

    Instead of relying on fixed container names for inter-container communication, use Docker’s internal DNS service. Each service in a Docker Compose file is reachable by other services using the service name as a hostname.
    See "Networking in Compose (V2)"

    Given this, when you remove the container_name directive from your Docker Compose configuration, you should rely on this internal DNS service for inter-container communication. That means any references to specific container names within your application (if any) should be replaced with the service names defined in your Docker Compose file.

    For instance, if other services in your Docker Compose setup need to connect to the foo service, they can simply use foo as the hostname, rather than a hardcoded container name.

    Login or Signup to reply.
  2. 0

    If you absolutely need the container_name directives (Immich is an example), you can first remove the container_name directives from the docker-compose file, do an docker-compose up, then add them back and do another docker-compose up.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search