How to fix Error response from daemon: node is not available in Docker

DockerINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 189 views

This error occurs when Docker Swarm cannot schedule tasks on a node because it is set to 'drain' or 'pause' availability, or the node has gone offline. The fix involves checking node status, updating availability settings, or rejoining the node to the swarm.

Quick fix

Fixes Error response from daemon: node is not available

docker node ls
  1. Check node availability status
  2. Set the node back to active availability
  3. Check if the node is connected to the swarm
  4. Rejoin a node to the swarm
docker — error
docker node ls
Error response from daemon: node is not available

What this error means

The "node is not available" error in Docker Swarm indicates that the swarm manager cannot assign tasks to a particular node. This happens when a node's availability state prevents it from receiving new workloads. In Docker Swarm, every node has an availability setting that determines whether it can accept tasks: - **Active**: The node can receive and run tasks (default state when joining) - **Pause**: The node cannot receive new tasks, but existing tasks continue running - **Drain**: The scheduler stops all existing tasks and moves them to other active nodes; no new tasks are assigned This error commonly appears when you try to deploy a service with placement constraints targeting a node that is drained or paused, when a node has gone offline due to network issues, or when a manager node has been drained to dedicate it to management tasks only.

Typical symptoms

  • Service deployment fails with 'node is not available' error
  • docker service ps shows tasks in 'pending' state
  • docker node ls shows node with 'Drain' or 'Pause' availability
  • Tasks fail to schedule on specific nodes despite resources being available
  • Placement constraints cannot be satisfied
  • Services show 'no suitable node' errors in combination with this error

Common causes

  1. Node availability is set to 'drain' (most common)
  2. Node availability is set to 'pause'
  3. Node has disconnected from the swarm (showing 'Down' status)
  4. Network connectivity issues between manager and worker nodes
  5. Placement constraints targeting an unavailable node
  6. Manager node was drained to prevent task scheduling on managers
  7. Node was removed from the swarm but tasks still reference it
  8. Firewall blocking swarm communication ports (2377, 7946, 4789)

How to fix "Error response from daemon: node is not available"

1Check node availability status

First, inspect the current state of all nodes in your swarm:

bash
docker node ls

This shows the availability of each node. Look for nodes with "Drain" or "Pause" in the AVAILABILITY column:

bash
ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS
abc123def456...   manager1   Ready     Active         Leader
xyz789ghi012...   worker1    Ready     Drain

To get detailed information about a specific node:

bash
docker node inspect <node_name> --pretty

Check the "Availability" field in the output.

2Set the node back to active availability

If the node shows "Drain" or "Pause" status and you want it to accept tasks, update its availability:

bash
docker node update --availability active <node_name>

For example:

bash
docker node update --availability active worker1

Verify the change:

bash
docker node ls

The node should now show "Active" in the AVAILABILITY column. Existing services will automatically reschedule tasks to this node if needed.

3Check if the node is connected to the swarm

If the node shows "Down" status instead of "Ready", it has lost connection to the swarm:

bash
docker node ls

Look for:

bash
ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS
xyz789ghi012...   worker1    Down      Active

On the disconnected node, check if Docker is running:

bash
sudo systemctl status docker

If Docker is stopped, start it:

bash
sudo systemctl start docker

Check swarm membership on the node:

bash
docker info | grep -A 5 "Swarm"

If the node thinks it's not in a swarm, you may need to rejoin it.

4Rejoin a node to the swarm

If a node has been disconnected or removed, rejoin it to the swarm.

On a manager node, get the join token:

bash
# For worker nodes
docker swarm join-token worker

# For manager nodes
docker swarm join-token manager

This outputs a command like:

bash
docker swarm join --token SWMTKN-1-abc123... 192.168.1.100:2377

On the node to rejoin, first leave any existing swarm:

bash
docker swarm leave --force

Then run the join command provided by the manager:

bash
docker swarm join --token SWMTKN-1-abc123... 192.168.1.100:2377

On the manager, remove the old node entry if it persists:

bash
docker node rm <old_node_id>
5Check and fix network connectivity

Docker Swarm requires specific ports to be open between nodes:

- TCP 2377: Cluster management communications
- TCP/UDP 7946: Communication among nodes (gossip protocol)
- UDP 4789: Overlay network traffic (VXLAN)

Test connectivity from a worker to the manager:

bash
nc -zv <manager_ip> 2377
nc -zv <manager_ip> 7946
nc -zuv <manager_ip> 4789

If using UFW (Ubuntu firewall):

bash
sudo ufw allow 2377/tcp
sudo ufw allow 7946/tcp
sudo ufw allow 7946/udp
sudo ufw allow 4789/udp
sudo ufw reload

If using firewalld (RHEL/CentOS):

