iris/iris-linux-server

Fork 0

Vault-Sync: .git des Vaults gehört root, Fetch scheitert an FETCH_HEAD (Permission denied) #107

New issue

Closed

opened 2026-10-28 09:43:37 +00:00 by alf · 2 comments

alf commented

2026-10-28 09:43:37 +00:00

Owner

Befund

Auf dem Dev-Host alf@iris-server schlägt die Vault-Synchronisation fehl, weil das .git des Vaults root gehört, der Server-Prozess aber als iris läuft:

POST /vault/sync/pull  →  {"ok":false,"pulled":false,...}
GET  /vault/sync/status → sync_state "error", error: "error: cannot open '.git/FETCH_HEAD': Permission denied"

Gemessen am 2026-10-28 im Container iris-server:

/vault gehört iris:iris, /vault/.git gehört root:root (angelegt 2026-10-20 10:36).
3723 Einträge unter /vault/.git gehören nicht iris; FETCH_HEAD fehlt noch, git kann es nicht anlegen.
Der Server läuft als iris (siehe Abschnitt „server läuft als non-root“ in linux-server/CLAUDE.md).

Vermutung (nicht belegt)

Das Repository wurde als root angelegt, etwa durch ein git init oder einen Commit per docker exec ohne -u iris, oder durch einen älteren Server als root. docker-entrypoint.sh chownt beim Start die data/-Pfade, aber offenbar nicht das .git im Vault. Wer es angelegt hat, ist nicht geklärt.

Auswirkung

