Conclusão principal: não considere a imagem avariada apenas com base no erro de instalação. O LiveSync autoalojado requer credenciais CouchDB funcionais, armazenamento persistente com permissões de escrita, inicialização, CORS e um ponto final acessível. Um modelo de aplicação de um clique pode continuar a exigir esses valores.
Definir as variáveis obrigatórias do CouchDB
As variáveis do CouchDB do LiveSync atuais do projeto upstream requerem credenciais de administrador e um nome de base de dados:
COUCHDB_USER=admin
COUCHDB_PASSWORD=strong-random-password
COUCHDB_DATABASE=obsidiannotesLeia os registos do contentor antes de editar aleatoriamente
docker ps -a | grep -i couch
docker logs --tail 200 <container-name>Procure variáveis em falta, erros de permissões, falhas na montagem da configuração, falhas de inicialização ou conflitos de portas.
O armazenamento persistente tem de permitir escrita
A configuração do armazenamento CouchDB do projeto upstream indica que os diretórios de dados/configuração podem pertencer ao UID 5984. As permissões de proprietário incorretas podem impedir o arranque do contentor.
Verificar o CouchDB antes do Obsidian
curl -u admin:YOUR_PASSWORD http://SERVER_IP:5984/_upO teste de integridade do CouchDB do projeto upstream espera um estado saudável antes da configuração do plugin.
Inicializar a base de dados LiveSync
Um processo CouchDB em execução não constitui toda a configuração. Execute o processo de inicialização atual do projeto upstream para que os valores necessários de base de dados/configuração existam antes de ligar o plugin Obsidian.
A sincronização remota requer uma rota HTTPS segura
O projeto upstream disponibiliza agora perfis para Caddy, Tailscale e Cloudflare. Utilize apenas HTTP simples para testes locais; a sincronização remota/móvel deve utilizar uma rota HTTPS suportada.
Atualmente, a BigBear disponibiliza um pacote Obsidian LiveSync baseado em CouchDB. Compare a composição gerada com as variáveis do projeto upstream, em vez de presumir que um dos lados está correto.
O catálogo de aplicações do ZimaOS inclui cargas de trabalho relacionadas com o Obsidian, e a configuração Docker do CasaOS ajuda a explicar as definições do modelo face às definições em execução.
O ZimaBoard 2 é suficiente para esta carga de trabalho de base de dados leve; a durabilidade do armazenamento é mais importante do que o poder de processamento bruto.
Compare o modelo com a configuração compose atual do upstream
A configuração compose atual do upstream inicia o CouchDB com as variáveis obrigatórias de nome de utilizador/palavra-passe, dados persistentes e um ficheiro de configuração dedicado do LiveSync. Se um modelo da comunidade for diferente, identifique a diferença antes de classificar a imagem do contentor como defeituosa. A imagem, o modelo compose e a configuração da aplicação são três camadas distintas.
Não force casualmente o utilizador do contentor CouchDB
A configuração compose atual do upstream avisa explicitamente contra a definição de um valor fixo utilizador: valor, porque o entrypoint do CouchDB começa com privilégios suficientes para escrever a sua configuração e depois muda para o UID do CouchDB. Um modelo que substitua este comportamento pode criar falhas de permissões durante o arranque.
Verifique o CORS depois de o endpoint de estado funcionar
Um estado saudável /_up a resposta prova que o CouchDB está em execução, mas não que os clientes Obsidian o possam utilizar. Teste os cabeçalhos da resposta com uma origem Obsidian e confirme que a configuração do LiveSync permite as origens esperadas para computador e dispositivos móveis.
Mantenha a base de dados fora da Internet aberta
A porta 5984 do CouchDB é um endpoint de base de dados, não uma página de partilha para consumidores. Para a sincronização remota, prefira os padrões HTTPS suportados pelo upstream — Caddy, Tailscale ou Cloudflare — em vez de um simples encaminhamento do router para a porta 5984.
Siga esta ordem de resolução de problemas
- O contentor mantém-se em execução.
-
/_updevolve um estado saudável com as credenciais. - Os dados persistentes sobrevivem ao reinício.
- A inicialização é concluída.
- O CORS está correto.
- O endpoint HTTPS funciona remotamente.
- O URI, o utilizador, a palavra-passe e a base de dados do plug-in Obsidian correspondem aos valores do servidor.
Avançar diretamente para as definições do plug-in antes dos passos 1–5 torna a resolução de problemas muito mais difícil.
FAQ
A imagem BigBear está definitivamente defeituosa?
A discussão de origem não provou isso. Compare primeiro a configuração com os requisitos atuais do upstream.
Porque é que o CouchDB pode funcionar enquanto o Obsidian falha?
A inicialização da base de dados, o CORS, as credenciais, o nome da base de dados e o URL do endpoint têm de continuar a corresponder.