bash
sudo firewall-cmd --permanent --add-port=2377/tcp
sudo firewall-cmd --permanent --add-port=7946/tcp
sudo firewall-cmd --permanent --add-port=7946/udp
sudo firewall-cmd --permanent --add-port=4789/udp
sudo firewall-cmd --reload

Check for HTTP proxy interference: If you have an HTTP proxy configured, it may intercept swarm traffic. Ensure Docker traffic bypasses the proxy.

6Review and fix placement constraints

If you're using placement constraints in your service definition, ensure they target available nodes.

Check existing service constraints:

bash
docker service inspect <service_name> --pretty | grep -A 10 "Placement"

Common constraint issues:

1. Targeting a drained node by name:

yaml
# This fails if worker1 is drained
deploy:
  placement:
    constraints:
      - node.hostname == worker1

2. Using labels that don't exist on active nodes:

yaml
deploy:
  placement:
    constraints:
      - node.labels.region == us-west

Add labels to nodes:

bash
docker node update --label-add region=us-west worker1

Verify node labels:

bash
docker node inspect worker1 --format '{{ .Spec.Labels }}'

Update service to remove or modify constraints:

bash
docker service update --constraint-rm 'node.hostname == worker1' <service_name>
7Remove stale node references

If a node was removed but tasks still reference it, clean up the stale entries.

List all nodes including down ones:

bash
docker node ls

Remove nodes that are no longer part of the cluster:

bash
docker node rm <node_id>

If the node is still showing tasks:

bash
docker node rm --force <node_id>

Check for orphaned tasks:

bash
docker service ps <service_name> --filter "desired-state=running"

If tasks are stuck referencing a removed node, force a service update:

bash
docker service update --force <service_name>

This reschedules all tasks, placing them on available nodes.

Advanced notes

Understanding node availability states:
- Active: Default state. The node participates fully in the swarm and can receive task assignments.
- Pause: The node remains in the swarm and existing tasks keep running, but no new tasks are assigned. Useful for troubleshooting without disrupting current workloads.
- Drain: The scheduler evacuates all tasks from the node and prevents new assignments. Use this for maintenance or to dedicate manager nodes to management only.

Best practice for manager nodes: In production swarms, drain your manager nodes so they focus solely on cluster management:

bash
docker node update --availability drain <manager_node>

Handling node failures gracefully: Configure appropriate restart policies and replica counts so the swarm can recover when nodes fail:

yaml
deploy:
  replicas: 3
  restart_policy:
    condition: on-failure
    delay: 5s
    max_attempts: 3

Monitoring node health: Set up monitoring to alert when nodes go down:

bash
# Simple check script
docker node ls --format "{{.Hostname}}: {{.Status}}" | grep -v "Ready"

Soft constraints (workaround): Docker Swarm doesn't support "preferred" placement (like Kubernetes nodeAffinity). If a node is unavailable, services with hard constraints will fail. Consider using labels on multiple nodes to provide fallback options:

bash
# Label multiple nodes with the same role
docker node update --label-add role=database worker1 worker2 worker3

Recovering from split-brain scenarios: If network partitions cause managers to disagree on cluster state, you may need to reinitialize the swarm. As a last resort:

bash
docker swarm init --force-new-cluster

This recovers from a loss of quorum using the current manager's state. Use with caution.

Task history and stale references: Docker keeps a history of tasks (default: 5). If you see "node not found" errors in logs, these may relate to old task entries. Reduce history to minimize noise:

bash
docker swarm update --task-history-limit 3

Frequently asked questions

What does "Error response from daemon: node is not available" mean?
The "node is not available" error in Docker Swarm indicates that the swarm manager cannot assign tasks to a particular node. This happens when a node's availability state prevents it from receiving new workloads. In Docker Swarm, every node has an availability setting that determines whether it can accept tasks: - Active: The node can receive and run tasks (default state when joining) - Pause: The node cannot receive new tasks, but existing tasks continue running - Drain: The scheduler stops all existing tasks and moves them to other active nodes; no new tasks are assigned This error commonly appears when you try to deploy a service with placement constraints targeting a node that is drained or paused, when a node has gone offline due to network issues, or when a manager node has been drained to dedicate it to management tasks only.
How do I fix "Error response from daemon: node is not available"?
This error occurs when Docker Swarm cannot schedule tasks on a node because it is set to 'drain' or 'pause' availability, or the node has gone offline. The fix involves checking node status, updating availability settings, or rejoining the node to the swarm.
What causes "Error response from daemon: node is not available"?
Node availability is set to 'drain' (most common) Node availability is set to 'pause' Node has disconnected from the swarm (showing 'Down' status)
Is the "Error response from daemon: node is not available" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading