catalog / docker.io/library/nextcloud / criteria

nextcloud — validation criteria

Per-image acceptance criteria for the docker.io/library/nextcloud profile (apache variant). Validated against …@sha256:90fdc9f9… (tag 32), derived by drop-test against the default in-stack invocationMYSQL_* env against a mariadb database, NEXTCLOUD_ADMIN_* auto-install. Capabilities trim 14 → 6, the same set as sibling wordpress (both are root-entrypoint-copy + apache-worker images).

Representative workload / correctness check

profiles/workloads/nextcloud.sh — wait for occ status to report installed, then a WebDAV PUT/GET round-trip as the auto-installed admin: a real file write through the full apache → php → storage path, read back byte-identical. The drop-test correctness check additionally asserts a worker runs as www-data (uid 33) — the httpd/wordpress sharp edge (a broken SETGID drop keeps serving with root workers).

The in-stack trial lifecycle (measured on 32, encoded in the csd correctness check): the database dep persists across trials, and a fresh-docroot nextcloud cannot adopt an installed database — it boots into a running-but-broken installed: false limbo. Per-trial recovery: reset the database (root exec in the dep) and docker restart the target; its entrypoint then performs a clean install under the trial's cap posture. The trial's first boot has already rsync'd the sources into its fresh volume under that same posture, so the copy phase and the install phase are both exercised in every trial.

Probe hygiene (all three catalog rules apply): occ execs as --user www-data; WebDAV goes through the curl sidecar; responses are captured then matched (never curl | grep -q under pipefail); no probe writes inside the target.

capabilities — derived by drop-test

filesystem — derived by drop-test

Scope (run_config + out-of-band conditions)