O utilizador de origem tinha o Syncthing a funcionar para sincronizar fotografias do telemóvel, mas os ficheiros continuavam a ser guardados na unidade do sistema em vez do disco de armazenamento. Copiar um caminho da aplicação Ficheiros e colá-lo diretamente no Syncthing fez com que o Syncthing recriasse a mesma árvore de diretórios dentro do seu próprio sistema de ficheiros do contentor.
A solução final foi conceptual, e não um comando mágico do sistema de ficheiros: o Docker tem um caminho no anfitrião e um caminho no contentor. O Syncthing deve utilizar o caminho visível dentro do contentor, e não o caminho bruto visível no CasaOS ou no ZimaOS.
Porque é que o caminho externo estava a ser recriado no local errado
Se for indicado ao Syncthing um caminho que ele não consegue realmente ver, poderá criar esse caminho no seu próprio sistema de ficheiros com capacidade de escrita ou dentro de uma localização de configuração mapeada. O utilizador de origem interpretou o nome da pasta como um caminho para o disco externo, enquanto o contentor o interpretou como um caminho relativo ao seu próprio sistema de ficheiros.
Encontrar o ponto de montagem real no anfitrião
A comunidade utilizou lsblk para identificar onde o sistema operativo montou a unidade externa. No exemplo do autor da resposta, a unidade apareceu num caminho semelhante a /media/devmon/...; as unidades do autor original apareceram mais tarde em /mnt/Storage1 e /mnt/Storage2.
Esses caminhos de montagem históricos exatos são exemplos do CasaOS/ZimaBlade e não devem ser tratados como caminhos universais atuais do ZimaOS.
Mapear a unidade do anfitrião para o Syncthing
O autor da resposta utilizou /DATA como caminho do lado do Syncthing. Depois de esse mapeamento existir, o Syncthing deve referir-se às pastas dentro de /DATA em vez do caminho de montagem original do anfitrião.
O utilizador introduziu inicialmente o caminho do anfitrião no Syncthing
O Syncthing devolveu então um erro de permissões/caminho, porque esse caminho interno não correspondia ao volume mapeado.
O caminho final que funcionou foi /DATA/Documents
O autor da resposta explicou que, depois de mapear a unidade do anfitrião para /DATA, o Syncthing deve utilizar:
/DATA/Documentsou o equivalente ~/Documents atalho quando a pasta inicial do Syncthing aponta para essa localização de dados mapeada.
O autor original voltou no dia seguinte e confirmou que funcionava.
O chown recursivo fazia parte do procedimento da comunidade, não da correção principal
A discussão também utilizou um chown na unidade externa. Isso pode ser apropriado num sistema de ficheiros gerido pelo Linux, mas altera a propriedade em todo o destino e não era um requisito definido pela IceWhale.
Não altere recursivamente a propriedade de um disco partilhado existente antes de saber que utilizadores e aplicações já dependem das respetivas permissões.
O ZimaOS atual facilita o mapeamento do armazenamento das aplicações
O ZimaOS atual documenta diretamente os caminhos do anfitrião e do contentor nas definições da aplicação e recomenda definir os dados da aplicação num armazenamento gerido, em vez de deixar que as aplicações encham o disco do sistema.
Utilize o modelo atual de caminhos de aplicações do ZimaOS para volumes Docker em vez de depender das antigas localizações de montagem do CasaOS.
O utilizador de origem reinstalou o Syncthing e recriou o mapeamento
Depois de as primeiras tentativas continuarem confusas, o autor original da publicação fez uma instalação nova do Syncthing, voltou a adicionar as unidades de armazenamento e mapeou /mnt/Storage1 no anfitrião para /DATA dentro do contentor. Este novo teste limpo removeu as definições antigas do contentor da análise.
A permissão do anfitrião, por si só, não fez funcionar o caminho errado dentro do contentor
O utilizador conseguiu ligar-se por SSH à unidade de armazenamento e criar diretórios, mas o Syncthing continuava a falhar quando lhe era pedido para utilizar /mnt/Storage1/Documents internamente. Esse resultado negativo é valioso: conseguir escrever como utilizador do anfitrião não significa que o contentor consiga ver o mesmo espaço de nomes.
A visibilidade dentro do contentor tem de estar correta antes de o ajuste das permissões poder resolver alguma coisa.
O ZimaOS atual deve dar preferência a caminhos de armazenamento geridos
O tópico é de um ZimaBlade fornecido com caminhos de armazenamento ao estilo do CasaOS. O ZimaOS atual tem um comportamento de armazenamento gerido diferente e uma interface mais clara para volumes de aplicações. Num servidor atual, utilize o caminho de armazenamento selecionado através do ZimaOS, em vez de assumir /mnt/Storage1 ou /media/devmon existirá.
Altere apenas as permissões de que a aplicação realmente precisa
Normalmente, o Syncthing precisa de acesso de leitura e escrita à respetiva pasta de sincronização. Se uma pasta mapeada estiver visível mas não permitir escrita, verifique a propriedade e as permissões de grupo dessa pasta específica. Evite alterar recursivamente a propriedade de uma unidade inteira com várias finalidades, a menos que tenha considerado todos os outros serviços que utilizam essa unidade.
Perguntas frequentes sobre discos rígidos externos do Syncthing
Porque é que o Syncthing criou o caminho da unidade externa dentro do disco do sistema?
O caminho do anfitrião não era o caminho que o Syncthing conseguia ver dentro do respetivo contentor.
Que caminho funcionou depois de a unidade ser mapeada para /DATA?
O utilizador de origem confirmou /DATA/Documents funcionou.
A alteração recursiva do proprietário foi a única solução?
Não. A distinção decisiva foi entre o caminho do anfitrião e o caminho do contentor.
