sneak, 2026-09-29 in chat, on the README instruction that the host data directory must be created and chowned to the app's uid before the first deploy (verbatim):
this is wrong. always make sure that the container sets appropriate permissions on the data dir before startup.
A standing rule for every app image: the container itself makes its data directory usable before the app starts. No operator step (mkdir, chown, chmod on the host) is needed or documented.
Definition of done:
The image starts correctly with an empty, root-owned host directory bind-mounted as its data directory, on first start and on every later start: an entrypoint running as root creates the directory if needed, sets its owner and mode for the app's user, then drops to that user (for example with su-exec or setpriv) and execs the app. The app process never runs as root.
It also works when the directory already holds data owned by another uid (for example from an earlier run under a different uid).
A test or a recorded run shows both cases: container healthy, app running as its unprivileged user, data written.
README: every instruction to pre-create or chown the host directory is removed; the upaas section says only which path to mount.
No change to where data lives or to the app's uid is needed; if one is, say why on this issue first.
Model: opus-5-5
sneak, 2026-09-29 in chat, on the README instruction that the host data directory must be created and chowned to the app's uid before the first deploy (verbatim):
> this is wrong. always make sure that the container sets appropriate permissions on the data dir before startup.
A standing rule for every app image: the container itself makes its data directory usable before the app starts. No operator step (mkdir, chown, chmod on the host) is needed or documented.
Definition of done:
- The image starts correctly with an empty, root-owned host directory bind-mounted as its data directory, on first start and on every later start: an entrypoint running as root creates the directory if needed, sets its owner and mode for the app's user, then drops to that user (for example with `su-exec` or `setpriv`) and execs the app. The app process never runs as root.
- It also works when the directory already holds data owned by another uid (for example from an earlier run under a different uid).
- A test or a recorded run shows both cases: container healthy, app running as its unprivileged user, data written.
- README: every instruction to pre-create or chown the host directory is removed; the upaas section says only which path to mount.
- No change to where data lives or to the app's uid is needed; if one is, say why on this issue first.
Model: opus-5-5
clawbot
self-assigned this 2026-09-29 11:07:46 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
sneak, 2026-09-29 in chat, on the README instruction that the host data directory must be created and chowned to the app's uid before the first deploy (verbatim):
A standing rule for every app image: the container itself makes its data directory usable before the app starts. No operator step (mkdir, chown, chmod on the host) is needed or documented.
Definition of done:
su-execorsetpriv) and execs the app. The app process never runs as root.Model: opus-5-5