How to fix Error response from daemon: a prune operation is already running in Docker

DockerBEGINNERLOWUpdated Dec 6, 2025· 189 views

This error occurs when Docker detects an existing prune operation lock, often caused by interrupted SSH sessions, unresponsive containers, or containerd communication failures.

Quick fix

Fixes Error response from daemon: a prune operation is already running

docker system info
  1. Check if a prune operation is actually running
  2. Restart the Docker daemon
  3. Identify and remove unresponsive containers
  4. Force remove dangling images if needed
docker — error
docker system info
Error response from daemon: a prune operation is already running

What this error means

When you run `docker system prune` or any related prune command, Docker creates a lock to prevent multiple prune operations from running simultaneously. This safeguard ensures data integrity during cleanup operations. The error "a prune operation is already running" appears when Docker's daemon detects this lock is still active. However, in most cases, no actual prune operation is running. The lock typically persists due to: 1. **Interrupted operations**: If your SSH session disconnects mid-prune or the terminal closes unexpectedly, the lock may remain even though the operation stopped. 2. **Unresponsive containers**: A container that Docker cannot communicate with can cause the daemon to hang, leaving the lock in place. 3. **Containerd issues**: In some cases, the underlying container runtime (containerd) fails to respond to the Docker daemon, causing cleanup operations to stall indefinitely. This is a concurrency protection mechanism that has become stuck, not an indication of an actual ongoing operation.

Typical symptoms

  • Running docker system prune returns 'a prune operation is already running'
  • Docker commands related to cleanup (prune, rm) hang or fail
  • The error persists even after waiting several minutes
  • SSH session was disconnected while running prune
  • docker system info shows no decrease in image or container counts
  • Other Docker commands work normally but prune operations fail

Common causes

  1. SSH session disconnected or terminal closed during a prune operation
  2. A container became unresponsive and Docker cannot interact with it
  3. The containerd runtime is not responding to Docker daemon requests
  4. A previous prune operation was interrupted by system restart or kill signal
  5. Multiple automated scripts attempted to run prune simultaneously
  6. Containerd bug causing goroutines to wait indefinitely for responses

How to fix "Error response from daemon: a prune operation is already running"

1Check if a prune operation is actually running

Before taking action, verify whether a legitimate prune operation is in progress. Open a new terminal and run:

bash
docker system info

Watch the "Images" and "Containers" counts. If they are decreasing over time, a prune operation is genuinely running. Wait for it to complete.

If the counts remain static, the lock is stale and you can proceed with the following fixes.

2Restart the Docker daemon

The simplest and most reliable fix is restarting the Docker service, which clears the stale lock:

On Linux with systemd:

bash
sudo systemctl restart docker

On older Linux systems:

bash
sudo service docker restart

On macOS (Docker Desktop):
Click the Docker icon in the menu bar, then select "Restart Docker Desktop."

On Windows (Docker Desktop):
Right-click the Docker icon in the system tray and select "Restart."

After restarting, retry your prune command:

bash
docker system prune
3Identify and remove unresponsive containers

If restarting Docker is not an option (e.g., production environment), identify containers that may be causing the hang:

Test container responsiveness:

bash
docker ps -a

Try inspecting each container. An unresponsive container will cause this command to hang:

bash
docker inspect <container_id>

Find the stuck container process:

bash
ps aux | grep docker-containerd-shim

Kill the unresponsive container process:

bash
sudo kill -9 <PID>

Force remove the problematic container:

bash
docker rm -f <container_id>

After removing the unresponsive container, retry the prune operation.

4Force remove dangling images if needed

If the prune operation was stuck while removing images, you may need to force-remove them manually:

bash
docker rmi -f $(docker images -q --filter "dangling=true")

Or to remove all unused images:

bash
docker rmi -f $(docker images -aq)

Warning: This removes all images not currently used by running containers. Only use this if you are comfortable re-pulling required images.

5Prevent future issues with proper prune practices

To avoid this error in the future:

Use the force flag to skip confirmation prompts:

bash
docker system prune -f

Run prune in a screen or tmux session to survive SSH disconnections:

bash
screen -S docker-prune
docker system prune -a --volumes
# Detach with Ctrl+A, D

For CI/CD environments, use age filters to avoid conflicts:

bash
docker system prune -f --filter "until=24h"

This only removes resources older than 24 hours, reducing the chance of conflicts with active build operations.

Advanced notes

### Understanding Docker's Prune Lock Mechanism

Docker uses a mutex lock at the daemon level to prevent concurrent prune operations. This is essential because prune operations involve:
- Iterating through all containers, images, networks, and volumes
- Checking dependencies between resources
- Removing resources in the correct order

Running multiple prune operations simultaneously could lead to race conditions or data corruption.

### Containerd Integration Issues

The Docker daemon communicates with containerd (the container runtime) for low-level container operations. When containerd becomes unresponsive (documented in containerd issue #2078), the daemon's goroutines can wait indefinitely. This manifests as a stuck prune operation even though no actual cleanup is happening.

To check containerd health:

bash
sudo systemctl status containerd
sudo journalctl -u containerd -n 50

### Production Environment Considerations

In production, restarting Docker stops all running containers. If you cannot restart Docker:
1. Identify the specific unresponsive container causing the hang
2. Use kill -9 on its containerd-shim process
3. Force-remove the container with docker rm -f

This surgical approach minimizes disruption while clearing the lock.

### Debugging with Stack Traces

To get detailed debugging information, send SIGUSR1 to the Docker daemon:

bash
sudo kill -SIGUSR1 $(pidof dockerd)

Check the Docker logs for stack traces that reveal where the daemon is stuck:

bash
sudo journalctl -u docker -n 100

Frequently asked questions

What does "Error response from daemon: a prune operation is already running" mean?
When you run docker system prune or any related prune command, Docker creates a lock to prevent multiple prune operations from running simultaneously. This safeguard ensures data integrity during cleanup operations. The error "a prune operation is already running" appears when Docker's daemon detects this lock is still active.
How do I fix "Error response from daemon: a prune operation is already running"?
This error occurs when Docker detects an existing prune operation lock, often caused by interrupted SSH sessions, unresponsive containers, or containerd communication failures.
What causes "Error response from daemon: a prune operation is already running"?
SSH session disconnected or terminal closed during a prune operation A container became unresponsive and Docker cannot interact with it The containerd runtime is not responding to Docker daemon requests
Is the "Error response from daemon: a prune operation is already running" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading