Conclusione fondamentale: se Syncthing riesce a leggere una cartella ma non a propagare eliminazioni o modifiche, verifica i permessi di scrittura dall'interno del container Syncthing. Un bind mount leggibile non è automaticamente scrivibile.
Controlla prima la modalità della cartella
Una cartella bidirezionale dovrebbe usare le modalità delle cartelle di Syncthing appropriate per ricevere modifiche. Send Only non si comporterà come Send & Receive.
Dimostra che il container può scrivere
docker exec -it syncthing sh
touch /DATA/Gallery/.write-test
rm /DATA/Gallery/.write-testSe uno dei due comandi non riesce, correggi le autorizzazioni dello storage prima di modificare le impostazioni di Syncthing.
Fai corrispondere PUID e PGID
Il compose ufficiale di Syncthing per CasaOS passa PUID/PGID e monta /DATA nel container. LinuxServer spiega la proprietà PUID/PGID per i volumi host.
docker exec syncthing id
stat -c '%u:%g %a %n' /DATA/GalleryConfronta gli ID numerici. Cambiare la proprietà a un nome utente non basta se il container viene eseguito con un UID/GID diverso.
Le eliminazioni richiedono autorizzazioni sulla directory principale
Per rimuovere o rinominare un file sono necessarie le autorizzazioni di scrittura ed esecuzione sulla directory principale. Questo spiega perché la lettura/sincronizzazione può sembrare parzialmente funzionante mentre le eliminazioni remote non riescono.
Confronta una cartella funzionante
Confronta docker inspect syncthing mount, stat modalità/UID/GID, ACL con getfacl, stato di sola lettura del filesystem e pattern da ignorare. Non saltare a chmod 777.
La configurazione di CasaOS Syncthing offre una base di riferimento pulita. La piattaforma per app ZimaOS aiuta a confrontare le alternative, mentre ZimaCube 2 è adatto ai carichi di lavoro di archiviazione su più unità.
Controlla le ACL quando i bit della modalità Unix sembrano corretti
Tradizionali chmod l’output può sembrare corretto anche se un’ACL modifica ancora i permessi effettivi. Confronta una directory funzionante con una che presenta problemi:
getfacl /DATA/Gallery
getfacl /DATA/DocumentsSe un percorso contiene voci ACL aggiuntive, correggile intenzionalmente invece di aprire ricorsivamente i permessi ovunque.
Verifica se il filesystem è di sola lettura
findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /DATA/GalleryUn disco montato ro, gli errori del filesystem o un’unità esterna degradata possono produrre lo stesso sintomo “può leggere ma non può modificare”. Se il montaggio è di sola lettura, modificare le impostazioni di Syncthing non può risolvere il problema.
Leggi l’errore di Syncthing alla base di “non sincronizzato”
Apri l’interfaccia web di Syncthing e controlla l’errore della cartella, quindi confronta i log del container:
docker logs --tail 200 syncthingCerca permesso negato, operazione non consentita, errori di percorso non trovato o operazioni di ridenominazione/eliminazione non riuscite. “Non sincronizzato” è uno stato; il log di solito contiene la causa filesystem di livello inferiore.
Non usare Ignore Permissions come soluzione universale
Ignorare i metadati dei permessi può essere utile quando due filesystem rappresentano i bit della modalità Unix in modo diverso, ma non concede al processo i permessi di scrittura. Se il container non può eliminare un file di test, modificare il comportamento di Syncthing relativo ai metadati dei permessi non renderà scrivibile la directory sull’host.
Esegui un test di scrittura controllato
Crea una piccola directory temporanea, collegala a Syncthing e verifica le operazioni di creazione → modifica → ridenominazione → eliminazione da entrambi i dispositivi. Quando funziona, applica lo stesso schema di proprietà e montaggio alla cartella reale. In questo modo separi il comportamento della sincronizzazione dalla complessa struttura di directory esistente.
Domande frequenti
Perché Syncthing può aggiungere file ma non eliminarli?
I permessi della directory padre possono consentire la lettura, ma impedire le operazioni di ridenominazione o eliminazione.
Devo usare chmod 777?
No. Prima dimostra il percorso che fallisce e l’identità del container.
