Un dataset ZFS può risultare montato ma apparire vuoto quando i dati attesi si trovano in un dataset figlio, in un punto di montaggio nascosto o in una radice di importazione diversa.
Il flag di montaggio dimostra che un dataset è collegato a un percorso, ma non dimostra che il percorso sia quello previsto da un’applicazione o da un utente, che i dataset figli siano montati al suo interno o che un discendente crittografato sia stato sbloccato. Un dataset padre vuoto può essere perfettamente integro, mentre tutti i file reali si trovano nei dataset figli. Inizia confrontando le proprietà dei dataset, lo spazio referenziato, le tabelle dei mount e la vista della directory prima di copiare dati o modificare la struttura del pool.
Confronta lo spazio del dataset con la directory che hai aperto
Registra il nome del dataset e i valori di USED, REFER, AVAIL, MOUNTPOINT e MOUNTED. Quindi elenca la directory esatta mostrata all’utente o all’applicazione.
Se il dataset segnala una quantità di dati referenziati quasi nulla, i file potrebbero appartenere a un dataset figlio, a uno snapshot, a un clone o a un altro dataset con un nome simile. Il manuale ZFS di FreeBSD descrive i dataset come filesystem gestiti separatamente, quindi l’utilizzo a livello di pool e una directory aperta non rappresentano necessariamente lo stesso dataset.
Non dedurre una perdita di dati dal solo browser grafico dei file. Confronta la vista delle proprietà ZFS, la tabella dei mount del sistema operativo e una shell locale con privilegi di root, esterna a qualsiasi container o namespace applicativo limitato.
Verifica insieme mountpoint, mounted e canmount
Controlla se il mountpoint del dataset è esplicito o ereditato, se è effettivamente montato in quel percorso e se canmount è impostato su on, off o noauto.
La guida di Oracle sulle proprietà ZFS spiega che mountpoint e canmount determinano se un dataset viene montato automaticamente, solo quando richiesto oppure utilizzato esclusivamente per passare proprietà ai discendenti.
Un dataset può fornire proprietà ereditate ai propri figli pur rimanendo intenzionalmente non montato. Al contrario, un dataset che utilizza un mountpoint legacy può apparire corretto nelle proprietà ZFS, ma dipendere da una voce di montaggio separata del sistema che non è stata eseguita.
Esamina i mount dei dataset padre e figli
Elenca l’intero albero dei dataset sotto il pool e ordina l’elenco per mountpoint. Confronta il dataset padre con ogni figlio che dovrebbe contenere file utente, dati delle applicazioni, backup o contenuti multimediali.
Un padre vuoto è comune quando esiste solo per organizzare proprietà e mountpoint. Il namespace dei dataset ZFS di FreeBSD tratta ogni figlio come un dataset gestito separatamente, quindi pool/data può essere vuoto mentre pool/data/photos contiene i file effettivi.
Se il padre viene montato ma un figlio no, diagnostica il figlio separatamente. Controlla canmount, le chiavi di crittografia, i mountpoint in conflitto, le importazioni non riuscite e l’eventualità che un servizio sia stato avviato prima del completamento del mount del figlio.
Verifica se il mount ha nascosto file già presenti nella directory
Prima che un dataset venga montato sopra una directory, in quella directory possono già esistere dei file. Una volta montato il dataset ZFS, i file sottostanti vengono nascosti dal percorso, anche se rimangono nel filesystem root.
Smonta il dataset solo durante una finestra di manutenzione controllata e controlla la directory sottostante dall’host. Il manuale dei mount di Linux afferma che i contenuti preesistenti del punto di montaggio diventano invisibili mentre il filesystem montato occupa quel percorso.
Può verificarsi anche il problema opposto: un mount ZFS previsto non riesce e lascia visibile agli utenti e ai container la directory sottostante vuota. In questo modo un dataset integro può sembrare vuoto, anche se semplicemente non è collegato al percorso che viene esposto.
Escludi una radice alternativa e il comportamento dei mount legacy
Controlla se il pool è stato importato con una radice alternativa, un’opzione di ripristino, un percorso di montaggio temporaneo o un nome di pool diverso. Un dataset può essere montato correttamente sotto un percorso di ripristino con prefisso anziché nella normale posizione di produzione.
L’importazione di un pool con una radice alternativa riscrive i percorsi di montaggio dei dataset in relazione a quella radice temporanea. La documentazione di riferimento di zpool import di Ubuntu specifica che -R imposta altroot, mentre -N può importare il pool senza montare i filesystem.
Esamina anche i dataset il cui mountpoint è impostato su legacy. In questa modalità ZFS non gestisce automaticamente il mount, quindi la configurazione dei mount del sistema operativo diventa la fonte di verità.
Controlla i figli crittografati e i namespace di montaggio dei container
Un dataset figlio crittografato può rimanere non disponibile dopo il montaggio del padre se la chiave non è stata caricata o se il mount del figlio non è riuscito. La directory del padre appare quindi vuota o incompleta anche se il pool è online.
Verifica lo stato della chiave e del mount per ogni discendente crittografato, quindi confronta il percorso dell’host con quello presentato al container. La documentazione LXD di Canonical spiega che i dispositivi disco dei container mappano le origini dell’host su percorsi separati dell’istanza, quindi un dataset figlio visibile sull’host può essere comunque assente da un mount più vecchio del container.
Se l’host vede i dati ma un container no, controlla l’origine del bind del container e la propagazione del mount. Un container creato prima del montaggio del figlio ZFS può continuare a visualizzare la directory sottostante vuota finché il servizio non viene ricreato o il mount non viene propagato correttamente.
Ripristina la visualizzazione corretta senza copiare il dataset
Correggi la proprietà o il percorso più piccolo per cui hai una causa certa: monta il figlio mancante, correggi un mountpoint ereditato, rimuovi una radice alternativa non intenzionale, ripara la voce di mount legacy, carica la chiave di crittografia oppure ricrea il container con l’origine bind corretta.
La checklist di ripristino del server domestico di ZimaSpace stabilisce una regola correlata: verifica il livello di archiviazione e lo stato dei mount prima di eseguire strumenti di riparazione o ripristinare i dati.
La diagnosi è completa quando il dataset previsto e i mount dei figli compaiono nei percorsi desiderati, lo spazio referenziato corrisponde ai file visibili, le applicazioni vedono lo stesso albero dell’host e la struttura rimane corretta dopo esportazione, importazione, riavvio del servizio e riavvio del sistema.
Supporto e consigli
Altro da leggere

Guida all’archiviazione delle registrazioni TV in diretta per capacità, conservazione e pulizia
Misura le registrazioni reali, riserva margine, combina i limiti di età e capacità e dimostra che il programma idoneo più vecchio viene rimosso prima...

Procedura di recupero dei metadati multimediali domestici dopo il ripristino di un database
Proteggi lo stato ripristinato, verifica l'identità e i percorsi dei media, quindi correggi le copertine o le corrispondenze mancanti in una libreria pilota prima...

Checklist di compatibilità del client Jellyfin per audio, video e sottotitoli
Testa file rappresentativi una variabile alla volta e registra Direct Play, remux, conversione audio, transcodifica video o errore per ogni client.

