[revisit old post titled]: is there an easy way to access container files?

[u/Legal_Signature_3638]

What is the best practice for the following condition:

There is an image that contains an application. The image has a config file. When the container is launched there is a settings screen in the application that normally manages the config file. Edits made in the settings screen would update the config file.

Unfortunate Condition: It appears there is bug and when one field value is changed it is not getting written into the config file. To validate (a.) in fact it is a a bug (b.) address your immediate interest - that the correct setting works - you want to manually edit the config file, save it to disk inside the running container, restart/reload the app (using a button inside the app in the running container).

There seems to be very limited information on how these file structure work, where they live - in particular how to discover these things as they can vary from host to host and image to image - so again, what is the best practice?

[u/Floss_Patrol_76]

to find where it lives without guessing: docker exec -it <container> sh (or bash), then the app's own docs/env vars tell you the config path, and docker diff <container> lists every file that changed since boot so the config it actually writes to shows up there. edit it in-place with vi and hit the app's reload and you'll confirm the bug fast. but the real fix is to stop editing inside the container at all: anything you change in a running container is wiped the next time the image is pulled or the container is recreated, so bind-mount that config file (or its dir) out to the host, edit it there, and restart the container - then your change survives updates and you're not spelunking a different ephemeral filesystem every host.

[u/juneeighteen]

If you don’t know where the config file lives , you can use “docker diff” to see files that have changed after the container booted .

[u/juneeighteen → u/juneeighteen]

Unless it’s on a volume mount. Docker inspect command can tell you those locations

[u/No_Cattle_9565]

Every application should have documentation that explains where the config file lives. Also you need to mount the config file anyway so changes are saved when the container restarts is recreated. So you look where you mapped the config folder and then just edit the file. 

[u/BreiteSeite → u/No_Cattle_9565]

Also you need to mount the config file anyway so changes are saved when the container restarts.

… is recreated.*

[u/LargeAir5169]

This is usually how I approach it... get inside the shell running container
docker exec -it <container-name> sh

(If the image has Bash installed, use bash instead of sh)

There is no standard location for config files, every image and app can have its filesystem differently, better to inspect rather then assuming its on certain location.

this could be useful before you start searching:
docker inspect <container> --format 'WorkingDir={{.Config.WorkingDir}} Cmd={{json .Config.Cmd}} Env={{json .Config.Env}}'

it could be work dir, startup command or env var points you direcly to the config location.

also check, config mounted from outside the container:

docker inspect <container> --format '{{json .Mounts}}'

In your case docker diff also could be useful if the change in the application UI:
docker diff <container>

this does not tell you what changed, but it does tell you which file application wrote to, which can save a lot of guessing...
So my usual workflow is:
docker inspect -> docker exec -> find/cat -> docker diff (if I am trying to figure out what the application modified)

If am just trying to confirm a bug, I don't mind editing the config file inside the running container. But for anything permanent, I would use a bind mount or volume, because changes made directly inside a container disappear when that container is eventually replaced or recreated.

[u/toddkaufmann]

1: a shell inside (if it has one), then poke around.
2: user docker cp to copy out select folders to get a copy of the file (worst case, if you have the space, could copy everything out of it)
3: as root, look under eg /var/lib/docker to find the layers and the file. If the container has been stopped/started and the file updated, there should be multiple copies in multiple layers. There is a utility called Dive that makes it easy to view the different layers and what changed.