A report generator exits successfully. The next step cannot find its report. Rebuilding the image may feel productive, but I would first ask where that successful process wrote the file.
An image, one container created from it, and the files worth keeping are different things. Reusing an image does not make two executions the same execution. It also does not automatically move their output into the directory a person is looking at on the host.
Follow one path all the way out
Imagine a program writing /work/out/report.csv inside its container. A later command looks for ./out/report.csv on the host. Those names only describe the same file if the run connects those locations appropriately.
A bind mount can connect a host directory to a container path. A Docker-managed volume is another storage choice. The Docker volume documentation explains that a volume has a lifecycle outside a particular container; a container's writable layer does not survive removal of that container.
Persistence is still not a backup. A persistent file can be overwritten or deliberately removed. The recovery question remains separate from the question of whether a second container can read it.
| Boundary | Question |
|---|---|
| Program | Which exact path receives the output? |
| Container | Which mount covers that path? |
| Next consumer | Which path and permissions does it use? |
Mounting storage over an existing directory can also hide the files already visible at that location. An empty-looking directory is therefore not, on its own, proof that the image never contained the files.
Attach the log to the execution
I would keep the container identity, image identity, input and output path together in a debugging note. A convincing log from yesterday's similarly named container can otherwise explain the wrong execution.
Then inspect the file expected by the next step: its presence, size, format and a small content check appropriate to the job. An exit code describes the process outcome, while the next step needs a usable artifact. Neither check replaces the other.
The cleanup command belongs after that trace. If the only report lives in a disposable container, removing the container first converts a path question into a recovery problem.
한국어 글: Docker에서 실행은 끝났는데 파일이 안 보일 때