How to fix Error response from daemon: This node is already part of a swarm in Docker

DockerBEGINNERLOWUpdated Dec 6, 2025· 185 views

This error occurs when you try to initialize or join a Docker Swarm on a node that is already a member of an existing swarm. The fix involves leaving the current swarm first before joining or creating a new one.

Quick fix

Fixes Error response from daemon: This node is already part of a swarm

docker info | grep -A 5 "Swarm"
  1. Check current swarm status
  2. Leave the current swarm (worker node)
  3. Leave the current swarm (manager node)
  4. Initialize or join a new swarm
docker — error
docker info | grep -A 5 "Swarm"
Error response from daemon: This node is already part of a swarm

What this error means

The "This node is already part of a swarm" error indicates that you're attempting to run `docker swarm init` or `docker swarm join` on a machine that is already participating in a Docker Swarm cluster. Docker only allows a node to be a member of one swarm at a time. This commonly happens when: - You previously initialized a swarm and forgot about it - Your machine was rebooted but retained its swarm membership state - You're trying to join a different swarm without leaving the current one - You accidentally ran `docker swarm init` on a machine that was already a worker or manager in a swarm Docker Swarm mode stores membership information locally on each node, which persists across Docker daemon restarts and system reboots. To join a different swarm or reinitialize, you must explicitly leave the current swarm first.

Typical symptoms

  • docker swarm init fails with 'This node is already part of a swarm'
  • docker swarm join fails when trying to add node to a different swarm
  • docker info shows Swarm: active when you expected Swarm: inactive
  • Unable to create a new swarm cluster on a machine that was previously part of another swarm
  • Swarm commands work but connect to an unexpected or old swarm cluster

Common causes

  1. Node was previously initialized as a swarm manager with docker swarm init
  2. Node previously joined a swarm as a worker and membership persists
  3. Docker daemon restart or system reboot preserved swarm membership state
  4. Attempting to join a second swarm without leaving the first one
  5. Swarm was initialized for testing and not properly cleaned up
  6. Docker Desktop retained swarm state from a previous session

How to fix "Error response from daemon: This node is already part of a swarm"

1Check current swarm status

First, verify that the node is indeed part of a swarm and understand its current role:

bash
docker info | grep -A 5 "Swarm"

This will show output like:

bash
Swarm: active
  NodeID: abc123xyz
  Is Manager: true
  ClusterID: def456uvw
  Managers: 1
  Nodes: 1

You can also check the node's role directly:

bash
docker node ls

If you're a manager, this shows all nodes in the swarm. If you see "Error response from daemon: This node is not a swarm manager", the node is a worker (not a manager).

2Leave the current swarm (worker node)

If the node is a worker (not a manager), you can simply leave the swarm:

bash
docker swarm leave

This gracefully removes the node from the swarm. The output will confirm:

bash
Node left the swarm.

After leaving, verify the swarm status:

bash
docker info | grep "Swarm"

Should now show:

bash
Swarm: inactive

You can now join a new swarm or initialize a fresh one.

3Leave the current swarm (manager node)

If the node is a manager, Docker requires the --force flag to leave:

bash
docker swarm leave --force

Warning: If this is the last manager in the swarm, the entire swarm state (services, networks, secrets) will be lost. Make sure you understand the implications before proceeding.

For a safer approach with multiple managers:
1. First demote the manager to a worker:

bash
# Run from another manager node
docker node demote <node-id>

2. Then leave normally:

bash
# Run from the demoted node
docker swarm leave

3. Remove the node from the swarm's node list (from a remaining manager):

bash
docker node rm <node-id>
4Initialize or join a new swarm

After leaving the previous swarm, you can now create a new one or join an existing one.

To initialize a new swarm:

bash
docker swarm init

Or specify an advertise address for multi-network hosts:

bash
docker swarm init --advertise-addr <IP-ADDRESS>

To join an existing swarm as a worker:

bash
docker swarm join --token <WORKER-TOKEN> <MANAGER-IP>:2377

Get the join token from a manager node:

bash
docker swarm join-token worker

To join as a manager:

bash
docker swarm join --token <MANAGER-TOKEN> <MANAGER-IP>:2377

Get the manager token from an existing manager:

bash
docker swarm join-token manager
5Recover a broken swarm with force-new-cluster

If you're trying to recover a swarm after losing quorum (majority of managers), use the --force-new-cluster flag:

bash
docker swarm init --force-new-cluster

This reinitializes the swarm on the current node while preserving existing services, networks, and other swarm objects. Use this when:
- Other manager nodes are permanently lost
- The swarm lost quorum and can't be recovered normally
- You need to rebuild the swarm from a single remaining manager

Important considerations:
- Run this only on a node that was previously a manager
- All other nodes will need to rejoin the swarm
- Worker nodes will be marked as "down" until they rejoin
- This is a recovery operation, not for routine use

Advanced notes

Docker Python SDK force_new_cluster: If you're using the Docker Python SDK (docker-py), you can use the force_new_cluster parameter:

python
import docker
client = docker.from_env()
client.swarm.init(force_new_cluster=True)

Swarm data location: Docker stores swarm state in /var/lib/docker/swarm/ on Linux. In extreme cases where docker swarm leave --force doesn't work, you can stop Docker, remove this directory, and restart Docker:

bash
sudo systemctl stop docker
sudo rm -rf /var/lib/docker/swarm
sudo systemctl start docker

Warning: This is a last resort and will cause data loss.

Docker Desktop considerations: On Docker Desktop (Mac/Windows), swarm state persists in the Docker Desktop VM. Restarting Docker Desktop or resetting to factory defaults will clear swarm state.

Kubernetes vs Swarm: If you're using Docker Desktop with Kubernetes enabled, be aware that Kubernetes and Swarm are separate orchestrators. Enabling Kubernetes doesn't affect swarm membership.

CI/CD environments: In CI/CD pipelines, always ensure you clean up swarm state between runs if you're testing swarm functionality:

bash
docker swarm leave --force 2>/dev/null || true

Frequently asked questions

What does "Error response from daemon: This node is already part of a swarm" mean?
The "This node is already part of a swarm" error indicates that you're attempting to run docker swarm init or docker swarm join on a machine that is already participating in a Docker Swarm cluster. Docker only allows a node to be a member of one swarm at a time. This commonly happens when: - You previously initialized a swarm and forgot about it - Your machine was rebooted but retained its swarm membership state - You're trying to join a different swarm without leaving the current one - You accidentally ran docker swarm init on a machine that was already a worker or manager in a swarm Docker Swarm mode stores membership information locally on each node, which persists across Docker daemon restarts and system reboots.
How do I fix "Error response from daemon: This node is already part of a swarm"?
This error occurs when you try to initialize or join a Docker Swarm on a node that is already a member of an existing swarm. The fix involves leaving the current swarm first before joining or creating a new one.
What causes "Error response from daemon: This node is already part of a swarm"?
Node was previously initialized as a swarm manager with docker swarm init Node previously joined a swarm as a worker and membership persists Docker daemon restart or system reboot preserved swarm membership state
Is the "Error response from daemon: This node is already part of a swarm" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading