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've established the crash is a write to a read-only root filesystem

(Errno 30 / Read-only file system on /app/cache) caused by the --read-only hardening — not a permissions bug, missing dir, or disk-full.

• 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?