Gegenbuch-Container: Rechte am Bind-Mount selbst geraderuecken

Fehlerbild aus dem echten Betrieb: "mkdir: cannot create directory
'/gegenbuch/schluessel': Permission denied", Container in der
Neustart-Schleife. Ursache: Das Datenverzeichnis kommt als Bind-Mount vom Host;
der Betreiber hatte das Projekt als root geklont, der Container lief aber
direkt als UID 1000 und durfte dort nichts anlegen. Der .gitkeep-Ansatz hatte
stillschweigend angenommen, dass als normaler Benutzer geklont wird - auf einem
Server ist root der Normalfall.

Fix: Der Container startet als root, setzt /gegenbuch per chown auf den
Arbeitsbenutzer (PUID/PGID, Standard 1000) und startet sich per setpriv als
dieser neu. Die eigentliche Arbeit laeuft weiterhin unprivilegiert. Schlaegt
das chown fehl (rootless Docker), gibt es einen Hinweis mit dem passenden
Host-Befehl statt eines stummen Abbruchs.

Verifiziert mit exakt der Ausgangslage: Datenverzeichnis auf root:root gesetzt,
Container gestartet -> laeuft durch, erzeugte Dateien gehoeren 1000:1000, der
private Schluessel liegt mit 0600.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/todo.md

@@ -97,6 +97,24 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **🔧 Gegenbuch-Container: Rechte am Bind-Mount selbst geraderuecken** (2026-08-22)
+  - Fehlerbild aus dem echten Betrieb: `mkdir: cannot create directory
+    '/gegenbuch/schluessel': Permission denied`, Container in der
+    Neustart-Schleife. Ursache: Das Datenverzeichnis kommt als Bind-Mount vom
+    Host; der Betreiber hatte das Projekt als **root** geklont, der Container
+    lief aber direkt als UID 1000 und durfte dort nichts anlegen.
+    Mein `.gitkeep`-Ansatz hatte stillschweigend angenommen, dass als normaler
+    Benutzer geklont wird – auf einem Server ist root der Normalfall.
+  - Fix: Der Container startet als root, setzt `/gegenbuch` per `chown` auf den
+    Arbeitsbenutzer (`PUID`/`PGID`, Standard 1000) und startet sich per
+    `setpriv` als dieser neu. Die eigentliche Arbeit laeuft damit weiterhin
+    unprivilegiert. Schlaegt das `chown` fehl (z. B. rootless Docker), gibt es
+    einen Hinweis mit dem passenden Host-Befehl statt eines stummen Abbruchs.
+  - Verifiziert mit exakt der Ausgangslage: Datenverzeichnis auf `root:root`
+    gesetzt, Container gestartet → laeuft durch, Schluessel und Buch werden
+    angelegt, erzeugte Dateien gehoeren 1000:1000, der private Schluessel liegt
+    mit `0600`.
+
 - [x] **🔑 Gegenbuch: Dienstkonto statt Token, .env mit gueltigen Werten** (2026-08-22)
   - **Blocker gefunden und behoben:** Ich hatte ein dauerhaftes API-Token
     vorausgesetzt – das gibt es in OpenCRM gar nicht. Zugangstoken leben