Read-only filesystem containers in Docker - Commands & Configuration

Introduction

Sometimes you want to make sure a container cannot change its files to keep it safe and stable. Using a read-only filesystem means the container can only read files but cannot write or change them. This helps prevent accidental or harmful changes inside the container.

When running a container that only needs to read data and should not modify it, like a web server serving static files.

When you want to improve security by stopping attackers from changing files if they get access to the container.

When you want to make sure your container behaves the same every time by preventing file changes.

When running containers in production where stability and immutability are important.

When debugging or testing to ensure no files are accidentally changed during the container run.

Commands

This command runs a temporary container from the busybox image with its filesystem set to read-only. It lists the root directory to show the container is running and can read files.

Terminal

docker run --rm --read-only busybox ls /

Expected Output

bin

etc

proc

sys

usr

→

--read-only - Makes the container's filesystem read-only, preventing any file changes.

→

--rm - Automatically removes the container after it exits to keep the system clean.

This tries to create a new file inside the read-only container. It will fail because the filesystem does not allow writing.

Terminal

docker run --rm --read-only busybox touch /testfile

Expected Output

touch: /testfile: Read-only file system

→

--read-only - Prevents writing to the container filesystem.

→

--rm - Removes the container after it stops.

This runs a container with a read-only root filesystem but mounts a writable host directory at /data. It creates a file inside the mounted directory and lists it to show writing is allowed there.

Terminal

docker run --rm --read-only -v /tmp/data:/data busybox sh -c "touch /data/newfile && ls /data"

Expected Output

newfile

→

--read-only - Makes the container root filesystem read-only.

→

-v - Mounts a host directory to allow writing in that specific path.

→

--rm - Removes the container after it exits.

Key Concept

If you remember nothing else from this pattern, remember: the --read-only flag locks the container's filesystem to prevent any changes, improving security and stability.

Common Mistakes

Trying to write files inside the container without mounting a writable volume.

The container filesystem is read-only, so write operations fail with errors.

Mount a writable volume using -v to allow writing in specific directories.

Not using --rm flag during testing and leaving stopped containers on the system.

This clutters the system with unused containers and wastes disk space.

Always use --rm for temporary containers to clean up automatically.

Summary

Use the --read-only flag to make the container filesystem read-only and prevent file changes.

Write operations inside a read-only container fail unless you mount a writable volume.

Use -v to mount writable directories when you need to allow specific file changes.

Practice

1. What does the --read-only flag do when starting a Docker container?

easy

A. Runs the container with root privileges.

B. Deletes all files inside the container before starting it.

C. Makes the container's filesystem read-only, preventing any changes inside it.

D. Allows the container to write to the host filesystem.

Solution

1. Step 1: Understand the --read-only flag purpose

   The --read-only flag makes the container's filesystem read-only, so no files can be changed or created inside the container.

2. Step 2: Compare other options

   Running with root privileges, deleting files, or allowing writes to the host filesystem are unrelated or incorrect behaviors for this flag.

3. Final Answer:

   Makes the container's filesystem read-only, preventing any changes inside it. -> Option C

4. Quick Check:

   --read-only = read-only filesystem [OK]

Hint: Remember: --read-only locks container files from changes [OK]

Common Mistakes:

• Thinking it deletes files instead of locking them
• Confusing with volume mounts
• Assuming it grants root access

2. Which of the following is the correct Docker command to start a container with a read-only filesystem?

easy

A. docker run --read-only alpine

B. docker run --readonly alpine

C. docker run -ro alpine

D. docker run --readwrite alpine

Solution

1. Step 1: Check the correct flag syntax

   The correct flag to make the filesystem read-only is --read-only with a hyphen.

2. Step 2: Validate options

   docker run --read-only alpine uses the correct flag --read-only. The short flag -ro doesn't exist, --readonly lacks the hyphen, and --readwrite is the opposite meaning.

3. Final Answer:

   docker run --read-only alpine -> Option A

4. Quick Check:

   Correct flag is --read-only [OK]

Hint: Use double dash and hyphen: --read-only [OK]

Common Mistakes:

• Using --readonly without hyphen
• Using short flags like -ro which don't exist
• Confusing with --readwrite

3. Consider this command:
docker run --read-only -v /data alpine sh -c "echo hello > /data/file.txt && cat /data/file.txt"
What will be the output?

medium

A. hello

B. Permission denied error

C. No such file or directory error

D. Empty output

Solution

1. Step 1: Understand --read-only with volume mount

   The container filesystem is read-only, but the /data directory is mounted as a volume, which is writable.

2. Step 2: Analyze the command behavior

   The command writes "hello" to /data/file.txt and then reads it back. Since /data is writable, this succeeds and outputs "hello".

3. Final Answer:

   hello -> Option A

4. Quick Check:

   Writable volume inside read-only container = writable [OK]

Hint: Writable volumes override read-only container filesystem [OK]

Common Mistakes:

• Assuming entire container is fully read-only including volumes
• Expecting permission denied on volume writes
• Confusing volume mount syntax

4. You run this command:
docker run --read-only alpine sh -c "touch /tmp/testfile"
But it fails with a permission error. What is the best fix?

medium

A. Remove the --read-only flag

B. Add a writable tmpfs mount for /tmp using --tmpfs /tmp

C. Run the container as root user

D. Use -v /tmp:/tmp to mount host /tmp

Solution

1. Step 1: Identify cause of permission error

   The container filesystem is read-only, so creating files in /tmp fails.

2. Step 2: Provide writable space with tmpfs

   Using --tmpfs /tmp mounts a writable temporary filesystem at /tmp, allowing file creation despite read-only root.

3. Final Answer:

   Add a writable tmpfs mount for /tmp using --tmpfs /tmp -> Option B

4. Quick Check:

   Writable tmpfs fixes write errors in read-only containers [OK]

Hint: Use --tmpfs to add writable temp folders in read-only containers [OK]

Common Mistakes:

• Removing --read-only loses security benefits
• Mounting host /tmp may cause permission issues
• Assuming root user can write despite read-only filesystem

5. You want to run a container with a read-only filesystem but allow writing only to /app/logs. Which command correctly achieves this?

hard

A. docker run --read-only alpine

B. docker run --read-only --tmpfs /app/logs alpine

C. docker run -v /host/logs:/app/logs alpine

D. docker run --read-only -v /host/logs:/app/logs alpine

Solution

1. Step 1: Understand read-only with writable folder

   The container filesystem is read-only, but mounting a host directory as a volume at /app/logs makes that folder writable.

2. Step 2: Evaluate options

   docker run --read-only -v /host/logs:/app/logs alpine uses --read-only plus a volume mount for writable logs. docker run --read-only --tmpfs /app/logs alpine uses tmpfs which is temporary and not persistent. docker run -v /host/logs:/app/logs alpine lacks --read-only. docker run --read-only alpine has no writable folder.

3. Final Answer:

   docker run --read-only -v /host/logs:/app/logs alpine -> Option D

4. Quick Check:

   Volume mount + --read-only = writable folder [OK]

Hint: Use volume mount with --read-only for writable folders [OK]

Common Mistakes:

• Using tmpfs when persistence is needed
• Forgetting --read-only flag
• Expecting writable without volume or tmpfs