How to fix Error response from daemon: removal of container is already in progress in Docker

DockerBEGINNERLOWUpdated Dec 6, 2025· 276 views

The 'removal of container is already in progress' error occurs when Docker is already attempting to delete a container and you try to remove it again. Wait for the operation to complete, or restart Docker if the container is stuck in a zombie state.

Quick fix

Fixes Error response from daemon: removal of container is already in progress

# Wait a moment for the removal to complete
sleep 5

# Check if the container still exists
docker ps -a --filter "name=mycontainer"

# If still there, try removing again
docker rm mycontainer
  1. Wait and retry the operation
  2. Check container status
  3. Force remove the container
  4. Restart the Docker daemon
docker — error
# Wait a moment for the removal to complete
sleep 5
# Check if the container still exists
docker ps -a --filter "name=mycontainer"
# If still there, try removing again
docker rm mycontainer
Error response from daemon: removal of container is already in progress

What this error means

The "removal of container is already in progress" error in Docker indicates that the Docker daemon has already begun the process of removing a container, and you've issued another command that attempts to delete or interact with the same container. This typically occurs due to a race condition in Docker's container lifecycle management. When you stop a container started with the `--rm` flag, Docker automatically queues the container for removal. If your script or another process simultaneously tries to remove the same container, Docker returns this conflict error because it cannot process multiple removal operations on the same container. The error is particularly common in CI/CD environments (like GitHub Actions with Docker-in-Docker), automated scripts that manage containers, and when using `docker-compose` where multiple services are being torn down simultaneously. In most cases, the container will be successfully removed shortly—you just need to wait or handle the race condition in your automation.

Typical symptoms

  • Docker rm command fails with 'removal of container is already in progress'
  • docker-compose down fails partway through teardown
  • CI/CD pipeline fails when cleaning up containers
  • Container shows 'Removal In Progress' status in docker ps -a
  • Container stuck in removal state for extended periods (zombie container)
  • Scripts that stop and remove containers fail intermittently
  • Race condition errors when using --rm flag with docker stop
  • GitHub Actions with Docker-in-Docker fails with conflicting lifecycle events

Common causes

  1. Race condition: container started with --rm flag and docker stop/rm called simultaneously
  2. Multiple processes or scripts trying to remove the same container at once
  3. docker-compose down running while container auto-removal is in progress
  4. Previous removal operation failed partway through, leaving container in zombie state
  5. Filesystem issue: device or resource busy preventing container layer deletion
  6. Container volumes are still being used by another process
  7. Filename too long in container filesystem causing lstat errors during cleanup
  8. NTP/time sync daemon (ntpd/chronyd) holding references to container filesystem

How to fix "Error response from daemon: removal of container is already in progress"

1Wait and retry the operation

In most cases, the container removal is legitimately in progress and will complete shortly. Simply wait a few seconds and try again:

bash
# Wait a moment for the removal to complete
sleep 5

# Check if the container still exists
docker ps -a --filter "name=mycontainer"

# If still there, try removing again
docker rm mycontainer

For scripts, add retry logic with a delay:

bash
# Retry removal with backoff
for i in 1 2 3 4 5; do
    docker rm mycontainer 2>/dev/null && break
    echo "Attempt $i failed, waiting..."
    sleep $((i * 2))
done
2Check container status

Examine the container's current state to understand what's happening:

bash
# List all containers including those being removed
docker ps -a

# Check container details
docker inspect mycontainer

# Look for 'Status' and 'State' in the output
docker inspect --format='{{.State.Status}}' mycontainer

If the status shows "removing" or "removal in progress", the daemon is actively working on it. If it's been stuck for a long time, proceed to the next steps.

3Force remove the container

Try force-removing the container to override the in-progress state:

bash
# Force remove by name
docker rm -f mycontainer

# Force remove by container ID
docker rm -f abc123def456

# If that fails, try stopping first then removing
docker stop mycontainer && docker rm mycontainer

The -f flag sends a SIGKILL signal and forces removal, which can break through some stuck states.

4Restart the Docker daemon

If the container is stuck in a zombie state, restarting Docker often resolves it:

bash
# Linux with systemd
sudo systemctl restart docker

# Or using service command
sudo service docker restart

# macOS/Windows Docker Desktop
# Use the Docker Desktop UI to restart, or:
# macOS: killall Docker && open /Applications/Docker.app
# Windows: Restart-Service docker (PowerShell as Admin)

After restarting, the stuck container should either complete removal or become removable:

bash
# Check status after restart
docker ps -a

# Try removing again
docker rm mycontainer
5Check for processes using container resources

If you get "device or resource busy" errors, identify what's holding the container:

bash
# Find what's using the container's overlay filesystem
sudo lsof +D /var/lib/docker/overlay2/

# Or check for processes using container directories
sudo fuser -v /var/lib/docker/containers/<CONTAINER_ID>/

# Look for processes that might be accessing mounted volumes
ps aux | grep -i docker

Common culprits include:
- nginx or other servers with open file handles
- Log collection agents reading container logs
- Monitoring tools inspecting container filesystems

Stop these processes, then retry removal.

6Manually remove container files (last resort)

For persistent zombie containers when all else fails, manually remove the container directory:

