Run containers as the host user instead of root
Everything the containers wrote into the bind mounts (surreal_data, notebook_data) was owned by root, so the host user could not delete or back up his own podcast data — prune_podcast_data.py and update_stack.sh had to detour through `docker compose exec` for every rm and tar. That was not a requirement, just the default: the open_notebook image declares no USER, and the compose file even overrode surrealdb's own non-root user (65532) with `user: root`, under the comment "Required for bind mounts on Linux" — which is not true. Both services now run as user: "1000:1000". Two things this needs: - HOME=/tmp for open_notebook. Without it HOME resolves to "/" for a non-root uid, uv cannot create /.cache/uv, and api + worker exit 2 at startup. Verified by running the image as uid 1000 both ways. - The data directories must be owned by that uid. Existing data was adopted with a throwaway root container (chown -R), no sudo needed. Both scripts drop the container detour and operate on the host directly, which is simpler and now honest. smoke_test.sh gained two checks so a silent regression to root cannot go unnoticed: the container's uid must match the host user, and no foreign-owned files may exist under the data directories. Verified: containers run as uid 1000, new files land as dschlueter and are deletable without sudo, SurrealDB writes as 1000, a source can be created, embedded and deleted through the API, and the full smoke test is green. Note this deviates from what the image expects (it assumes root), so it is exactly the kind of assumption an update can break — hence the smoke-test checks. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
parent
09c6d910a7
commit
9e6d790830
6 changed files with 96 additions and 40 deletions
|
|
@ -53,19 +53,17 @@ mkdir -p "$backup"
|
|||
say "2/5 Stack stoppen und sichern -> backups/$ts"
|
||||
docker compose down
|
||||
cp docker-compose.yml "$backup/docker-compose.yml"
|
||||
# Die Datenverzeichnisse gehoeren root (der Container schreibt als root), deshalb wird
|
||||
# im Container gepackt statt auf dem Host — spart sudo.
|
||||
docker run --rm -v "$REPO:/work" -w /work --entrypoint tar \
|
||||
"lfnovo/open_notebook@$pinned" -czf "backups/$ts/data.tgz" surreal_data notebook_data
|
||||
# Direkt auf dem Host, weil die Container als Host-User laufen (user: "1000:1000")
|
||||
# und die Daten uns gehoeren. Liefen sie als root, scheiterte das an den Rechten.
|
||||
tar -czf "$backup/data.tgz" surreal_data notebook_data
|
||||
echo " $(du -sh "$backup/data.tgz" | cut -f1) gesichert"
|
||||
|
||||
restore() {
|
||||
say "ROLLBACK"
|
||||
docker compose down || true
|
||||
cp "$backup/docker-compose.yml" docker-compose.yml
|
||||
docker run --rm -v "$REPO:/work" -w /work --entrypoint sh \
|
||||
"lfnovo/open_notebook@$pinned" -c \
|
||||
"rm -rf surreal_data notebook_data && tar -xzf backups/$ts/data.tgz"
|
||||
rm -rf surreal_data notebook_data
|
||||
tar -xzf "$backup/data.tgz"
|
||||
docker compose up -d
|
||||
echo " Alter Stand ($pinned) ist wiederhergestellt, Daten aus backups/$ts."
|
||||
echo " Das neue Image bleibt lokal liegen — Ursache pruefen, dann erneut versuchen."
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue