Obsidian-LiveSync-CouchDB schlägt auf CasaOS fehl: Was ist zu konfigurieren?

Wichtige Schlussfolgerung: Bezeichnen Sie das Image nicht allein aufgrund des Installationsfehlers als fehlerhaft. Selbst gehostetes LiveSync benötigt funktionierende CouchDB-Anmeldedaten, beschreibbaren persistenten Speicher, eine Initialisierung, CORS und einen erreichbaren Endpunkt. Auch eine One-Click-App-Vorlage kann diese Werte erfordern.

Erforderliche CouchDB-Variablen festlegen

Die aktuellen Upstream-LiveSync-CouchDB-Variablen erfordern Administratoranmeldedaten und einen Datenbanknamen:

COUCHDB_USER=admin
COUCHDB_PASSWORD=strong-random-password
COUCHDB_DATABASE=obsidiannotes

Lesen Sie die Containerprotokolle, bevor Sie wahllos Änderungen vornehmen

docker ps -a | grep -i couch
docker logs --tail 200 <container-name>

Achten Sie auf fehlende Variablen, Berechtigungsfehler, Fehler beim Einbinden der Konfiguration, Initialisierungsfehler oder Portkonflikte.

Der persistente Speicher muss beschreibbar sein

Das Upstream-CouchDB-Speicher-Setup weist darauf hin, dass Daten- und Konfigurationsverzeichnisse dem Benutzer mit der UID 5984 gehören können. Falsche Besitzrechte können den Container am Start hindern.

CouchDB vor Obsidian überprüfen

curl -u admin:YOUR_PASSWORD http://SERVER_IP:5984/_up

Der Upstream-CouchDB-Health-Check erwartet vor der Plugin-Konfiguration einen fehlerfreien Status.

LiveSync-Datenbank initialisieren

Ein laufender CouchDB-Prozess allein reicht nicht aus. Führen Sie den aktuellen Upstream-Initialisierungspfad aus, damit die erforderlichen Datenbank- und Konfigurationswerte vorhanden sind, bevor Sie das Obsidian-Plugin verbinden.

Für die Synchronisierung aus der Ferne wird ein sicherer HTTPS-Pfad benötigt

Das Upstream-Projekt bietet jetzt Profile für Caddy, Tailscale und Cloudflare. Verwenden Sie für lokale Tests ausschließlich HTTP; für die Synchronisierung aus der Ferne oder von Mobilgeräten sollte eine unterstützte HTTPS-Route verwendet werden.

BigBear listet derzeit ein Obsidian-LiveSync-Paket auf Basis von CouchDB. Vergleichen Sie die generierte Compose-Konfiguration mit den Upstream-Variablen, anstatt davon auszugehen, dass eine der beiden Seiten korrekt ist.

Der ZimaOS-App-Katalog umfasst Obsidian-bezogene Workloads, und die CasaOS-Docker-Konfiguration hilft dabei, die Einstellungen von Vorlage und Laufzeit zu erklären.

ZimaBoard 2 ist für diese leichtgewichtige Datenbank-Workload ausreichend; die Speicherdauerhaftigkeit ist wichtiger als die reine Rechenleistung.

Vergleiche die Vorlage mit der aktuellen Upstream-Compose-Datei.

Die aktuelle Upstream-Compose-Datei startet CouchDB mit den erforderlichen Variablen für Benutzername und Passwort, persistenten Daten und einer dedizierten LiveSync-Konfigurationsdatei. Wenn eine Community-Vorlage davon abweicht, ermittle zuerst den Unterschied, bevor du das Container-Image als fehlerhaft bezeichnest. Image, Compose-Vorlage und Anwendungskonfiguration sind drei getrennte Ebenen.

Erzwinge nicht ohne Weiteres den Benutzer des CouchDB-Containers.

Die aktuelle Upstream-Compose-Datei warnt ausdrücklich davor, einen festen Benutzer: Wert, da der CouchDB-Einstiegspunkt mit ausreichenden Berechtigungen startet, um seine Konfiguration zu schreiben, und anschließend auf die CouchDB-UID wechselt. Eine Vorlage, die dieses Verhalten überschreibt, kann beim Start Berechtigungsfehler verursachen.

Prüfe CORS, nachdem der Health-Endpunkt funktioniert.

Ein „healthy“ /_up Die Antwort beweist, dass CouchDB läuft, nicht aber, dass Obsidian-Clients es verwenden können. Teste die Antwort-Header mit einem Obsidian-Origin und bestätige, dass die LiveSync-Konfiguration die erwarteten Desktop-/Mobil-Origin-URLs zulässt.

Halte die Datenbank vom offenen Internet fern.

Der CouchDB-Port 5984 ist ein Datenbankendpunkt, keine Freigabeseite für Verbraucher. Für die Fernsynchronisierung solltest du die vom Upstream unterstützten HTTPS-Muster – Caddy, Tailscale oder Cloudflare – gegenüber einer direkten Routerweiterleitung an Port 5984 bevorzugen.

Halte dich an diese Reihenfolge bei der Fehlersuche.

1. Der Container bleibt aktiv.
2. /_up gibt bei Verwendung der Zugangsdaten „healthy“ zurück.
3. Persistente Daten bleiben nach einem Neustart erhalten.
4. Die Initialisierung wird abgeschlossen.
5. CORS ist korrekt konfiguriert.
6. Der HTTPS-Endpunkt funktioniert aus der Ferne.
7. Die URI, der Benutzername, das Passwort und die Datenbank des Obsidian-Plugins stimmen mit den Serverwerten überein.

Wenn du direkt zu den Plugin-Einstellungen springst und die Schritte 1–5 überspringst, wird die Fehlersuche erheblich schwieriger.

FAQ

Ist das BigBear-Image definitiv fehlerhaft?

Die Ausgangsdiskussion hat das nicht bewiesen. Vergleiche zuerst die Compose-Datei mit den aktuellen Upstream-Anforderungen.

Warum kann CouchDB laufen, während Obsidian fehlschlägt?

Datenbankinitialisierung, CORS, Zugangsdaten, Datenbankname und Endpunkt-URL müssen weiterhin übereinstimmen.