Summary
A first-run of the production Compose bundle in deploy/compose/ never reaches a healthy relay. The buzz-git-data named volume is created root-owned, but the relay container runs as non-root (buzz:buzz, uid 1000, per Dockerfile:153), so BUZZ_GIT_PACK_CACHE_PATH cannot be created and the container restart-loops.
Environment
- Relay image:
ghcr.io/block/buzz:main (digest-pinned), Linux x86_64 VPS
- Docker 29.4.1, Compose v5.1.3
deploy/compose/compose.yml + a small local override (port binding + memory limits only; no changes to volumes or user)
- Fresh host, no pre-existing volumes
Steps to reproduce
- Copy
deploy/compose/, fill .env from .env.example (all CHANGE_ME replaced)
docker compose up -d
docker compose ps / docker compose logs relay
Actual
Postgres, Redis and MinIO go healthy; the relay never does:
ERROR Invalid configuration: invalid config: BUZZ_GIT_PACK_CACHE_PATH=/data/git/.pack-cache could not be created: Permission denied (os error 13)
Error: Configuration error: invalid config: BUZZ_GIT_PACK_CACHE_PATH=/data/git/.pack-cache could not be created: Permission denied (os error 13)
repeating on the restart policy indefinitely. /_readiness is unreachable for the entire time.
Expected
Either the relay creates its own cache directory inside the volume it was given, or the bundle prepares ownership so the non-root runtime user can.
Workaround (confirmed)
docker compose down
chown -R 1000:1000 "$(docker volume inspect <project>_buzz-git-data --format '{{.Mountpoint}}')"
docker compose up -d
Relay then starts cleanly, passes the A3 git object-store conformance probe, and /_readiness returns 200.
Suggested fix
Any of: an init step in the bundle that chowns the volume (the pattern already used for minio-init), a user: / entrypoint chown in the relay service, or — cheapest — a documented prerequisite in deploy/compose/README.md. Happy to send a PR for whichever you prefer.
Notes
Not reproducible with the root-level docker-compose.yml dev stack, which is presumably why it survives: the failure is specific to the production bundle on a clean host.
Summary
A first-run of the production Compose bundle in
deploy/compose/never reaches a healthy relay. Thebuzz-git-datanamed volume is created root-owned, but the relay container runs as non-root (buzz:buzz, uid 1000, perDockerfile:153), soBUZZ_GIT_PACK_CACHE_PATHcannot be created and the container restart-loops.Environment
ghcr.io/block/buzz:main(digest-pinned), Linux x86_64 VPSdeploy/compose/compose.yml+ a small local override (port binding + memory limits only; no changes to volumes or user)Steps to reproduce
deploy/compose/, fill.envfrom.env.example(allCHANGE_MEreplaced)docker compose up -ddocker compose ps/docker compose logs relayActual
Postgres, Redis and MinIO go healthy; the relay never does:
repeating on the restart policy indefinitely.
/_readinessis unreachable for the entire time.Expected
Either the relay creates its own cache directory inside the volume it was given, or the bundle prepares ownership so the non-root runtime user can.
Workaround (confirmed)
Relay then starts cleanly, passes the A3 git object-store conformance probe, and
/_readinessreturns 200.Suggested fix
Any of: an init step in the bundle that chowns the volume (the pattern already used for
minio-init), auser:/ entrypoint chown in the relay service, or — cheapest — a documented prerequisite indeploy/compose/README.md. Happy to send a PR for whichever you prefer.Notes
Not reproducible with the root-level
docker-compose.ymldev stack, which is presumably why it survives: the failure is specific to the production bundle on a clean host.