La configurazione di origine utilizzava ZimaOS come server applicativo, mantenendo tutti i contenuti multimediali su un NAS Unraid esistente. Plex, Emby e OpenWebUI venivano eseguiti su ZimaOS e inizialmente accedevano correttamente ai dati remoti. Dopo circa una settimana, e nuovamente dopo un riavvio, la condivisione di rete è scomparsa dall’ambiente applicativo. Ricollegarla in Files e riavviare le app ha ripristinato l’accesso.
Questo mette in evidenza un limite architetturale importante per le implementazioni con “nodo di calcolo + NAS separato”: una posizione di rete visibile nell’app Files non equivale automaticamente a un montaggio host persistente da cui ogni container Docker possa dipendere anche dopo riavvii e riconnessioni.
Le app hanno perso i contenuti perché la condivisione remota è scomparsa
Non sono stati segnalati problemi con i database di Plex ed Emby. Semplicemente, hanno perso i percorsi che puntavano ai dati su Unraid. Quando l’utente ha aggiunto nuovamente la condivisione, le applicazioni hanno iniziato a ricostruire i database o a eseguire nuovamente la scansione.
Questo fa pensare a un problema di raggiungibilità dello spazio di archiviazione, non a un’installazione di Plex o Emby danneggiata.
L’accesso da Files e l’accesso ai volumi Docker sono livelli diversi
Files di ZimaOS può connettersi allo spazio di archiviazione della LAN tramite SMB. Questa connessione consente all’utente di sfogliare e spostare i file dall’interfaccia web.
Un’applicazione Docker ha bisogno di un percorso host che rimanga disponibile quando il container viene avviato. Se il montaggio di rete sottostante scompare o viene ricreato seguendo un ciclo di vita diverso, l’app può visualizzare un percorso vuoto o mancante anche se Files riesce a riconnettersi in seguito.
Le indicazioni sugli UUID non si applicano a una normale condivisione SMB
Una risposta suggeriva di eseguire il montaggio “utilizzando un UUID”. Un altro partecipante ha correttamente osservato che la condivisione Unraid remota era stata collegata tramite IP/SMB, anziché essere un dispositivo a blocchi locale.
Gli UUID sono utili per identificare filesystem e dispositivi a blocchi locali. Una condivisione SMB viene identificata tramite il percorso del server e della condivisione di rete, le credenziali e la configurazione del montaggio.
Una risposta della community suggeriva /etc/fstab
Un altro partecipante ha affermato che per lui un montaggio SMB persistente in /etc/fstab era stato stabile. Si tratta di una procedura convenzionale dell’amministrazione Linux e può funzionare, ma era un consiglio della community e l’autore del post originale non ha confermato una configurazione finale funzionante.
Su un sistema operativo di tipo appliance, configurare manualmente il montaggio sull’host significa inoltre assumersi la gestione dell’ordine di avvio, delle credenziali, del comportamento alla riconnessione e della compatibilità tra gli aggiornamenti.
Le versioni attuali di ZimaOS supportano ancora lo spazio di archiviazione LAN in Files
La documentazione attuale di IceWhale mostra come aggiungere lo spazio di archiviazione LAN dalla barra laterale di Files, inserendo l’indirizzo IP del NAS remoto e le credenziali. Questo è il metodo supportato per sfogliare o migrare dati da un altro NAS.
Utilizza la procedura attuale di connessione allo spazio di archiviazione LAN quando l’obiettivo è accedere ai file o migrarli.
La discussione non ha stabilito un metodo supportato per il montaggio persistente delle app
Nessuno sviluppatore di IceWhale ha risposto con una procedura documentata per “montare permanentemente questa condivisione SMB per le app Docker”, e l’autore del post originale è rimasto scettico sul fatto che la connessione da Files potesse sopravvivere al ciclo di vita osservato.
Un articolo affidabile deve mantenere questo aspetto irrisolto, invece di presentare il suggerimento della community relativo a fstab come soluzione ufficiale.
Per un server multimediale, stabilisci dove si trova il confine del montaggio stabile
Se Plex ed Emby devono ripristinarsi automaticamente dopo un’interruzione di corrente, il percorso dei contenuti multimediali remoti deve essere montato prima dell’avvio dei container e rimanere stabile durante le riconnessioni. Questo può essere ottenuto con diverse architetture Linux, ma la scelta esatta deve essere testata sulla versione attuale di ZimaOS.
Per configurazioni sempre attive e di particolare importanza, verifica il riavvio a freddo, il riavvio del NAS remoto, il riavvio dello switch e la perdita temporanea della rete prima di considerare il percorso di archiviazione pronto per la produzione.
Evita scansioni non necessarie dei contenuti multimediali
Quando una condivisione multimediale scompare temporaneamente, Plex o Emby possono interpretarlo come una rimozione dei contenuti, a seconda delle impostazioni della libreria. Evita la pulizia automatica distruttiva della libreria finché il comportamento del montaggio remoto non è stato dimostrato stabile.
Domande frequenti sul montaggio delle app da un NAS remoto
Ricollegare la condivisione in Files ha ripristinato le app?
Gli utenti hanno riferito che ricollegare la condivisione e riavviare le app ha ripristinato l’accesso.
Una condivisione SMB può essere montata tramite UUID del filesystem?
Non nello stesso senso di un disco locale. SMB utilizza il percorso di una condivisione di rete e le credenziali.
In questa discussione IceWhale ha pubblicato una soluzione confermata per il montaggio persistente delle app Docker?
No. La discussione pubblica si è conclusa senza una soluzione di questo tipo.
