Conclusion essentielle : ne déclarez pas l’image défectueuse sur la seule base de l’erreur d’installation. LiveSync auto-hébergé nécessite des identifiants CouchDB fonctionnels, un stockage persistant accessible en écriture, une initialisation, CORS et un point de terminaison accessible. Un modèle d’application en un clic peut tout de même nécessiter ces valeurs.
Définir les variables CouchDB requises
Les variables CouchDB de LiveSync actuelles du projet en amont exigent des identifiants administrateur et un nom de base de données :
COUCHDB_USER=admin
COUCHDB_PASSWORD=strong-random-password
COUCHDB_DATABASE=obsidiannotesLisez les journaux du conteneur avant de modifier des éléments au hasard
docker ps -a | grep -i couch
docker logs --tail 200 <container-name>Recherchez les variables manquantes, les erreurs de permissions, les échecs de montage de configuration, les échecs d’initialisation ou les conflits de ports.
Le stockage persistant doit être accessible en écriture
La configuration du stockage CouchDB du projet en amont indique que les répertoires de données et de configuration peuvent appartenir à l’UID 5984. Des droits de propriété incorrects peuvent empêcher le conteneur de démarrer.
Vérifier CouchDB avant Obsidian
curl -u admin:YOUR_PASSWORD http://SERVER_IP:5984/_upLe contrôle d’état CouchDB du projet en amont exige un état sain avant la configuration du plugin.
Initialiser la base de données LiveSync
Un processus CouchDB en cours d’exécution ne constitue pas toute la configuration. Exécutez le chemin d’initialisation actuel du projet en amont afin que les valeurs requises de base de données et de configuration existent avant de connecter le plugin Obsidian.
La synchronisation à distance nécessite une voie HTTPS sécurisée
Le projet en amont fournit désormais des profils Caddy, Tailscale et Cloudflare. Utilisez uniquement HTTP en local pour les tests ; la synchronisation à distance ou mobile doit utiliser une route HTTPS prise en charge.
BigBear propose actuellement un paquet Obsidian LiveSync basé sur CouchDB. Comparez la composition générée aux variables du projet en amont au lieu de supposer que l’une ou l’autre est correcte.
Le catalogue d’applications ZimaOS inclut des charges de travail liées à Obsidian, et la configuration Docker de CasaOS aide à expliquer les différences entre les paramètres du modèle et ceux de l’exécution.
ZimaBoard 2 suffit pour cette charge de travail légère de base de données ; la durabilité du stockage compte davantage que la puissance de calcul brute.
Comparez le modèle à la configuration compose actuelle du projet amont.
La configuration compose actuelle du projet amont démarre CouchDB avec les variables obligatoires de nom d’utilisateur et de mot de passe, des données persistantes et un fichier de configuration LiveSync dédié. Si un modèle communautaire diffère, identifiez la différence avant de déclarer l’image du conteneur défectueuse. L’image, le modèle compose et la configuration de l’application sont trois couches distinctes.
Ne forcez pas l’utilisateur du conteneur CouchDB sans précaution.
La configuration compose actuelle du projet amont déconseille explicitement de définir un utilisateur : valeur, car le point d’entrée de CouchDB démarre avec suffisamment de privilèges pour écrire sa configuration, puis bascule vers l’UID de CouchDB. Un modèle qui remplace ce comportement peut entraîner des échecs de permissions au démarrage.
Vérifiez le CORS une fois que le point de terminaison d’état sain fonctionne.
Un état sain /_up La réponse prouve que CouchDB fonctionne, mais pas que les clients Obsidian peuvent l’utiliser. Testez les en-têtes de réponse avec une origine Obsidian et vérifiez que la configuration de LiveSync autorise les origines de bureau et mobiles attendues.
Gardez la base de données hors de l’Internet public.
Le port 5984 de CouchDB est un point de terminaison de base de données, et non une page de partage destinée aux utilisateurs. Pour la synchronisation à distance, privilégiez les configurations HTTPS prises en charge par le projet amont — Caddy, Tailscale ou Cloudflare — plutôt qu’une simple redirection du routeur vers le port 5984.
Suivez cet ordre de dépannage
- Le conteneur reste en fonctionnement.
-
/_uprenvoie un état sain avec les identifiants. - Les données persistantes sont conservées après le redémarrage.
- L’initialisation est terminée.
- Le CORS est correctement configuré.
- Le point de terminaison HTTPS fonctionne à distance.
- L’URI, l’utilisateur, le mot de passe et la base de données du plug-in Obsidian correspondent aux valeurs du serveur.
Passer directement aux paramètres du plug-in avant d’avoir suivi les étapes 1 à 5 complique considérablement le dépannage.
FAQ
L’image BigBear est-elle vraiment défectueuse ?
La discussion source ne l’a pas démontré. Comparez d’abord sa configuration compose aux exigences actuelles de la version amont.
Pourquoi CouchDB peut-il fonctionner alors qu’Obsidian échoue ?
L’initialisation de la base de données, le CORS, les identifiants, le nom de la base de données et l’URL du point de terminaison doivent toujours correspondre.
