Conclusione fondamentale: non dichiarare che l'immagine è difettosa basandoti solo sull'errore di installazione. LiveSync auto-ospitato richiede credenziali CouchDB funzionanti, archiviazione persistente scrivibile, inizializzazione, CORS e un endpoint raggiungibile. Anche un modello di app con installazione in un clic può richiedere questi valori.
Imposta le variabili CouchDB richieste
Le variabili CouchDB upstream di LiveSync attuali richiedono credenziali di amministratore e un nome di database:
COUCHDB_USER=admin
COUCHDB_PASSWORD=strong-random-password
COUCHDB_DATABASE=obsidiannotesLeggi i log del container prima di modificare elementi a caso
docker ps -a | grep -i couch
docker logs --tail 200 <container-name>Cerca variabili mancanti, errori di autorizzazione, problemi di montaggio della configurazione, errori di inizializzazione o conflitti di porta.
L'archiviazione persistente deve essere scrivibile
La configurazione dell'archiviazione CouchDB upstream indica che le directory dei dati e della configurazione possono appartenere all'UID 5984. Una proprietà errata può impedire l'avvio del container.
Verifica CouchDB prima di Obsidian
curl -u admin:YOUR_PASSWORD http://SERVER_IP:5984/_upL'controllo dello stato di salute di CouchDB upstream richiede uno stato di salute corretto prima della configurazione del plugin.
Inizializza il database LiveSync
Un processo CouchDB in esecuzione non costituisce l'intera configurazione. Esegui l'attuale procedura di inizializzazione upstream, così i valori di database/configurazione richiesti esistono prima di connettere il plugin Obsidian.
La sincronizzazione remota richiede un percorso HTTPS sicuro
Il progetto upstream ora fornisce profili Caddy, Tailscale e Cloudflare. Usa HTTP semplice solo per i test locali; la sincronizzazione remota/mobile dovrebbe usare un percorso HTTPS supportato.
BigBear attualmente elenca un pacchetto Obsidian LiveSync basato su CouchDB. Confronta il compose generato con le variabili upstream, invece di presumere che una delle due parti sia corretta.
Il catalogo delle app di ZimaOS include carichi di lavoro correlati a Obsidian e la configurazione Docker di CasaOS aiuta a spiegare le differenze tra le impostazioni del template e quelle di runtime.
ZimaBoard 2 è sufficiente per questo carico di lavoro leggero del database; la durata del supporto di archiviazione è più importante della potenza di calcolo grezza.
Confronta il template con il compose upstream attuale
Il compose upstream attuale avvia CouchDB con le variabili obbligatorie per nome utente e password, dati persistenti e un file di configurazione dedicato per LiveSync. Se un template della community differisce, individua la differenza prima di definire difettosa l'immagine del container. L'immagine, il template compose e la configurazione dell'applicazione sono tre livelli distinti.
Non forzare alla leggera l'utente del container CouchDB
Il compose upstream attuale avverte esplicitamente di non impostare un utente: valore perché l'entrypoint di CouchDB viene avviato con privilegi sufficienti per scrivere la propria configurazione, quindi passa all'UID di CouchDB. Un template che sovrascrive questo comportamento può creare errori di autorizzazione durante l'avvio.
Controlla il CORS dopo che l'endpoint di health funziona
Uno stato healthy /_up La risposta dimostra che CouchDB è in esecuzione, non che i client Obsidian possano utilizzarlo. Verifica le intestazioni della risposta con un'origine Obsidian e conferma che la configurazione di LiveSync consenta le origini desktop/mobile previste.
Tieni il database fuori da Internet aperto
La porta 5984 di CouchDB è un endpoint del database, non una pagina di condivisione per gli utenti. Per la sincronizzazione remota, preferisci i pattern HTTPS supportati upstream — Caddy, Tailscale o Cloudflare — invece di un semplice inoltro del router alla porta 5984.
Segui questo ordine per la risoluzione dei problemi
- Il container rimane in esecuzione.
-
/_uprestituisce uno stato healthy con le credenziali. - I dati persistenti sopravvivono al riavvio.
- L'inizializzazione è completata.
- Il CORS è configurato correttamente.
- L'endpoint HTTPS funziona da remoto.
- L'URI, l'utente, la password e il database del plugin Obsidian corrispondono ai valori del server.
Passare direttamente alle impostazioni del plugin prima dei passaggi 1–5 rende la risoluzione dei problemi molto più difficile.
FAQ
L'immagine BigBear è sicuramente difettosa?
La discussione di origine non lo ha dimostrato. Confronta prima il relativo compose con i requisiti upstream attuali.
Perché CouchDB può funzionare mentre Obsidian non funziona?
L'inizializzazione del database, il CORS, le credenziali, il nome del database e l'URL dell'endpoint devono comunque corrispondere.
