L’utente di origine aveva configurato Syncthing per sincronizzare le foto del telefono, ma i file continuavano a finire sull’unità di sistema invece che sul disco di archiviazione. Copiare un percorso dall’app File e incollarlo direttamente in Syncthing ha fatto sì che Syncthing ricreasse la stessa struttura di directory all’interno del proprio filesystem del container.
La soluzione finale era concettuale, non un comando magico del filesystem: Docker ha un percorso sull’host e uno nel container. Syncthing deve utilizzare il percorso visibile all’interno del container, non il percorso grezzo visibile a CasaOS o ZimaOS.
Perché il percorso esterno veniva ricreato nella posizione sbagliata
Se si indica a Syncthing un percorso che non può effettivamente vedere, potrebbe creare quel percorso nel proprio filesystem scrivibile o all’interno di una posizione di configurazione mappata. L’utente di origine ha interpretato il nome della cartella come un percorso del disco esterno, mentre il container lo ha interpretato come un percorso relativo al proprio filesystem.
Individuare il punto di mount reale sull’host
La community ha utilizzato lsblk per individuare il punto di mount usato dal sistema operativo per l’unità esterna. Nell’esempio del partecipante, l’unità appariva in un percorso simile a /media/devmon/...; in seguito le unità dell’autore del post originale sono apparse sotto /mnt/Storage1 e /mnt/Storage2.
Quei percorsi di mount storici sono esempi di CasaOS/ZimaBlade e non devono essere considerati percorsi universali attuali di ZimaOS.
Mappare l’unità dell’host in Syncthing
Il partecipante ha utilizzato /DATA come percorso lato Syncthing. Una volta creata questa mappatura, Syncthing dovrebbe fare riferimento alle cartelle contenute in /DATA invece del percorso di mount originale dell’host.
L’utente aveva inizialmente inserito il percorso dell’host in Syncthing
Syncthing ha quindi restituito un errore di autorizzazione/percorso perché quel percorso interno non corrispondeva al volume mappato.
Il percorso finale funzionante era /DATA/Documents
Il partecipante ha spiegato che, dopo aver mappato l’unità host su /DATA, Syncthing dovrebbe usare:
/DATA/Documentso l’equivalente ~/Documents abbreviazione quando la home di Syncthing punta a quella posizione di dati mappata.
L’autore del post originale è tornato il giorno seguente e ha confermato che il problema era stato risolto.
Il chown ricorsivo faceva parte del flusso di lavoro della community, non della correzione principale
La discussione utilizzava inoltre un chown sull’unità esterna. Può essere appropriato su un filesystem gestito da Linux, ma modifica la proprietà sull’intera destinazione e non era un requisito definito da IceWhale.
Non modificare ricorsivamente il proprietario di un disco condiviso esistente finché non sai quali utenti e applicazioni dipendono già dai suoi permessi.
L'attuale ZimaOS semplifica la mappatura dello storage delle app
L'attuale ZimaOS documenta direttamente i percorsi host-container nelle impostazioni dell'applicazione e consiglia di impostare i dati dell'app su uno storage gestito, invece di lasciare che le applicazioni riempiano il disco di sistema.
Usa il modello attuale dei percorsi delle app di ZimaOS per i volumi Docker invece di affidarti ai vecchi percorsi di mount di CasaOS.
L'utente della fonte ha reinstallato Syncthing e ricreato la mappatura
Dopo che i primi tentativi erano rimasti confusi, l'autore originale ha eseguito una nuova installazione di Syncthing, ha riaggiunto le unità di archiviazione e ha mappato /mnt/Storage1 sull'host a /DATA all'interno del container. Questo nuovo test ha eliminato dalla diagnosi le vecchie impostazioni del container.
I soli permessi dell'host non hanno fatto funzionare il percorso errato del container
L'utente poteva collegarsi via SSH all'unità di archiviazione e creare directory, ma Syncthing continuava a non funzionare quando gli veniva chiesto di usare /mnt/Storage1/Documents internamente. Questo risultato negativo è prezioso: poter scrivere come utente dell'host non significa che il container possa vedere lo stesso spazio dei nomi.
La visibilità del container deve essere corretta prima che la configurazione dei permessi possa risolvere il problema.
L'attuale ZimaOS dovrebbe privilegiare i percorsi di archiviazione gestiti
La discussione riguarda uno ZimaBlade fornito con percorsi di archiviazione in stile CasaOS. L'attuale ZimaOS gestisce lo storage in modo diverso e offre un'interfaccia più chiara per i volumi delle applicazioni. Su un server attuale, usa il percorso di archiviazione selezionato tramite ZimaOS invece di dare per scontato /mnt/Storage1 oppure /media/devmon sarà presente.
Modifica solo i permessi effettivamente necessari all'app
Syncthing di solito richiede l'accesso in lettura e scrittura alla propria cartella di sincronizzazione. Se una cartella mappata è visibile ma non è scrivibile, controlla il proprietario e i permessi di gruppo su quella cartella specifica. Evita di modificare ricorsivamente il proprietario di un'intera unità multiuso, a meno che tu non abbia considerato ogni altro servizio che la utilizza.
FAQ sull'HDD esterno di Syncthing
Perché Syncthing ha creato il percorso dell'unità esterna all'interno del disco di sistema?
Il percorso sull'host non era quello che Syncthing poteva vedere all'interno del suo container.
Quale percorso ha funzionato dopo aver mappato l'unità su /DATA?
L'utente della fonte ha confermato /DATA/Documents ha funzionato.
La modifica ricorsiva del proprietario era l'unica soluzione?
No. The decisive understanding was the host path versus the container path.
