Container filesystem is ephemeral in Docker - Step-by-Step Execution

Process Flow - Container filesystem is ephemeral

Start Container

↓

Container Filesystem Created

↓

Write Files Inside Container

↓

Stop & Remove Container

↓

Container Filesystem Deleted

↓

Start New Container

↓

Fresh Filesystem, No Previous Data

This flow shows how a container's filesystem is created fresh at start, changes are temporary, and are lost when the container is stopped and removed.

Execution Sample

Docker

docker run -d --name test1 alpine sh -c "echo hello > /file.txt && sleep 3600"
docker stop test1
docker rm test1
docker run --name test2 alpine cat /file.txt

This sequence creates a container that writes a file, stops and removes it, then starts a new container trying to read that file.

Process Table

Step	Command	Action	Filesystem State	Output
1	docker run -d --name test1 alpine sh -c "echo hello > /file.txt && sleep 3600"	Start container and write file	File /file.txt created with content 'hello'
2	docker stop test1	Stop container	Filesystem still exists but container stopped
3	docker rm test1	Remove container and its filesystem	Filesystem deleted
4	docker run --name test2 alpine cat /file.txt	Start new container and try to read file	Fresh filesystem, no /file.txt	cat: /file.txt: No such file or directory

💡 New container has a fresh filesystem; previous container's files are lost because container filesystem is ephemeral.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
Filesystem /file.txt	absent	present with 'hello'	present with 'hello'	deleted	absent

Key Moments - 2 Insights

Why can't the new container read the file created by the old container?

Because each container has its own temporary filesystem that is deleted when the container is removed, as shown in step 3 where the filesystem is deleted.

Does stopping a container delete its filesystem?

No, stopping only pauses the container but the filesystem remains until the container is removed, as seen between steps 2 and 3.

Visual Quiz - 3 Questions

Look at the execution table, what is the output when the new container tries to read /file.txt?

A "hello"

B Empty output

C "cat: /file.txt: No such file or directory"

D Error: container not found

💡 Hint

Check step 4 in the execution table under Output column.

At which step is the container filesystem deleted?

A Step 3

B Step 2

C Step 1

D Step 4

💡 Hint

Look at the Action and Filesystem State columns in the execution table.

If we did not remove the first container, what would happen when starting the second container?

A The second container would see the file /file.txt

B The second container would still have a fresh filesystem

C Docker would throw an error about container name conflict

D The file would be empty

💡 Hint

Container names are test1 and test2 (different), so no name conflict. Each container has its own independent fresh filesystem.

Concept Snapshot

Container filesystem is temporary.
Files created inside a container exist only while it runs.
Stopping a container keeps filesystem; removing deletes it.
New containers start with a clean filesystem.
Use volumes to keep data persistent outside containers.

Full Transcript

When you start a Docker container, it creates a fresh filesystem. Any files you create inside exist only while the container runs. If you stop the container, the filesystem stays but the container is paused. When you remove the container, its filesystem is deleted. Starting a new container creates a new fresh filesystem without any files from the old container. This means container filesystems are ephemeral, or temporary. To keep data beyond container life, you use volumes. This example showed creating a file in one container, stopping and removing it, then starting a new container that could not see the old file.

Practice

1. What happens to files created inside a Docker container when the container is stopped and restarted?

easy

A. The files are deleted because the container filesystem is ephemeral.

B. The files are saved permanently inside the container.

C. The files are automatically copied to the host machine.

D. The files are backed up to Docker Hub.

Solution

1. Step 1: Understand container filesystem behavior

   Docker containers have an ephemeral filesystem, meaning changes inside the container do not persist after restart.

2. Step 2: Apply this to file creation

   Files created inside the container are lost when the container stops or restarts unless saved externally.

3. Final Answer:

   The files are deleted because the container filesystem is ephemeral. -> Option A

4. Quick Check:

   Container filesystem ephemeral = files lost on restart [OK]

Hint: Remember: container files reset on restart unless saved outside [OK]

Common Mistakes:

• Thinking files inside container persist after restart
• Assuming Docker automatically saves files externally
• Confusing container filesystem with host filesystem

