From 820787c7bfe2919bc8523ed20e1fc8de1947e42f Mon Sep 17 00:00:00 2001 From: Saksham Das Date: Wed, 5 Aug 2026 15:46:46 -0400 Subject: [PATCH] Fix celery beat permission error: chown /app itself, not just its contents COPY --chown fixes the files being copied in, but WORKDIR had already created /app as root beforehand - the directory entry itself stayed root:root (no write bit for appuser), so celery beat's schedule-file write still failed with Permission denied even after the earlier --chown fix. Confirmed live on the actual deployment (local testing hadn't caught this). Co-Authored-By: Claude Sonnet 5 --- infrastructure/docker/api.Dockerfile.prod | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/infrastructure/docker/api.Dockerfile.prod b/infrastructure/docker/api.Dockerfile.prod index 22eed18..3dc58e1 100644 --- a/infrastructure/docker/api.Dockerfile.prod +++ b/infrastructure/docker/api.Dockerfile.prod @@ -31,11 +31,15 @@ RUN useradd --create-home --uid 1000 appuser WORKDIR /app COPY --from=builder /venv /venv -# --chown so appuser can actually write here - celery beat needs to write -# its schedule state file (celerybeat-schedule) into the working directory, -# and a plain COPY leaves everything root-owned even after USER switches -# the running process to appuser. +# --chown fixes the *contents* being copied, but WORKDIR above already +# created /app itself as root beforehand - COPY --chown doesn't retroactively +# fix a pre-existing directory's own ownership, only what it copies into it. +# Confirmed live: celery beat writing its schedule file (celerybeat-schedule) +# directly into /app failed with "Permission denied" even with --chown here, +# because /app itself was still root:root (mode 755, no write bit for +# appuser). The explicit chown below fixes the directory entry itself. COPY --chown=appuser:appuser apps/api /app +RUN chown appuser:appuser /app USER appuser