Conclusione principale: probabilmente non si tratta di un problema da risolvere continuando a modificare chmod finché Syncthing non funziona. L’indicazione più forte è che la cartella funziona quando si trova in un percorso direttamente visibile a Syncthing, ma non quando un collegamento simbolico attraversa un’altra unità fisica. In CasaOS, questo fa pensare innanzitutto ai percorsi montati nel container e poi ai permessi UID/GID.
“Ho già configurato i permessi fino in fondo… funziona quando uso come destinazione /DATA/AppData/, ma non quando il collegamento punta a un’altra unità fisica.” Questo risultato del test è più utile dell’errore di autorizzazione originale, perché circoscrive il problema al percorso di archiviazione.
Perché il collegamento simbolico è la prima cosa da mettere in discussione
Syncthing non tratta un collegamento simbolico come “vai alla destinazione e sincronizza tutto ciò che contiene”. Il comportamento documentato di collegamenti simbolici di Syncthing prevede che i collegamenti simbolici possano essere sincronizzati, ma non vengono mai seguiti. Inoltre, la configurazione della cartella si aspetta un percorso reale specifico del dispositivo: il Percorso della cartella Syncthing è il percorso fisico della cartella sul disco rigido.
Questo rende sospetto un percorso come il seguente:
/DATA/Documents/Syncthing/SyncFiles → collegamento simbolico → /some/other/physical/driveSe Syncthing è in esecuzione in Docker, l’host può risolvere quel collegamento, mentre il container potrebbe non riuscire a vedere affatto la destinazione.
L’app Syncthing di CasaOS spiega perché una seconda unità può scomparire
La definizione ufficiale di Syncthing nell’App Store di CasaOS è particolarmente utile in questo caso. Il suo file compose monta tramite bind due percorsi dell’host nel container:
/DATA/AppData/$AppID/config → /config
/DATA → /DATAPuoi verificare l’effettiva mappatura dei volumi nel file compose di Syncthing per CasaOS.
Ciò significa che una destinazione fisicamente disponibile nell’albero /DATA dell’host dovrebbe essere visibile anche sotto /DATA all’interno del container Syncthing. Tuttavia, se il collegamento simbolico punta infine a un mount dell’host esterno a quell’albero, il container necessita di un bind mount separato per la destinazione reale. Con i bind mount Docker, le directory dell’host devono essere montate esplicitamente nel container.
Usa questo test per distinguere un problema di percorso da un problema di autorizzazioni
Esegui i controlli in quest'ordine. Non iniziare con un altro chmod ricorsivo.
1. Risolvi il percorso reale sull'host CasaOS
readlink -f "/DATA/Documents/Syncthing/SyncFiles"Se il comando restituisce un percorso al di fuori di /DATA, hai trovato un indizio importante.
2. Chiedi al container Syncthing se riesce a vedere la stessa destinazione
docker exec syncthing ls -ld "/DATA/Documents/Syncthing/SyncFiles"Poi verifica la destinazione risolta, se dovrebbe esistere all'interno del container. Se l'host riesce a elencarla ma il container no, le autorizzazioni non sono ancora il problema principale; il percorso manca nello spazio dei nomi del container.
3. Ispeziona i montaggi effettivi del container
docker inspect syncthingGuarda la Montaggi sezione. Dovresti riuscire a identificare la sorgente sull'host e la destinazione nel container dell'unità che intendi sincronizzare.
La soluzione più pulita: esegui il bind mount dell'unità reale, quindi usa quel percorso nel container
Se l'unità esterna si trova al di fuori di /DATA, esponendola direttamente a Syncthing invece di nasconderla dietro un collegamento simbolico. Concettualmente, la voce compose è simile a:
volumes:
- type: bind
source: /real/host/path/to/external-drive
target: /sync-drivePoi configura il percorso della cartella Syncthing in modo esplicito, ad esempio:
/sync-drive/Dev FilesQuesto non è un percorso magico; scegli una destinazione coerente con la configurazione compose. L'importante è che il container riceva la directory reale dell'host come volume montato.
L'immagine Syncthing upstream di LinuxServer usa lo stesso modello e documenta mappature separate dei dati dall'host al container, come /path/to/data1:/data1 e /path/to/data2:/data2. La sua mappatura PUID/PGID di Syncthing spiega inoltre come l'identità del container debba corrispondere alla proprietà del volume sull'host.
Solo dopo aver verificato il montaggio dovresti correggere proprietà e autorizzazioni
La risoluzione dei problemi originale includeva un suggerimento del tipo:
sudo chmod -R 770 /path/to/folder770 possono essere appropriati in alcune configurazioni, ma sono utili solo se Syncthing viene effettivamente eseguito da un utente o gruppo proprietario di quella directory, oppure appartenente al gruppo che la possiede. L'app CasaOS passa PUID e PGID nell'immagine LinuxServer. La documentazione di LinuxServer indica che la proprietà dei volumi sull'host deve corrispondere al PUID/PGID configurato.
Controlla gli ID invece di dare per scontato il nome utente casaos è sufficiente:
docker exec syncthing id
stat -c '%u:%g %a %n' /real/host/path/to/external-driveSe UID/GID numerici non corrispondono, modifica intenzionalmente la proprietà o l’appartenenza al gruppo. Evita chmod -R 777; nasconde il vero problema e indebolisce il controllo degli accessi.
Cosa indica realmente l’errore «file esiste»
Il messaggio:
mkdir /DATA/Documents/Syncthing/SyncFiles: file esistenon dimostra che la directory finale File di sviluppo la directory è il problema. Syncthing fallisce durante la preparazione della radice della cartella. Quando un percorso principale è un link simbolico o si risolve in modo diverso all’interno del container, l’applicazione può incontrare un oggetto del filesystem dove si aspettava un normale percorso di directory.
La diagnosi più rapida, quindi, non consiste nell’eliminare e ricreare la stessa directory. Consiste nel confrontare:
- il percorso risolto sull’host;
- il percorso visibile all’interno del container;
- i bind mount del container;
- il PUID/PGID numerico con la proprietà della destinazione.
Per una configurazione di base pulita, la configurazione di Syncthing su CasaOS mostra un normale flusso di sincronizzazione con lo stesso percorso prima della personalizzazione per più unità. La piattaforma di app ZimaOS è utile per confrontare strumenti alternativi di backup o sincronizzazione dei file. Se l’obiettivo finale è consolidare diverse unità fisiche invece di collegarle tramite link simbolici, ZimaCube 2 è l’opzione hardware incentrata sull’archiviazione.
Domande frequenti
Dovrei risolvere il problema cambiando il proprietario da root a casaos?
Non da solo. La proprietà conta solo dopo che il container può vedere il percorso di destinazione reale. Verifica prima il bind mount e i valori numerici di PUID/PGID.
Perché un percorso diretto funziona mentre il link simbolico a un’altra unità dà errore?
Un percorso diretto sotto una directory montata nel container esiste in entrambi i filesystem. Un link simbolico può risolversi in una posizione dell’host che non è mai stata montata nel container, lasciando Syncthing con un percorso che non può attraversare.
Syncthing segue i link simbolici per sincronizzare la directory di destinazione?
No. La documentazione di Syncthing indica che i link simbolici non vengono mai seguiti. Usa un percorso di una cartella reale visibile al processo Syncthing.
Cosa dovrei modificare per prima cosa?
Risolvi il link simbolico, controlla i mount del container Syncthing e monta in bind la directory effettiva dell’unità esterna. Poi verifica PUID/PGID e i permessi.