2. Which Docker command correctly mounts a host directory /data to a container directory /app/data to persist data?

easy

A. docker run --env /data:/app/data myimage

B. docker run -p /data:/app/data myimage

C. docker run --link /data:/app/data myimage

D. docker run -v /data:/app/data myimage

Solution

1. Step 1: Identify volume mount syntax

   The correct syntax to mount a host directory is using -v host_path:container_path.

2. Step 2: Match the correct option

   docker run -v /data:/app/data myimage uses -v /data:/app/data, which is the correct way to mount the host directory.

3. Final Answer:

   docker run -v /data:/app/data myimage -> Option D

4. Quick Check:

   Volume mount uses -v host:container [OK]

Hint: Use -v host_path:container_path to mount volumes [OK]

Common Mistakes:

• Using -p instead of -v for volumes
• Confusing --link or --env with volume mounts
• Forgetting to specify both host and container paths

3. Consider this Dockerfile snippet:

FROM alpine
RUN echo "Hello" > /greeting.txt
CMD cat /greeting.txt

If you run this container, then modify /greeting.txt inside the running container to "Hi", then restart the container, what will cat /greeting.txt output?

medium

A. Hi

B. Hello

C. File not found error

D. Empty output

Solution

1. Step 1: Understand Dockerfile build vs container runtime

   The file /greeting.txt is created during image build with content "Hello".

2. Step 2: Recognize ephemeral container filesystem

   Changes made inside a running container (changing to "Hi") are lost after restart because the container filesystem resets.

3. Final Answer:

   Hello -> Option B

4. Quick Check:

   Container restart resets filesystem, original file restored [OK]

Hint: Changes inside container lost on restart; image files stay [OK]

Common Mistakes:

• Assuming changes inside container persist after restart
• Confusing image build files with runtime changes
• Expecting file to be missing after restart

4. You ran a container and created a file inside it. After restarting, the file disappeared. You want to keep the file persistent. Which of these fixes the problem?

medium

A. Restart the container with --restart=always flag.

B. Increase container memory limit.

C. Use a Docker volume to store the file outside the container.

D. Run the container with --rm option.

Solution

1. Step 1: Identify cause of file loss

   Files inside container are lost on restart because filesystem is ephemeral.

2. Step 2: Choose method to persist data

   Using a Docker volume stores data outside container, preserving files across restarts.

3. Final Answer:

   Use a Docker volume to store the file outside the container. -> Option C

4. Quick Check:

   Volumes keep data persistent beyond container life [OK]

Hint: Persist files with volumes, not restart flags or memory [OK]

Common Mistakes:

• Thinking restart flags keep files
• Confusing memory limits with filesystem persistence
• Using --rm removes container on exit, losing files

5. You want to run a container that writes logs to /var/log/app.log inside the container. You want these logs to persist even if the container is removed or recreated. Which Docker run command achieves this?

hard

A. docker run -v /host/logs/app.log:/var/log/app.log myapp

B. docker run --rm myapp

C. docker run -v /host/logs:/var/log/app.log myapp

D. docker run -v /host/logs/app.log:/var/log myapp

Solution

1. Step 1: Understand volume mount for specific file

   To persist a single log file, mount the host file to the container file path.

2. Step 2: Analyze options

   docker run -v /host/logs/app.log:/var/log/app.log myapp mounts /host/logs/app.log to /var/log/app.log inside container, persisting logs exactly.

3. Step 3: Why other options fail

   docker run -v /host/logs/app.log:/var/log myapp tries to mount file to directory path (invalid). docker run -v /host/logs:/var/log/app.log myapp tries to mount directory to file path (invalid). docker run --rm myapp removes container on exit, losing logs.

4. Final Answer:

   docker run -v /host/logs/app.log:/var/log/app.log myapp -> Option A

5. Quick Check:

   Mount host file to container file for persistent logs [OK]

Hint: Mount host file to container file path to persist logs [OK]

Common Mistakes:

• Mounting directory to file path (invalid)
• Using --rm which deletes container and files
• Mounting directory when only file persistence needed