Skip to content

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

Description

@ryanmitchellneely

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions