L'obiettivo originale di questa discussione del novembre 2025 era semplice: mantenere ZimaOS e le applicazioni sull'SSD interno da 512 GB del mini PC, utilizzando invece un disco rigido USB Seagate esterno da 5 TB per i contenuti multimediali e i download. La difficoltà è nata dal fatto che il disco esterno è stato trattato come un normale montaggio su un server Linux, prima di comprendere come ZimaOS gestisse già lo spazio di archiviazione.
L'utente ha fatto delle prove montando manualmente il disco sotto /var, in seguito il server si è arrestato e l'utente ha reinstallato ZimaOS. Dopo ha montato il disco sotto un percorso dati di ZimaOS e lo ha mappato in SABnzbd, ma l'applicazione ha continuato a restituire un errore di autorizzazione. Questa discussione contiene quindi due lezioni separate: scegliere prima un percorso host gestito e sicuro, poi risolvere separatamente i permessi del container.
Non usare /var come punto di montaggio USB arbitrario
ZimaOS è un sistema operativo in stile appliance, con percorsi di sistema gestiti. L'utente originale ha detto di aver montato l'unità esterna sotto /var inizialmente sembrava funzionare, ma poi si è verificato un arresto completo del server con successiva reinstallazione.
La discussione non dimostra che il montaggio in sé abbia causato direttamente il crash, ma è un motivo sufficiente per non promuovere le directory di sistema a normali percorsi di archiviazione per i dischi multimediali.
Lascia che sia l'attuale ZimaOS a gestire l'unità esterna
L'attuale ZimaOS offre un supporto per l'archiviazione USB molto più ampio rispetto all'ambiente del 2025 descritto in questa discussione. Un disco USB può essere aggiunto tramite Impostazioni > Archiviazione e quindi utilizzato come normale spazio di archiviazione, anziché essere collegato manualmente a un punto di montaggio Linux inventato.
Per una nuova installazione, inizia con il flusso di lavoro attuale di ZimaOS per aggiungere spazio di archiviazione USB. Una volta gestito il disco, usa la sua cartella di archiviazione effettiva nella mappatura dei volumi dell'applicazione.
Il disco sorgente è infine apparso nei percorsi gestiti da ZimaOS
Il percorso esatto mostrato in un'installazione del 2025 non dovrebbe essere copiato su un altro server. I nomi dei dispositivi, come sda, sdb, e sdc può cambiare a seconda dell'ordine di avvio e dell'hardware collegato.
Mappa una cartella, non il dispositivo a blocchi grezzo
Le applicazioni Docker dovrebbero normalmente ricevere una directory, ad esempio una cartella di download o multimediale, non il dispositivo grezzo /dev/sda1. ZimaOS monta il filesystem; il container riceve una cartella dell'host proveniente da quel filesystem montato.
La spiegazione attuale di come lo spazio di archiviazione dell'host diventa un volume del container aiuta a evitare di confondere il dispositivo disco, il punto di mount e il percorso del container.
Un mount corretto può comunque generare un errore di autorizzazioni
L'utente in questione ha raggiunto /DATA/HDD1 e l'ha mappata in SABnzbd, ma l'applicazione non riusciva a usare la directory di download selezionata. Ciò significa che la visibilità dello spazio di archiviazione non era più l'unico problema.
I processi Docker vengono eseguiti come utente o gruppo all'interno del container. Se la cartella sull'host appartiene a un utente diverso e dispone di autorizzazioni restrittive, il container può vedere il percorso senza riuscire a creare file.
Non copiare PUID 999 alla cieca
Una risposta della community suggeriva all'utente di modificare PUID da 1000 a 999. Questo poteva corrispondere al modello di account ZimaOS del rispondente, ma non è una costante universale.
Prima di modificare PUID o PGID, identifica il proprietario della cartella effettiva sull'host e l'utente con cui dovrebbe essere eseguita l'applicazione. Un valore numerico che funziona su un'installazione può riferirsi a un account diverso su un'altra.
chmod e chown ricorsivi sono potenti e distruttivi
Una risposta successiva della community ha suggerito di usare ricorsivamente chmod 775 e chown sul percorso dei download. Questi comandi possono essere utili strumenti di amministrazione Linux, ma modificano ogni file e directory all'interno della destinazione. Non sono stati pubblicati dallo staff di IceWhale in questa discussione.
Prima di modificare ricorsivamente la proprietà:
- conferma il percorso di destinazione esatto;
- verifica che il file system supporti la normale proprietà Linux;
- comprendi quali utenti o servizi utilizzano già la cartella;
- esegui il backup dei metadati o dei permessi importanti se la cartella è condivisa da diverse applicazioni.
Il tipo di file system può modificare il modello dei permessi
Un disco ext4 memorizza direttamente gli UID, i GID e i bit di modalità Linux. exFAT e alcune configurazioni NTFS possono invece presentare la proprietà tramite opzioni a livello di montaggio. Se le modifiche al PUID non hanno effetto, controlla il file system prima di cambiare ripetutamente le impostazioni dell'applicazione.
Una struttura più ordinata per le app multimediali
Un'impostazione pratica è:
- SSD interno: sistema ZimaOS e runtime ridotto delle applicazioni;
- HDD esterno di grandi dimensioni: contenuti multimediali, download, backup e altri dati voluminosi;
- AppData persistenti: collocati in una posizione di archiviazione con capacità e copertura di backup sufficienti;
- per ogni app: mappature esplicite dei volumi limitate alle sole cartelle necessarie.
In questo modo eviti che un download multimediale riempia l'unità di sistema e semplifichi il backup separato della configurazione dell'applicazione e dei file multimediali di grandi dimensioni.
FAQ sull'HDD esterno su ZimaOS
Devo montare manualmente un HDD esterno sotto /var?
No, per il normale utilizzo attuale di ZimaOS. Usa l'interfaccia Storage e i percorsi di archiviazione gestiti.
SABnzbd dovrebbe mappare direttamente /dev/sda1?
No. Mappa una normale directory dell'host dal file system montato al percorso di download previsto dal container.
Perché l'app vede la cartella ma non riesce a scriverci?
I permessi del file system host, la proprietà oppure PUID/PGID del container potrebbero non consentire la scrittura.
PUID 999 è un valore standard di ZimaOS?
No. Era un suggerimento specifico della community e andrebbe verificato sul sistema reale.
