You’ve spun up a Docker container. It’s running, but it’s not behaving correctly. Maybe the application is throwing 500 errors, or maybe it’s just silently failing to connect to the database.

You check docker logs, but the output is cryptic—or worse, empty. You feel locked out.

Docker containers are designed to be “sealed boxes.” This isolation is great for stability and security, but it’s a nightmare for debugging when you need to poke around the filesystem to see what’s actually happening.

You don’t need to rebuild the image or add complex logging just to see what’s wrong. You just need to open a side door.

That side door is docker exec.

In this guide, we’ll walk through how to interactively enter a running container, why the command works, and how to handle edge cases like Alpine Linux or permission errors.

Step 1: Identify Your Target

Before you can enter a container, you need its unique identifier. Open your terminal and list your running containers:

docker ps

You will see output that looks like this:

CONTAINER ID   IMAGE          COMMAND                  STATUS          NAMES
a1b2c3d4e5f6   nginx:latest   "/docker-entrypoint.…"   Up 10 minutes   my-web-server

You can target the container using either the CONTAINER ID (the alphanumeric string a1b2c3d4e5f6) or the NAME (my-web-server). The name is usually easier to remember.

Step 2: The Golden Command

To open a shell inside that container, run the following command:

docker exec -it my-web-server /bin/bash

If successful, your terminal prompt will change. You are no longer on your host machine; you are inside the container, usually logged in as root or the default application user.

From here, you can use standard Linux commands like ls, cat, top, or curl to debug your application from the inside out.

Deconstructing the Command

If you just copy-paste the command, you might not understand why it fails in certain scenarios. Here is exactly what those flags are doing:

• exec: This tells Docker to run a command inside an existing container (as opposed to run, which starts a new one).

• -i (Interactive): This keeps “Standard Input” (STDIN) open. It allows the container to receive the keystrokes you type.

• -t (TTY): This allocates a pseudo-terminal. It simulates a real terminal environment so you get a command prompt and formatted output.

• /bin/bash: This is the actual command we are running. We are launching the Bash shell program.

Troubleshooting: When /bin/bash Fails

The command above works for 90% of containers (Ubuntu, Debian, CentOS based). However, you will eventually run into an error that looks like this:

OCI runtime exec failed: exec: “/bin/bash”: stat /bin/bash: no such file or directory

This usually happens because you are using a lightweight image, such as Alpine Linux. To keep the image size small, Alpine does not include Bash. It uses the standard Bourne shell (sh) instead.

The Fix: simply change the shell command at the end:

docker exec -it my-web-server /bin/sh

Advanced Tricks

1. Entering as Root

Sometimes you enter a container, but you are logged in as a restricted user (like www-data or node). If you try to install a debug tool or edit a config file, you’ll get a “Permission Denied” error.

You can force Docker to log you in as the root user (User ID 0) by adding the -u flag:

docker exec -u 0 -it my-web-server /bin/bash

2. For Docker Compose Users

If you are running your stack via Docker Compose, you don’t need to look up the specific container ID with docker ps. You can use the service name defined in your docker-compose.yml file:

docker compose exec web_service /bin/bash

A Critical Warning: exec vs. attach

While searching for answers, you might see tutorials recommending docker attach.

Avoid using docker attach for debugging.

• exec creates a separate process (a side session) alongside your application.

• attach connects your terminal to the main process running the application (PID 1).

If you are “attached” to the main process and you hit Ctrl+C to exit, you will kill the application and the container will stop. With exec, you can enter and exit freely without affecting the running service.

Summary Cheat Sheet

Now that you’re inside, you can check configuration files, verify permissions, or test network connectivity manually. Just remember: containers are ephemeral. Any changes you make to files inside the container will be lost if you delete the container. Use exec for debugging, not for permanent updates.