Introduction

A container can only write to the host filesystem if you deliberately mount host-backed storage into it. In practice, that usually means either a bind mount to a specific host path or a Docker-managed volume that lives on the host and survives container restarts.

Bind Mounts Versus Volumes

If your goal is "write into this exact directory on my machine," use a bind mount. If your goal is durable container data without caring about the exact host path, use a named volume.

A bind mount maps a real host directory into the container:

1mkdir -p "$PWD/output"
2docker run --rm \
3  --mount type=bind,source="$PWD/output",target=/app/output \
4  alpine sh -c 'echo hello > /app/output/result.txt'

After the container exits, the host file exists at ./output/result.txt.

A named volume is similar from the container's point of view, but Docker manages the storage location:

1docker volume create appdata
2docker run --rm \
3  --mount type=volume,source=appdata,target=/app/data \
4  alpine sh -c 'echo hello > /app/data/result.txt'

Both write to host-backed storage. The difference is operational control.

Writing To A Specific Host Path

For direct host filesystem access, bind mounts are the normal choice. The modern syntax is --mount, though -v also works.

1docker run --rm \
2  --mount type=bind,source=/tmp/demo-output,target=/data \
3  python:3.12-slim \
4  python -c "from pathlib import Path; Path('/data/report.txt').write_text('done\n')"

This makes /tmp/demo-output/report.txt appear on the host.

If you prefer the short syntax:

docker run --rm -v /tmp/demo-output:/data alpine sh -c 'date > /data/created.txt'

Use absolute paths when possible. They reduce confusion and avoid shell-dependent path expansion problems.

Using Docker Compose

The same idea applies in Compose:

1services:
2  app:
3    image: python:3.12-slim
4    command: python -c "from pathlib import Path; Path('/logs/app.log').write_text('ok\n')"
5    volumes:
6      - ./logs:/logs

When the service runs, the container writes to /logs/app.log, and the host sees the file in ./logs/app.log.

This is the cleanest option for development setups where logs, generated files, or build artifacts need to remain outside the container.

Ownership And Permissions

Mounting a directory is only half the job. The process in the container still needs permission to write there.

A common failure mode is that the container runs as a non-root user while the host directory belongs to another user or has restrictive permissions. You can inspect this quickly:

1ls -ld /tmp/demo-output
2docker run --rm \
3  --mount type=bind,source=/tmp/demo-output,target=/data \
4  alpine sh -c 'id && touch /data/test.txt'

If the touch fails, fix the host directory ownership or run the container with a compatible user ID.

When Not To Use A Bind Mount

Bind mounts are powerful, but they reduce isolation. The container can overwrite host files in the mounted directory. That is fine for controlled outputs, but risky if you mount broad paths such as your home directory or a system directory.

For application state that does not need a human-friendly host path, a named volume is safer and more portable.

A Small Runnable Example

This Python script writes JSON into the mounted directory:

1from pathlib import Path
2import json
3
4payload = {"status": "ok", "items": 3}
5Path("/out/result.json").write_text(json.dumps(payload, indent=2) + "\n")

Run it with:

1mkdir -p "$PWD/out"
2docker run --rm \
3  --mount type=bind,source="$PWD/out",target=/out \
4  -v "$PWD/script.py:/app/script.py:ro" \
5  python:3.12-slim python /app/script.py

The file created inside the container ends up on the host because /out is backed by the host directory.

Common Pitfalls

The most common mistake is expecting container writes to appear on the host without a mount. They will not. Container filesystem changes live inside the container layer unless you mount storage.

Another mistake is mounting the wrong path. If the host source path is empty or misspelled, Docker may create a directory you did not intend, and you will look in the wrong place for the output.

Permissions are another frequent problem. A bind mount does not bypass Unix permissions.

Finally, do not mount more of the host than necessary. Give the container access only to the directory it actually needs to write.

Summary

• To write to the host from a container, mount host-backed storage.
• Use a bind mount when you need a specific host path.
• Use a named volume when you need persistence but not a fixed host location.
• Check file ownership and permissions if writes fail.
• Without a mount, container writes stay inside the container filesystem.