How to fix 'Error response from daemon: network with name … already exists'

Overview

This guide shows practical ways to resolve Docker’s "Error response from daemon: network with name … already exists". You’ll quickly identify the existing network, decide whether to reuse it, remove it safely, or avoid name collisions in Docker Compose and Swarm.

Quickstart (30 seconds)

• List networks and confirm the conflicting name:
  • bash: docker network ls | grep <name>
• Inspect who uses it:
  • bash: docker network inspect <name>
• Fix by one of:
  • Reuse existing network (Compose/Stack: mark it external).
  • Remove it (only if unused): docker network rm <name> or docker network prune.
  • Avoid collision: rename your network or change Compose project name.

Minimal working example (reproduce and fix)

# Reproduce the error
docker network create app-net
# Attempt to create with the same name
docker network create app-net
# Error: Error response from daemon: network with name app-net already exists

# Fix 1: remove and recreate (only if nothing uses it)
docker network rm app-net
docker network create app-net

If the network is in use:

# Simulate a container attached to the network
docker network create app-net || true
docker run -d --name demo --network app-net busybox sleep 3600

# Removing will fail because it's in use
# docker network rm app-net  # returns error

# Detach or remove the container, then remove the network
docker network disconnect app-net demo || docker rm -f demo
docker network rm app-net

Diagnose the conflict

1. List networks and find the exact name and ID:
   • bash: docker network ls
2. Inspect the network to see attached containers and driver:
   • bash: docker network inspect <network-name>
3. If using Docker Compose/Swarm, also check what wants to create the same name.

Key fields in inspect:

• Name, Id, Driver (bridge, overlay, macvlan, etc.)
• Containers map (who is attached)
• Labels (often identify Compose/Stack owners)

Common scenarios and fixes

Docker Compose: avoiding name clashes

Compose creates networks per project. By default, it names them <project>_<network>. If you force a fixed name via name:, Compose will try to create that exact network and fail if it exists unless marked external.

Minimal Compose example and fixes:

# docker-compose.yml
services:
  web:
    image: nginx:alpine
    networks:
      - appnet

networks:
  appnet:
    # Option A: let Compose manage (`<project>_appnet`) to avoid global collisions
    # no 'name' field here

Using a fixed global name safely:

# docker-compose.yml
services:
  web:
    image: nginx:alpine
    networks:
      - appnet

networks:
  appnet:
    external: true   # Tell Compose to reuse an existing network
    name: app-net    # Must exist already: docker network create app-net

Make project names unique:

# Use a stable, unique project name to avoid collisions
COMPOSE_PROJECT_NAME=myapp-prod docker compose up -d
# or
docker compose --project-name myapp-prod up -d

Clean up Compose-created networks:

docker compose down -v   # removes services, networks, and named volumes it created

Docker Swarm/Stacks: overlay networks

For Swarm, overlays are global. Name collisions happen if multiple stacks use the same overlay name without external.

• Prefer stack-scoped network names (default: <stack>_<network>).
• If you need a shared overlay, create once and mark as external.

Example:

# Create a shared overlay once
docker network create -d overlay --attachable shared-net

# stack.yml
services:
  api:
    image: nginx:alpine
    networks: [shared]

networks:
  shared:
    external: true
    name: shared-net

Deploy and clean up:

docker stack deploy -c stack.yml app
# ... later
docker stack rm app
# If an overlay lingers and is unused:
docker network rm shared-net

Safe removal and pruning

• Remove a specific unused network:
  • bash: docker network rm <name-or-id>
• Prune all unused networks:
  • bash: docker network prune (add -f to skip prompt)
• You cannot remove default networks (bridge, host, none).

If removal fails with "network has active endpoints":

# Find attached containers
docker network inspect <name> --format '{{json .Containers}}' | jq .
# Detach or remove them, then retry

Best practices to prevent future collisions

• Let Compose/Stacks manage network names; avoid hardcoded global names unless necessary.
• If sharing a network across projects, create it once and mark as external.
• Use unique Compose project names per environment.
• Prefer descriptive, environment-scoped names (e.g., prod-app-net).

Performance notes

• docker network ls/inspect/rm are lightweight operations; they do not pull images or scan layers.
• docker network prune only deletes unused networks; it’s fast and safe compared to docker system prune.
• Removing an in-use network is blocked until containers detach; plan detaches to avoid downtime.
• Removing overlay networks triggers cluster gossip updates; in large Swarm clusters, do this during low traffic.

Pitfalls

• Different drivers, same name: names are global regardless of driver; you still get a collision.
• Compose with name: but without external: true will try to create and fail if it already exists.
• Changing directories changes the Compose project name and may create additional networks you didn’t expect.
• Network labels often indicate owners; check labels before deleting shared networks.

FAQ

• How do I see what’s using the network?
  • docker network inspect <name> and check the Containers section.
• Can I force-remove a network in use?
  • No. Detach containers (docker network disconnect) or remove them first.
• Will pruning remove default networks or break running containers?
  • No. Prune removes only unused networks.
• How do I avoid collisions in CI?
  • Use unique project names (e.g., include build ID) or ephemeral network names.