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:
@@ -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
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user