Introduction

Reading output from a running Docker container is a normal debugging task, but Docker exposes logs and files through different mechanisms. Standard output and standard error come through docker logs, while regular files inside the container are read with docker exec or copied out with docker cp.

Read stdout and stderr with docker logs

If the application writes to standard output or standard error, use:

docker logs my_container

To follow logs in real time:

docker logs -f my_container

Useful options include:

docker logs --tail 100 my_container
docker logs --since 10m my_container

This is the fastest way to inspect runtime behavior when the containerized process follows the usual container logging pattern.

docker logs is not file access

A common source of confusion is expecting docker logs to read arbitrary files from the container filesystem. It cannot. docker logs only shows what the main process wrote to stdout and stderr.

If the application writes to a file such as /app/logs/app.log, Docker will not show that file automatically unless the application also forwards it to stdout. That distinction matters because many legacy apps still write only to files.

Read files with docker exec

To inspect a file in the running container, execute a command inside it:

docker exec my_container cat /app/logs/app.log

For large files, use tail:

docker exec my_container tail -n 100 /app/logs/app.log

To follow a file continuously:

docker exec -it my_container tail -f /app/logs/app.log

This is usually the right approach when the app logs to files instead of stdout.

Open an interactive shell when needed

If the image contains a shell, you can inspect the container more broadly:

docker exec -it my_container sh

Or:

docker exec -it my_container bash

Once inside, you can list directories, inspect permissions, and open files with the normal shell tools available in that image.

Copy files out of the container

If you want to examine a file locally, copy it out:

docker cp my_container:/app/logs/app.log ./app.log

You can also copy a directory:

docker cp my_container:/app/logs ./container-logs

This is often easier than staying inside the container when you want to search, archive, or compare files on the host.

Know the container state

If you are not sure which container to inspect, start with:

docker ps

If the container already exited, docker logs may still work, but docker exec will not because there is no running process namespace to enter. That difference explains why log access sometimes still succeeds after a crash while file inspection does not.

Prefer stdout logging when you control the app

For most containerized applications, writing logs to stdout and stderr is the better operational model. It makes docker logs useful immediately and helps orchestration platforms collect logs without extra file management.

File-based logging still has valid use cases, but if the application is under your control, stdout is usually the simplest default.

Common Pitfalls

• Expecting docker logs to show arbitrary files in the container filesystem.
• Trying docker exec against a stopped container.
• Assuming bash exists in minimal images when only sh or no shell is available.
• Keeping logs only in files when stdout logging would make container operations simpler.

Summary

• Use docker logs for stdout and stderr from the container’s main process.
• Use docker exec to read files inside a running container.
• Use docker cp to copy files or directories out of the container.
• Prefer stdout logging for simpler container debugging and log collection.