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 <[email protected]>
This commit is contained in:
2026-08-05 15:46:46 -04:00
co-authored by Claude Sonnet 5
parent 086ca1f13f
commit 820787c7bf
+8 -4
View File
@@ -31,11 +31,15 @@ RUN useradd --create-home --uid 1000 appuser
WORKDIR /app WORKDIR /app
COPY --from=builder /venv /venv COPY --from=builder /venv /venv
# --chown so appuser can actually write here - celery beat needs to write # --chown fixes the *contents* being copied, but WORKDIR above already
# its schedule state file (celerybeat-schedule) into the working directory, # created /app itself as root beforehand - COPY --chown doesn't retroactively
# and a plain COPY leaves everything root-owned even after USER switches # fix a pre-existing directory's own ownership, only what it copies into it.
# the running process to appuser. # 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 COPY --chown=appuser:appuser apps/api /app
RUN chown appuser:appuser /app
USER appuser USER appuser