bash
# WARNING: This is a last resort - can cause data loss
# Stop Docker first
sudo systemctl stop docker

# Remove the container directory
sudo rm -rf /var/lib/docker/containers/<CONTAINER_ID>

# Start Docker
sudo systemctl start docker

# Verify container is gone
docker ps -a

Important: Only do this if:
- The container is truly stuck and other methods failed
- You don't need any data from the container
- You've stopped Docker before removing files

7Handle race conditions in scripts

To prevent this error in automation, handle the race condition gracefully:

bash
# Check container state before removal
container_state=$(docker inspect --format='{{.State.Status}}' mycontainer 2>/dev/null)

case "$container_state" in
    "running")
        docker stop mycontainer
        docker rm mycontainer
        ;;
    "exited"|"created"|"dead")
        docker rm mycontainer
        ;;
    "removing")
        echo "Container removal already in progress, waiting..."
        while docker ps -a --format '{{.Names}}' | grep -q "^mycontainer$"; do
            sleep 1
        done
        ;;
    *)
        echo "Container does not exist or unknown state"
        ;;
esac

For docker-compose, use error handling:

bash
# Ignore removal-in-progress errors during down
docker-compose down 2>&1 | grep -v "removal of container.*already in progress" || true
8Clean up orphan containers in docker-compose

When using docker-compose, properly clean up to avoid conflicts:

bash
# Remove orphan containers from changed compose files
docker-compose down --remove-orphans

# Force removal of volumes too
docker-compose down -v --remove-orphans

# Clean up all stopped containers
docker container prune -f

# Nuclear option: remove all containers for this compose project
docker-compose rm -f -s -v

The --remove-orphans flag is especially important when you've renamed or removed services from your compose file.

Advanced notes

### Understanding the Race Condition

The removal-in-progress error is fundamentally a race condition in Docker's container lifecycle. When you use docker run --rm, Docker schedules container removal immediately after the container stops. If your script then calls docker rm or docker-compose down, both operations race to remove the same container.

The Docker Engine API returns HTTP 400 with "removal of container name is already in progress" when it detects this conflict. This behavior was documented in the API to prevent undefined behavior from concurrent removals.

### CI/CD Best Practices

In GitHub Actions and other CI environments, this error is common due to the asynchronous nature of container management:

yaml
# GitHub Actions example with proper cleanup
- name: Stop containers
  run: |
    docker stop mycontainer || true
    # Wait for --rm to finish if applicable
    sleep 2
    docker rm mycontainer 2>/dev/null || true

Consider using docker wait instead of docker stop when you need to ensure the container has fully exited:

bash
# Wait for container to exit (blocks until stopped)
docker wait mycontainer
# Container is now fully stopped, safe to remove
docker rm mycontainer

### Zombie Container Recovery

Containers can become zombies (stuck in "Removal In Progress" indefinitely) due to:

1. Filesystem issues: Long filenames in the container can cause lstat to fail during cleanup
2. Time sync daemons: ntpd or chronyd can hold file descriptors in container filesystems
3. Storage driver bugs: Issues with overlay2 or devicemapper can prevent layer removal

For filesystem issues, you may need to manually clean up the problematic files:

bash
# Find files with extremely long names
sudo find /var/lib/docker/containers/<ID> -name "*" -print 2>&1 | grep "File name too long"

# Remove the container directory after stopping Docker
sudo systemctl stop docker
sudo rm -rf /var/lib/docker/containers/<ID>
sudo systemctl start docker

### Docker Compose Pull Request #10136

The Docker Compose team addressed this issue by modifying how Compose handles orphan containers. Compose now ignores "conflict" errors (HTTP 409) when a removal is already in progress, treating it the same as "not found"—since the end result (container gone) is the same.

If you're on an older version of Docker Compose, upgrade to get this fix:

bash
# Check compose version
docker-compose version

# Update Docker Compose (Linux)
sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

### Alternative: Use Container Labels for Cleanup

Instead of relying on container names, use labels for more robust cleanup:

bash
# Create container with labels
docker run -d --label app=myapp --label env=test myimage

# Remove all containers matching labels (regardless of state)
docker rm -f $(docker ps -aq --filter "label=app=myapp")

This approach avoids name conflicts entirely and allows for more flexible container management.

Frequently asked questions

What does "Error response from daemon: removal of container is already in progres" mean?
The "removal of container is already in progress" error in Docker indicates that the Docker daemon has already begun the process of removing a container, and you've issued another command that attempts to delete or interact with the same container. This typically occurs due to a race condition in Docker's container lifecycle management. When you stop a container started with the --rm flag, Docker automatically queues the container for removal.
How do I fix "Error response from daemon: removal of container is already in progres"?
The 'removal of container is already in progress' error occurs when Docker is already attempting to delete a container and you try to remove it again. Wait for the operation to complete, or restart Docker if the container is stuck in a zombie state.
What causes "Error response from daemon: removal of container is already in progres"?
Race condition: container started with --rm flag and docker stop/rm called simultaneously Multiple processes or scripts trying to remove the same container at once docker-compose down running while container auto-removal is in progress
Is the "Error response from daemon: removal of container is already in progres" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading