Il problema originale era più pericoloso della semplice scomparsa di un percorso. Dopo il riavvio, SABnzbd poteva avviarsi prima che la condivisione SMB Synology fosse effettivamente montata. Il container continuava a vedere una directory nel percorso host previsto, quindi un download poteva completarsi e sembrare spostato correttamente, mentre in realtà finiva nello spazio di archiviazione locale di ZimaOS invece che sul NAS remoto.
La community alla fine ha realizzato una soluzione CIFS/fstab manuale funzionante e l’autore del post originale ha confermato che il mount persisteva dopo il riavvio. Tuttavia, ha anche dimostrato il rischio: una voce fstab non valida poteva impedire il normale avvio e un punto di mount contenente uno spazio non preceduto da escape rompeva la configurazione. Considera questi comandi come procedure di amministrazione della community confermate dalla fonte, non come la procedura ufficiale aggiornata di ZimaOS per l’archiviazione di rete.
Il problema principale era il momento del mount
Il percorso originale era simile a:
/media/192.168.2.125/MoviesDopo il riavvio, il mount SMB non era pronto quando SABnzbd si avviava. Aggiungere nuovamente lo stesso volume dopo che il sistema si era stabilizzato lo faceva funzionare di nuovo, confermando fortemente che si trattava di un problema di temporizzazione o ordine di avvio, non di un ID del mount variabile.
Un mount remoto mancante può trasformarsi in una trappola costituita da una directory locale
Se Docker riceve un percorso di directory host che esiste localmente mentre il filesystem remoto è assente, l’applicazione può scrivere in quella directory locale. Il log può comunque indicare che il file è stato spostato in /movies, mentre sul Synology non compare nulla.
Prima di avviare download di grandi dimensioni, verifica che il filesystem remoto previsto sia effettivamente montato, invece di limitarti a controllare che esista la directory del punto di mount.
La community ha spostato il mount in un percorso /DATA stabile
La configurazione proposta consisteva nel montare la condivisione SMB in un percorso locale stabile, ad esempio:
/DATA/Media/Moviese quindi mappare quel percorso host stabile in SABnzbd. In questo modo il percorso del container rimane prevedibile, mentre il filesystem remoto viene gestito a livello host.
L’utente della fonte ha confermato che /etc/fstab persisteva dopo il riavvio
L’esempio della community utilizzava opzioni CIFS tra cui _netdev, una versione specifica del protocollo SMB e valori UID/GID/modalità. L’utente ha dichiarato che la voce fstab persisteva e funzionava dopo il riavvio.
Non copiare le credenziali direttamente in una configurazione leggibile da tutti senza valutare l’uso di un file delle credenziali protetto.
nofail è diventato fondamentale dopo che una voce errata ha bloccato l’avvio
L’utente della fonte ha scoperto che un mount non valido o non disponibile poteva interferire con l’avvio. La risposta consigliava nofail, così ZimaOS potesse continuare ad avviarsi se il NAS remoto non era disponibile.
Anche _netdev indica al sistema di mount che si tratta di una risorsa dipendente dalla rete.
Gli spazi nei punti di mount devono essere gestiti correttamente
Una seconda voce fstab non funzionava perché il punto di mount includeva TV Shows. In fstab, gli spazi separano i campi, quindi uno spazio deve essere preceduto da escape nel modo appropriato oppure si può usare una directory più semplice, come TV_Shows.
In seguito l’OP ha usato con successo una cartella separata senza spazi.
Esegui sempre il test con mount -a prima di riavviare
Il passaggio più sicuro indicato dalla fonte era:
sudo mount -aSe restituisce un errore, correggi la sintassi o il percorso in fstab prima di riavviare. Verifica inoltre che il filesystem montato contenga i file remoti previsti.
Preferisci l’Archiviazione di rete di ZimaOS aggiornata quando soddisfa il caso d’uso
Le versioni attuali di ZimaOS possono connettersi allo spazio di archiviazione SMB/LAN tramite i flussi di lavoro File/Archiviazione di rete. Usa innanzitutto l’interfaccia gestita quando offre il comportamento di persistenza e ordine di avvio richiesto dalla tua applicazione.
Consulta l’attuale procedura di connessione SMB Synology.
Un container realmente robusto non dovrebbe scrivere finché il mount remoto non è stato verificato
Anche con fstab, un NAS di rete può risultare offline in un secondo momento. Per pipeline importanti di download o importazione, aggiungi un controllo di salute o di avvio, oppure una procedura operativa che confermi che la destinazione remota sia montata prima che SABnzbd elabori i lavori.
Domande frequenti sul mount SMB di SABnzbd
La fonte ha dimostrato che l’ID del mount SMB cambiava dopo il riavvio?
No. Le prove indicavano un problema di temporizzazione del mount.
fstab persisteva per l’utente della fonte?
Sì, ma le voci malformate o non disponibili causavano anche problemi di avvio finché non venivano corrette.
Perché un download può sembrare completato correttamente mentre sul Synology non compare alcun file?
L’applicazione può scrivere nella directory locale del punto di mount quando il filesystem SMB remoto non è effettivamente montato.
