The 'docker exec' command fails because the target container has exited or stopped. This typically happens when containers exit immediately after starting due to missing long-running processes or when you attempt to execute commands in a stopped container.
This error occurs when you attempt to run a command inside a container using `docker exec`, but the target container is not in a running state. The full error message reads: "Error response from daemon: Container <container_id> is not running". The `docker exec` command is designed to execute commands inside containers that are actively running. Unlike virtual machines, Docker containers are ephemeral - they exist only while their main process (PID 1) is running. When that process completes or exits, the container stops. Common scenarios that lead to this error include: containers with shell entrypoints that exit immediately without an interactive terminal, containers whose main application crashed, or simply trying to exec into a container that was previously stopped with `docker stop`.
First, verify the container's current state to understand why it's not running:
docker ps -aLook for your container in the output. The STATUS column will show either:
- "Up X minutes" (running - this error shouldn't occur)
- "Exited (0)" (completed successfully)
- "Exited (1)" or other non-zero code (crashed or error)
- "Created" (never started)
Note the container ID or name for the next steps.
If the container has exited, restart it first:
docker start <container_name_or_id>Then immediately run your exec command:
docker exec -it <container_name_or_id> /bin/bashNote: If the container exits again immediately after starting, proceed to the next steps to diagnose why.
If the container keeps exiting, check its logs to understand why:
docker logs <container_name_or_id>Common issues you might find:
- Application crashes or exceptions
- Missing environment variables or configuration
- File not found errors
- Permission denied errors
The exit code also provides hints:
- Exit code 0: Process completed successfully (not an error, just finished)
- Exit code 1: General error
- Exit code 137: Killed by SIGKILL (often OOM killer)
- Exit code 139: Segmentation fault
For images designed around shells (like ubuntu, alpine, debian), you need to allocate a terminal to keep them running:
# Run with interactive terminal
docker run -it --name my_container <image_name> /bin/bash
# Or run detached with a pseudo-TTY to keep alive
docker run -d -t --name my_container <image_name>
# Now you can exec into it
docker exec -it my_container /bin/bashThe -t flag allocates a pseudo-TTY, and -i keeps STDIN open. Together they keep shell-based containers running.
If you need a container to stay running for debugging or testing, override the entrypoint with a long-running process:
# Run with tail -f to keep container alive
docker run -d --name my_container <image_name> tail -f /dev/null
# Or use sleep infinity
docker run -d --name my_container <image_name> sleep infinity
# Now exec works
docker exec -it my_container /bin/bashThis is useful when the original CMD/ENTRYPOINT exits too quickly for you to debug.
If you only need to inspect files in a stopped container (not run commands), you can commit and create a new container:
# Commit the stopped container to a new image
docker commit <stopped_container_id> debug-image
# Run a new container from that image with a shell
docker run -it debug-image /bin/bashAlternatively, copy files directly from the stopped container:
docker cp <stopped_container_id>:/path/to/file ./local_destinationUnderstanding container lifecycle: Docker containers are fundamentally different from virtual machines. A container runs exactly one process (the entrypoint/CMD), and when that process exits, the container stops. This is by design - containers are meant to be ephemeral and stateless.
Debugging crashed containers: If a container crashes before you can exec into it, use these techniques:
# Run interactively to see output in real-time
docker run -it <image_name>
# Override entrypoint to get a shell before the app runs
docker run -it --entrypoint /bin/bash <image_name>
# Inspect the container's configuration
docker inspect <container_id>Container restart policies: If you need containers to stay running, configure restart policies:
docker run -d --restart=unless-stopped <image_name>This won't help if the main process exits cleanly (code 0), but it will restart containers that crash.
Paused containers: Note that containers can also be in a "paused" state (different from stopped). If you see "Container is paused" instead, use:
docker unpause <container_name_or_id>Using docker run instead: For one-off commands in images where you don't need a persistent container, consider using docker run with --rm instead of creating a container and exec-ing into it:
docker run --rm -it <image_name> /bin/bashdockerfile parse error line 5: unknown instruction: RRUN
How to fix 'unknown instruction' Dockerfile parse error in Docker
Error response from daemon: manifest for nginx:nonexistent not found: manifest unknown: manifest unknown
How to fix 'manifest for image:tag not found' in Docker
Error response from daemon: invalid reference format: repository name must be lowercase
How to fix 'repository name must be lowercase' in Docker
Error response from daemon: No such image
How to fix 'No such image' in Docker
the input device is not a TTY
How to fix 'the input device is not a TTY' in Docker