NAS Synology + Moments + Syncthing: lidando com os @eaDir que impedem a remoção de diretórios – Problemas e Soluções


Tenho em um dos HDDs do meu PC Desktop um diretório de fotos, o meu E:\Fotos para onde eu sempre descarrego as fotos do cartão SD da minha câmera e copio as fotos capturadas com o meu celular. Nele tenho atualmente 84.790 arquivos, totalizando 274GB (sim, eu tiro bastante fotos).

Através do Syncthing eu sincronizo esse diretório com outro que está no meu NAS Synology DS918+, já mostrado aqui no Skooter Blog, mais precisamente na pasta compartilhada \\DS918\photo\Fotos, que fica no meu /volume1/photo/Fotos. Deste modo as fotos ficam acessíveis em qualquer equipamento da rede, incluindo os TV Box Minix, já mostrados aqui também. No NAS, além da redundância com o RAID SHR, as fotos também são sincronizadas com o Google Drive, para ter uma segurança extra. Há ainda outras máquinas sincronizando e outros processos de backup no PC.

Ainda no DS918+, as fotos são todas indexadas pelo NAS e ficam disponíveis no Moments, um aplicativo similar ao Google Photos, mas que executa localmente no NAS e é acessível pelo navegador e por aplicativos para Android e iPhone. Ele também separa as fotos das pessoas pelo rosto, identifica assuntos, locais, dentre outros recursos.

O sistema da Synology salva metadados, incluindo os do próprio Moments, em subdiretórios que são criados dentro dos diretórios que tem fotos e outros arquivos de mídia. Este subdiretórios levam o nome de @eaDir.

Aí surgiu o meu primeiro problema, esses metadados estavam sendo replicados para outras máquinas, de modo que elas ficavam com vários @eaDir que para nada servem no Windows. A solução que encontrei foi colocar no \\DS918\photo\Fotos (e também nos demais diretórios de fotos de cada dispositivo) um arquivo chamado .stignore com o seguinte conteúdo:

@eaDir
.tmp.drivedownload

A primeira linha instrui o Syncthing a ignorar os @eaDir no processo de sincronização e, assim, esses diretórios não são replicados nas outras máquinas. A segunda linha não tem relação com este problema, mas serve para o Syncthing não sincronize arquivos temporários que são criados pelo Google Backup & Sync.

Mas um novo problema surgiu: eventualmente eu apago algum subdiretório em alguma reorganização das fotos, e aí o Syncthing dava erro de que não conseguia replicar a exclusão no NAS, por conta dos @eaDir que ficavam para trás nesses diretórios que, portanto, não estavam vazios para serem excluídos.

A solução foi alterar o .stignore e deixa-lo assim:

(?d)@eaDir
.tmp.drivedownload

Dessa forma o Syncthing entende que não deve deixar de fazer uma exclusão de diretório por conta de um conteúdo que está sendo ignorado. Ou seja, em diretórios excluídos ele deve ir em frente e excluir o @eaDir. Note que os @eaDir são necessários para que o Moments funcione corretamente, mas parece não haver problemas em excluir os que estão em diretórios vazios.

Por fim, surgiu um novo problema, agora o Syncthing não conseguia excluir os @eaDir porque eles são criados por um processo que executa como root. Assim, todos os @eaDir tem o root como dono. A solução que encontrei foi fazer um script que periodicamente troca o dono de todos os arquivos dentro do \\DS918\photo\Fotos passando a posse para o usuário sc-syncthing, que é o usuário que executa o processo do Syncthing. Note que isso não causa problema para o Moments, pois o grupo dos @eaDir continua sendo o root, além do root ter acesso irrestrito de qualquer forma. Mas com os @eaDir sendo propriedade do sc-syncthing, o Syncthing consegue exclui-los quando eles estão em diretórios que devem ser excluídos.

Nomeei o script que faz essa mudança como chownSyncthing e coloquei-o em /volume1/photo. Ele tem o seguinte conteúdo:

#!/bin/bash
chown -R sc-syncthing /volume1/photo/Fotos/

No painel de controle do DS918+ eu usei o Programador de Tarefas para criar uma tarefa que diariamente executa este comando como root:

bash /volume1/photo/chownSyncthing
Programador de Tarefas

Programador de Tarefas

Agora sim, tudo funcionando perfeitamente. Eventualmente pode até ocorrer algum erro no Syncthing, caso algum @eaDir precise ser excluído novamente logo após ter sido criado, sem que o script tenha tido chance de agir, mas como ele vai ficar tentando novamente, em no máximo 24 horas o problema se resolve.

Compartilhe o artigo com seus amigos se você gostou 😉 . O Skooter Blog precisa de sua ajuda na divulgação para continuar existindo.

Atualização (29/03/2022):

Recentemente notei que alguns diretórios @eaDir ainda estavam ficando para trás porque o Syncthing não conseguia excluí-los. O problema era de permissão. Por algum motivo além da minha compreensão há arquivos dentro desses diretórios que nem o dono tem permissão de excluir.

Para resolver o problema atualizei o meu script para incluir também um chmod para deixar o novo dono dos arquivos (sc-syncthing) com permissões de leitura, escrita e execução. Aproveitei também para fazer o mesmo no meu diretório de vídeos, que tinha os mesmos problemas. Renomeei o script para chownSyncthing.sh para não precisar ficar chamando explicitamente o bash para executa-lo. Por fim, movi o script para um diretório scripts dentro do meu home, visto que agora ele também atua sobre os vídeos e não fazia mais sentido deixa-lo dentro do diretório photo. O novo script ficou assim:

#!/bin/bash
chown -R sc-syncthing /volume1/photo/Fotos/
chmod -R u+rwx /volume1/photo/Fotos/
chown -R sc-syncthing /volume1/video/Videos/
chmod -R u+rwx /volume1/video/Videos/
5 1 voto
Article Rating
(Visitado 23 vezes, 1 visitas hoje)

Link permanente para este artigo: https://www.skooterblog.com/2021/04/04/nas-synology-moments-syncthing-lidando-com-os-eadir-que-impedem-a-remocao-de-diretorios-problemas-e-solucoes/

Inscrever
Notificar sobre
guest

0 Comentários
Inline Feedbacks
Ver todos os comentários
0
Gostaríamos de saber o que você pensa, deixe seu comentáriox