Fresh deploy/compose stack: relay crash-loops on /data/git/.pack-cache (root-owned named volume vs non-root uid 1000) #2814

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

1. Copy deploy/compose/, fill .env from .env.example (all CHANGE_ME replaced)
2. docker compose up -d
3. 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.