Problem

After a security hardening pass, api won't start. It was given a read-only root filesystem (--read-only), and now it dies on boot the moment it tries to write its cache. The image and config are unchanged — only the hardening flag was added. Get it running again while keeping the root filesystem read-only.

Initial setup

• api — myapp:latest, Exited (1), started with a read-only root FS.
• The app needs to write to /app/cache at startup.

Example interaction

$ docker logs api
OSError: [Errno 30] Read-only file system: '/app/cache/session.db'

Acceptance

You've solved it when:

• You can explain, from the crash log, the actual reason the write fails

— what the app tried to do, what the filesystem refused, and why the startup aborts — rather than jumping to a permissions, missing-directory, or disk-full guess.

• You've brought api up running while keeping the root FS read-only —

by giving its writable path a --tmpfs /app/cache (or a volume mounted there), so the app can write without un-hardening the whole container.

Constraints

• Tools: docker CLI only.
• End state: api running; the writable path is backed by a tmpfs/volume

(dropping --read-only entirely is the lazy answer — prefer scoping the writable path).

Follow-up

1. Why does --read-only make /app/cache unwritable but `--tmpfs

/app/cache` fix it without touching the rest of the root FS?

1. Which paths typically still need to be writable under a read-only root

(/tmp, pid files, caches) and how do you enumerate them?

1. Why is "just remove --read-only" the wrong fix from a security stance?