Edit a file in a running Docker container

For a temporary investigation, either open a shell with docker exec or copy the file out, edit it locally, and copy it back. First identify whether the path belongs to the container's writable layer or a mount: an edit to a mounted file can also affect host storage or other containers.

Edit inside the container

docker container ls
docker exec -it myapp /bin/sh

Use Bash only if the image contains it. Work as the existing user where possible; if the task requires elevated container privileges and they are appropriate, docker exec -u 0 -it myapp /bin/sh selects UID 0. It does not bypass a read-only mount or every host security policy.

A Debian-based image may support apt-get update && apt-get install -y nano; Alpine may support apk add --no-cache nano. These need the package manager, permissions, and network access. Distroless images often have neither a shell nor a package manager.

For a simple known text file, an in-place replacement is another option:

docker exec myapp sed -i 's/debug=false/debug=true/' /etc/app/app.conf

Inspect the file first and verify the result. This example is a literal configuration convention, not a general YAML editor. sed -i syntax and replacement behavior can differ across tool implementations, and replacing a bind-mounted single file through a rename may fail.

Edit with local tools

docker cp myapp:/etc/app/config.yml ./config.yml
cp ./config.yml ./config.yml.before-edit
# Edit and validate config.yml locally.
docker cp ./config.yml myapp:/etc/app/config.yml

This avoids installing an editor inside the container, but still changes its files. Check ownership afterward: copied-in files are normally root-owned unless archive ownership is explicitly preserved. Keep the original copy for a deliberate rollback.

Apply and retain the intended change

For Nginx, run docker exec myapp nginx -t, and only after success use docker exec myapp nginx -s reload. Other applications have their own reload or restart procedure.

A normal restart retains the same container's writable layer, although startup scripts may regenerate files. Removal and recreation discard that layer. Record the final change in the Dockerfile, mounted configuration, or configuration-management source so a replacement behaves consistently.

FAQ

What if the image has no shell?

docker cp can still retrieve or replace suitable files. Use a supported debug workflow for inspection rather than assuming /bin/sh must exist.

Why is the filesystem read-only?

Inspect the container's root-filesystem and mount settings. Reconfigure and recreate through the deployment source if writing is actually required; copying does not override read-only storage.

What about Kubernetes?

kubectl exec offers similar process access when the image supports it, but managed configuration should normally come from the workload definition or ConfigMaps/Secrets. Applications may still need a reload, and some mount arrangements do not receive automatic file updates.

See container exec and container cp.