Fetch, Pull und Push des Vaults schlagen fehl; sync_state bleibt error. Betrifft jedes Vault, dessen .git nicht iris gehört, nicht nur den Dev-Host. Beim Test der Freigabe des Git-Servers (iris/Iris#112) aufgefallen; unabhängig davon.

Zu klären

Soll der Entrypoint das .git des Vaults mitchownen (selbstheilend wie bei data/), oder soll die Sync-Logik einen solchen Zustand erkennen und eine verständliche Meldung statt der git-Rohmeldung liefern?
Wie kam das root-Repository auf den Host?

Der Dev-Host wurde nicht von Hand repariert (Regel: Zielsysteme nie von Hand patchen); der Fehler besteht dort weiter.

Zusammenhang: iris/Iris#76 (Vault-Synchronisation).

## Befund Auf dem Dev-Host `alf@iris-server` schlägt die Vault-Synchronisation fehl, weil das `.git` des Vaults `root` gehört, der Server-Prozess aber als `iris` läuft: ``` POST /vault/sync/pull → {"ok":false,"pulled":false,...} GET /vault/sync/status → sync_state "error", error: "error: cannot open '.git/FETCH_HEAD': Permission denied" ``` Gemessen am 2026-10-28 im Container `iris-server`: - `/vault` gehört `iris:iris`, `/vault/.git` gehört `root:root` (angelegt 2026-10-20 10:36). - 3723 Einträge unter `/vault/.git` gehören nicht `iris`; `FETCH_HEAD` fehlt noch, git kann es nicht anlegen. - Der Server läuft als `iris` (siehe Abschnitt „server läuft als non-root“ in `linux-server/CLAUDE.md`). ## Vermutung (nicht belegt) Das Repository wurde als `root` angelegt, etwa durch ein `git init` oder einen Commit per `docker exec` ohne `-u iris`, oder durch einen älteren Server als root. `docker-entrypoint.sh` chownt beim Start die `data/`-Pfade, aber offenbar nicht das `.git` im Vault. Wer es angelegt hat, ist nicht geklärt. ## Auswirkung Fetch, Pull und Push des Vaults schlagen fehl; `sync_state` bleibt `error`. Betrifft jedes Vault, dessen `.git` nicht `iris` gehört, nicht nur den Dev-Host. Beim Test der Freigabe des Git-Servers (iris/Iris#112) aufgefallen; unabhängig davon. ## Zu klären - Soll der Entrypoint das `.git` des Vaults mitchownen (selbstheilend wie bei `data/`), oder soll die Sync-Logik einen solchen Zustand erkennen und eine verständliche Meldung statt der git-Rohmeldung liefern? - Wie kam das root-Repository auf den Host? Der Dev-Host wurde nicht von Hand repariert (Regel: Zielsysteme nie von Hand patchen); der Fehler besteht dort weiter. Zusammenhang: iris/Iris#76 (Vault-Synchronisation).

alf referenced this issue

2026-10-28 09:48:51 +00:00

fix(entrypoint): .git des Vaults dem Server-Nutzer zuordnen, FETCH_HEAD-Fehler (#107) #108

alf commented

2026-10-28 09:48:52 +00:00

Author

Owner

PR #108 gemergt: fix(entrypoint): .git des Vaults dem Server-Nutzer zuordnen, FETCH_HEAD-Fehler (#107)
#108

Commits:

fix(entrypoint): .git des Vaults dem Server-Nutzer zuordnen, FETCH_HEAD-Fehler (#107)

Stand: .git des Vaults wird beim Start dem Server-Nutzer zugeordnet

Befund: /vault/.git auf iris-server gehörte root (3723 Einträge), der Server läuft als iris; git konnte FETCH_HEAD nicht anlegen.
Geändert: docker-entrypoint.sh chownt beim Start alles unter /vault/.git, was nicht iris gehört (find … ! -user iris -exec chown). Ein sauberes Repository kostet nur den Verzeichnis-Walk; die Arbeitsdateien des Vaults bleiben unberührt (die bisherige Regel „befüllten Vault nie rekursiv anfassen“ gilt weiter, .git gehört der Sync-Logik des Servers).
Geprüft: Deploy auf alf@iris-server per rsync + docker compose up -d --build: danach /vault/.git iris:iris, find /vault/.git ! -user iris zählt 0; POST /vault/sync/pull meldet den FETCH_HEAD-Fehler nicht mehr.
Nicht geprüft: Kein automatischer Test für das Entrypoint-Skript; Verhalten bei sehr großem .git (viele LFS-Objekte) nicht gemessen.
Offen, anderer Fehler: Der Sync dieses Vaults bleibt auf error mit „Zugangsdaten wurden abgelehnt“. Ursache: Das Vault hat ein Remote (http://forgejo:3300/iris-admin/iris-vault.git), aber der Server hat keine gespeicherten Zugangsdaten dafür (_load_credentials() liefert None; Vault enthält „Manuelle Änderung“ und einen lokalen Commit voraus). Das ist ein Konfigurationsstand von vor der Sync-Funktion, kein Codefehler; behoben wird er mit „Vault verbinden“ (Anmeldung am eigenen Git-Server) in der App. Nicht von Hand repariert.

PR #108 gemergt: fix(entrypoint): .git des Vaults dem Server-Nutzer zuordnen, FETCH_HEAD-Fehler (#107) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/108 Commits: - fix(entrypoint): .git des Vaults dem Server-Nutzer zuordnen, FETCH_HEAD-Fehler (#107) --- **Stand: `.git` des Vaults wird beim Start dem Server-Nutzer zugeordnet** - **Befund:** `/vault/.git` auf iris-server gehörte `root` (3723 Einträge), der Server läuft als `iris`; git konnte `FETCH_HEAD` nicht anlegen. - **Geändert:** `docker-entrypoint.sh` chownt beim Start alles unter `/vault/.git`, was nicht `iris` gehört (`find … ! -user iris -exec chown`). Ein sauberes Repository kostet nur den Verzeichnis-Walk; die Arbeitsdateien des Vaults bleiben unberührt (die bisherige Regel „befüllten Vault nie rekursiv anfassen“ gilt weiter, `.git` gehört der Sync-Logik des Servers). - **Geprüft:** Deploy auf `alf@iris-server` per rsync + `docker compose up -d --build`: danach `/vault/.git` `iris:iris`, `find /vault/.git ! -user iris` zählt 0; `POST /vault/sync/pull` meldet den FETCH_HEAD-Fehler nicht mehr. - **Nicht geprüft:** Kein automatischer Test für das Entrypoint-Skript; Verhalten bei sehr großem `.git` (viele LFS-Objekte) nicht gemessen. - **Offen, anderer Fehler:** Der Sync dieses Vaults bleibt auf `error` mit „Zugangsdaten wurden abgelehnt“. Ursache: Das Vault hat ein Remote (`http://forgejo:3300/iris-admin/iris-vault.git`), aber der Server hat keine gespeicherten Zugangsdaten dafür (`_load_credentials()` liefert None; Vault enthält „Manuelle Änderung“ und einen lokalen Commit voraus). Das ist ein Konfigurationsstand von vor der Sync-Funktion, kein Codefehler; behoben wird er mit „Vault verbinden“ (Anmeldung am eigenen Git-Server) in der App. Nicht von Hand repariert.

alf referenced this issue from a commit

2026-10-28 09:48:52 +00:00

fix(entrypoint): .git des Vaults dem Server-Nutzer zuordnen, FETCH_HEAD-Fehler (#107)

alf referenced this issue

2026-10-28 10:00:11 +00:00

fix(entrypoint): vault-sync-credentials.json dem Server-Nutzer zuordnen, HTTP 500 beim Bereitstellen (#107) #110

alf commented

2026-10-28 10:00:12 +00:00

Author

Owner

PR #110 gemergt: fix(entrypoint): vault-sync-credentials.json dem Server-Nutzer zuordnen, HTTP 500 beim Bereitstellen (#107)
#110

Commits:

fix(entrypoint): vault-sync-credentials.json dem Server-Nutzer zuordnen, HTTP 500 beim Bereitstellen (#107)

Nachtrag: gleiche Fehlerklasse bei vault-sync-credentials.json (HTTP 500 bei „Auf diesem Rechner bereitstellen“)

Befund: Der Nutzer bekam in der App HTTP 500 bei „Auf diesem Rechner bereitstellen“. Serverlog: PermissionError: [Errno 13] Permission denied: '/data/vault-sync-credentials.json' in vault_git_sync.configure. Die Datei gehörte root (Modus 600, angelegt 2026-10-20 10:34, zeitgleich mit dem root-eigenen .git). _load_credentials() fängt den Lesefehler ab und liefert None; deshalb meldete der Sync „Zugangsdaten wurden abgelehnt“, obwohl Zugangsdaten gespeichert waren (meine Annahme im Kommentar zu PR #108, es gäbe keine, war falsch).
Geändert: docker-entrypoint.sh nimmt vault-sync-credentials.json in die Liste der beim Start dem Server-Nutzer zugeordneten Dateien auf.
Geprüft: Deploy auf alf@iris-server: Datei danach iris:iris; GET /vault/sync/status meldet synced, ahead 0 (der Start-Sync hat den lokalen Commit hochgeladen), last_sync_at gesetzt.
Nicht geprüft: „Auf diesem Rechner bereitstellen“ selbst wurde nicht ausgelöst (der Nutzer testet es). Weitere root-eigene Dateien unter /data sind nur browser und forgejo (gehören den anderen Containern, bewusst).
Offen: Der Lesefehler wird in _load_credentials() verschluckt und als „abgelehnt“ gemeldet; ob das eine eigene Meldung bekommen soll, ist nicht entschieden.

PR #110 gemergt: fix(entrypoint): vault-sync-credentials.json dem Server-Nutzer zuordnen, HTTP 500 beim Bereitstellen (#107) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/110 Commits: - fix(entrypoint): vault-sync-credentials.json dem Server-Nutzer zuordnen, HTTP 500 beim Bereitstellen (#107) --- **Nachtrag: gleiche Fehlerklasse bei `vault-sync-credentials.json` (HTTP 500 bei „Auf diesem Rechner bereitstellen“)** - **Befund:** Der Nutzer bekam in der App HTTP 500 bei „Auf diesem Rechner bereitstellen“. Serverlog: `PermissionError: [Errno 13] Permission denied: '/data/vault-sync-credentials.json'` in `vault_git_sync.configure`. Die Datei gehörte `root` (Modus 600, angelegt 2026-10-20 10:34, zeitgleich mit dem root-eigenen `.git`). `_load_credentials()` fängt den Lesefehler ab und liefert None; deshalb meldete der Sync „Zugangsdaten wurden abgelehnt“, obwohl Zugangsdaten gespeichert waren (meine Annahme im Kommentar zu PR #108, es gäbe keine, war falsch). - **Geändert:** `docker-entrypoint.sh` nimmt `vault-sync-credentials.json` in die Liste der beim Start dem Server-Nutzer zugeordneten Dateien auf. - **Geprüft:** Deploy auf `alf@iris-server`: Datei danach `iris:iris`; `GET /vault/sync/status` meldet `synced`, `ahead 0` (der Start-Sync hat den lokalen Commit hochgeladen), `last_sync_at` gesetzt. - **Nicht geprüft:** „Auf diesem Rechner bereitstellen“ selbst wurde nicht ausgelöst (der Nutzer testet es). Weitere root-eigene Dateien unter `/data` sind nur `browser` und `forgejo` (gehören den anderen Containern, bewusst). - **Offen:** Der Lesefehler wird in `_load_credentials()` verschluckt und als „abgelehnt“ gemeldet; ob das eine eigene Meldung bekommen soll, ist nicht entschieden.

alf referenced this issue from a commit

2026-10-28 10:00:12 +00:00

fix(entrypoint): vault-sync-credentials.json dem Server-Nutzer zuordnen, HTTP 500 beim Bereitstellen (#107)

alf closed this issue

2026-10-28 13:01:38 +00:00

alf added the

typ

bug

label

2026-11-11 11:06:59 +00:00