saksham/CIAgent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix celery beat permission error: chown /app itself, not just its contents

Browse Source 
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:
saksham
2026-08-05 15:46:46 -04:00
co-authored by Claude Sonnet 5
parent 086ca1f13f
commit 820787c7bf
1 changed files with 8 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
infrastructure/docker/api.Dockerfile.prod
+8 -4
View File
@@ -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