The image's entrypoint starts as root and then runs `su-exec openbao "$@"`
before exec'ing the server. deploy.sh probed with
`--entrypoint id -u`, which BYPASSES the entrypoint, so it reported UID 0 and
chowned config.hcl, tls/ and the raft volume to root -- while the server ran
as uid 100 and could write none of it:
error initializing storage of type raft: failed to create fsm:
failed to open bolt file: open /openbao/data/vault.db: permission denied
The container crash-looped on that, and tls.key (0600 root:root) would have
failed the listener straight afterwards. Confirmed on the affected host:
the probe reports 0, `id -u openbao` reports 100, and the entrypoint's line
92 is `set -- su-exec openbao "$@"`.
Ask for the account the entrypoint switches to, falling back to the old probe
when the image has no such account (then the server really does run as
whatever the entrypoint started as). Preferring the service account is also
the safe direction to be wrong in: root ignores file permissions, so chowning
to the unprivileged uid still works if the server turns out to run as root,
whereas the reverse is fatal.
Gate the raft chown on the volume's ACTUAL ownership rather than on a
first-run flag. The flag was false forever after the first deploy, so a volume
left root-owned by an earlier run -- exactly the state this bug created --
could never be repaired by re-running; the operator had to chown it by hand.
Reading the owner costs one container start and still keeps the recursive
chown off a healthy live raft dir. FIRST_RUN is now unused, so it is gone.
Also from the same run, two reporting failures:
- `docker compose ps` printed "Restarting (1)" and the script went on to print
an unqualified DEPLOYED banner. It now inspects the container state and, when
it is not `running`, says plainly that this is a crash loop rather than the
expected sealed-and-unhealthy state -- before and after the banner, with the
logs command to run.
- Every `docker compose` command in that banner assumed the project directory.
deploy.sh runs them from $STACK_DIR itself, so the omission only bit the
operator afterwards, with "no configuration file provided: not found". The
banner now says to cd there first and quotes that error.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
57_WolveandClaude Opus 5
a02524ae6e