Can a Container Use Both a Read-Only Config Mount and Writable App Data?

Yes. Bind-mount configuration read-only and give application state a separate writable volume with the exact UID, GID, and backup policy it needs.

The decision matters when a self-hosted app should not rewrite configuration but must persist databases, uploads, or caches. The two competing states are read-only configuration path and separate writable state and temporary paths. Begin with a saved configuration and disposable data, observe one branch at a time, and stop if the test expands data-loss, permission, or availability risk.

Define the Conditions Behind the Mixed Read-Only Config And Writable Data Mounts Decision

Record the environment before changing anything: software and firmware versions, device identities, mount or network path, free space, permissions, and the observable symptom. The baseline must preserve enough detail to reproduce a self-hosted app should not rewrite configuration but must persist databases, uploads, or caches.

The first candidate is read-only configuration path. The second is separate writable state and temporary paths. The current Docker volume behavior defines the mechanism or command boundary used in the test; it does not replace observation from this specific home server.

Write the acceptance condition and stop condition before running the discriminator. A pass must change the evidence predicted by one branch while leaving unrelated services unchanged; a fail must return the system to the saved state rather than trigger a chain of speculative fixes.

Test the Claim Without Lowering the Original Requirement

Use this discriminator: inspect the image paths, mount config ro and data rw, then attempt a config write and normal data workflow before recreation. Keep workload, client, path, file set, and timing constant so the result is attributable to the changed variable.

Use read-only container filesystems to select the field that can actually separate the branches, then capture its timestamp, exit status, error text, device or snapshot identity, latency, transferred bytes, permissions, and recovery state. A clean command exit is not enough when identity, durability, or application state is the claim under test.

Repeat the test once after a restart, reconnect, remount, or cold cache when that event is part of the original condition. If the first run is destructive or the environment cannot be restored, stop and reproduce on a disposable copy instead.

volumes:
  - ./config.yml:/etc/app/config.yml:ro
  - app-data:/var/lib/app:rw

Interpret Pass, Fail, and Exception Results

PASS: config writes fail, app data persists across recreation, and temporary paths remain bounded. Record the exact version, identity, and workload that passed so the conclusion stays conditional rather than becoming a universal claim.

FAIL: the app expects to rewrite config, data lands in the container layer, or ownership blocks startup. A fail does not automatically prove the opposite branch when network, memory, permissions, or source consistency can influence both; isolate those shared dependencies before escalating.

EXCEPTION OR AMBIGUOUS RESULT: restore the previous mounts and split generated configuration from operator-owned configuration. Preserve logs and do not run repair, prune, destroy, repartition, or recursive ownership commands until a recoverable copy exists.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Confirm the Decision Under the Original Workload

Apply the action matched to the observed branch, then repeat the original condition rather than a reduced substitute. The decision holds only when config writes fail, app data persists across recreation, and temporary paths remain bounded across two cycles or the relevant reboot, sleep, interruption, or load transition.

Use the read-only application roots to check the nearest dependent workflow, but keep the original trigger unchanged. Unrelated datasets, shares, containers, users, and recovery points must retain their previous access and timing.

The stop boundary is explicit: if the app expects to rewrite config, data lands in the container layer, or ownership blocks startup, return to the last verified configuration, retain the evidence, and escalate to a deeper platform or hardware test only when the branch is repeatable.

After the target result holds, compare it with the container data ownership so the fix does not move risk into a neighboring service. A successful target test with a new backup, identity, timeout, or availability failure is still a failed change.

FAQ

For mixed read-only config and writable data mounts, the remaining searches usually concern can the whole root filesystem also be read-only, what if the app rewrites its config at startup, and should writable data and cache share a volume. The answers below keep those edge cases separate from the primary decision.

The acceptance boundary does not move: config writes fail, app data persists across recreation, and temporary paths remain bounded. If a follow-up condition changes the filesystem, identity, network path, or application version, repeat only the discriminator affected by that change.

Stop broadening the experiment when the app expects to rewrite config, data lands in the container layer, or ownership blocks startup. At that point, restore the previous mounts and split generated configuration from operator-owned configuration; preserve the evidence before escalating to the platform, storage, or hardware owner.

Can the whole root filesystem also be read-only?

Yes when every required writable path is provided separately, including temporary and runtime directories.

What if the app rewrites its config at startup?

Use a generated writable copy or image build step; do not silently make the authoritative config writable.

Should writable data and cache share a volume?

Only if they share retention and restore rules. Regenerable cache is usually better separated.

For mixed read-only config and writable data mounts, the practical answer remains conditional: config writes fail, app data persists across recreation, and temporary paths remain bounded. When the app expects to rewrite config, data lands in the container layer, or ownership blocks startup, restore the previous mounts and split generated configuration from operator-owned configuration; a partial success that cannot survive the original workload is not compatibility.