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
Plan (repo-manager), checked against next at 99735f4:
deploy/docker-entrypoint.sh already runs as root, gives /var/lib/pixa to pixad (uid and gid 65532) and drops to it with su-exec. Two gaps against this issue: it does not create the directory if missing, and it changes only the directory's own owner, so data left by an earlier run under another uid (1000, before #151) stays unwritable. The fix: create the directory if needed, give the directory and everything in it to pixad when any of it is owned by someone else, set its mode, then drop and exec as now.
README.md "Running under upaas": the first-run step and "the host directory must exist before the first deploy" go; the section says only which path to mount.
The host directory's existence is upaas's side: Docker refuses a bind mount whose host path is missing and upaas does not create it. Filed as sneak/upaas#235.
The first-deploy PR #147 no longer tells the operator to pre-create the directory.
Model: opus-5-5
Plan (repo-manager), checked against `next` at `99735f4`:
- `deploy/docker-entrypoint.sh` already runs as root, gives `/var/lib/pixa` to `pixad` (uid and gid 65532) and drops to it with `su-exec`. Two gaps against this issue: it does not create the directory if missing, and it changes only the directory's own owner, so data left by an earlier run under another uid (1000, before https://git.eeqj.de/sneak/pixa/issues/151) stays unwritable. The fix: create the directory if needed, give the directory and everything in it to `pixad` when any of it is owned by someone else, set its mode, then drop and exec as now.
- `README.md` "Running under upaas": the first-run step and "the host directory must exist before the first deploy" go; the section says only which path to mount.
- The host directory's existence is upaas's side: Docker refuses a bind mount whose host path is missing and upaas does not create it. Filed as https://git.eeqj.de/sneak/upaas/issues/235.
- The first-deploy PR https://git.eeqj.de/sneak/pixa/pulls/147 no longer tells the operator to pre-create the directory.
Model: opus-5-5
Built in #161: the entrypoint creates /var/lib/pixa if missing, gives it and everything in it to pixad when it or one of its top-level entries belongs to someone else, sets its mode, then runs the server as pixad; the upaas section of the README no longer asks the operator to create or chown the host directory.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/pixa/pulls/161: the entrypoint creates `/var/lib/pixa` if missing, gives it and everything in it to `pixad` when it or one of its top-level entries belongs to someone else, sets its mode, then runs the server as `pixad`; the upaas section of the README no longer asks the operator to create or chown the host directory.
Model: opus-5-5
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
Plan (repo-manager), checked against
nextat99735f4:deploy/docker-entrypoint.shalready runs as root, gives/var/lib/pixatopixad(uid and gid 65532) and drops to it withsu-exec. Two gaps against this issue: it does not create the directory if missing, and it changes only the directory's own owner, so data left by an earlier run under another uid (1000, before #151) stays unwritable. The fix: create the directory if needed, give the directory and everything in it topixadwhen any of it is owned by someone else, set its mode, then drop and exec as now.README.md"Running under upaas": the first-run step and "the host directory must exist before the first deploy" go; the section says only which path to mount.Model: opus-5-5
Built in #161: the entrypoint creates
/var/lib/pixaif missing, gives it and everything in it topixadwhen it or one of its top-level entries belongs to someone else, sets its mode, then runs the server aspixad; the upaas section of the README no longer asks the operator to create or chown the host directory.Model: opus-5-5