Cosa causa la modifica dei checksum dei file dopo la copia tramite una condivisione SMB?
SMB normalmente trasporta i byte dei file senza modificarli, quindi una mancata corrispondenza dei checksum significa che il contenuto confrontato è cambiato, è stato letto in modo incoerente oppure non proveniva dallo stesso flusso di dati.
La mancata corrispondenza può dipendere dal calcolo dell’hash della sorgente prima che un’applicazione abbia terminato la scrittura, dal confronto tra un resource fork o uno stream alternativo su un lato, da un’applicazione multimediale o di sicurezza che riscrive la destinazione, dalla lettura tramite una cache client obsoleta oppure da errori di archiviazione e trasporto. Il test corretto blocca la sorgente, calcola l’hash di entrambi i file con lo stesso strumento e la stessa modalità e ripete il trasferimento attraverso un percorso controllato prima di attribuire la colpa a SMB.
Verifica che entrambi i checksum coprano gli stessi dati del file
Registra il percorso esatto della sorgente, il percorso della destinazione, il comando di hashing, l’algoritmo, la modalità binaria o testo e l’ora in cui è stato generato ciascun checksum. Verifica che nessun comando abbia letto un collegamento, la destinazione di un link simbolico, un file temporaneo o un file associato.
L’utility SHA-256 calcola un digest dai byte letti dal file specificato. Il riferimento di sha256sum supporta l’uso dello stesso algoritmo e della stessa invocazione su entrambi gli endpoint.
Se le dimensioni differiscono, individua una copia incompleta o modificata prima di confrontare gli hash. Se le dimensioni coincidono ma gli hash differiscono, continua verificando la stabilità della sorgente, l’ambito degli stream, le letture dello storage e le modifiche alla destinazione.
Blocca le applicazioni che possono modificare la sorgente durante la copia
Arresta database, client di download, macchine virtuali, editor multimediali, strumenti di sincronizzazione e qualsiasi applicazione che scriva sul file sorgente. Genera un nuovo checksum della sorgente solo dopo aver chiuso il file.
La documentazione di Rsync avverte che i file devono essere spostati in una directory sorgente monitorata solo dopo essere stati scritti completamente, perché un file sorgente in modifica può essere trasferito in modo incoerente.
Confronta il checksum della sorgente prima e subito dopo la copia SMB. Se i due hash della sorgente differiscono, SMB non è la prima causa: la sorgente è cambiata durante il test.
Controlla oplock, processi locali e stato della cache dei file
Elenca gli handle SMB aperti e i processi locali che accedono alla sorgente e alla destinazione. Presta particolare attenzione quando la stessa condivisione viene scritta contemporaneamente tramite SMB e direttamente sull’host NAS.
Samba spiega che i blocchi opportunistici consentono a un client di memorizzare localmente nella cache le modifiche ai file e di sincronizzarle nuovamente con il server quando necessario. Il suo modello di blocchi e oplock mostra perché i processi locali e SMB che scrivono contemporaneamente devono essere controllati durante i test di integrità.
Non disabilitare gli oplock sull’intero server come prima misura. Chiudi le applicazioni concorrenti, apri una nuova sessione e ripeti la copia di un singolo file per verificare se la concorrenza era coinvolta.
Separa il contenuto del file dagli attributi estesi e dagli stream alternativi
Stabilisci se il checksum previsto copre solo i dati principali del file oppure un archivio che include anche resource fork, attributi estesi, stream alternativi, ACL e metadati. Usa lo stesso ambito su entrambi i lati.
ArchWiki descrive gli attributi estesi come metadati memorizzati separatamente dai normali contenuti dei file. La perdita o la conversione di tali metadati può modificare l’hash di un archivio o di un pacchetto senza modificare il checksum del flusso di dati principale.
Per i file macOS, confronta separatamente il data fork principale con qualsiasi resource fork o file associato AppleDouble. Non interpretare una mancata corrispondenza dei metadati come prova che i byte del file principale siano cambiati.
Usa uno strumento di copia con ripresa e registrazione
Ripeti il trasferimento con un unico metodo di copia noto e un nuovo nome file di destinazione. Salva il registro dei tentativi, delle riprese, degli elementi ignorati e degli errori invece di affidarti alla finestra di avanzamento di un browser di file.
Microsoft definisce SMB come un protocollo che consente alle applicazioni di leggere, creare e aggiornare file remoti. Il suo modello di accesso ai file SMB supporta l’interpretazione di un checksum modificato come problema del percorso dati o di un processo di scrittura, non come una trasformazione prevista dal protocollo.
Se una copia dalla riga di comando con registro produce risultati corretti mentre il trascinamento della selezione no, confronta l’applicazione, il comportamento dei tentativi, la gestione dei file parziali, la scansione antivirus e l’elaborazione successiva alla copia invece di modificare il server SMB.
Confronta la destinazione prima che indicizzatori o applicazioni la riscrivano
Calcola l’hash della destinazione subito dopo la copia, mentre il file è chiuso e prima che scanner multimediali, convertitori di documenti, gestori di foto, strumenti antivirus o client di sincronizzazione possano modificarlo.
La guida di Robocopy dell’Oregon State sottolinea la copia con registrazione e ripristino, che offre un confine più chiaro tra il completamento del trasferimento e l’accesso successivo alla destinazione da parte delle applicazioni.
Se l’hash immediato della destinazione corrisponde ma cambia in seguito, identifica il primo processo che apre il file in scrittura. La soluzione permanente riguarda il comportamento dell’applicazione relativo a metadati, ottimizzazione o sincronizzazione.
Ripeti il test attraverso i confini dello storage e della rete
Copia lo stesso file di test chiuso localmente sul NAS sorgente, localmente sul filesystem di destinazione, tramite SMB da un altro client e tramite il client originale. Calcola l’hash dopo ogni passaggio.
La guida di ZimaSpace alla conservazione dei metadati durante la migrazione NAS fornisce la regola correlata: gli hash del contenuto e i campi dei metadati devono essere convalidati come criteri di accettazione separati.
Il problema è risolto quando un file sorgente chiuso produce hash corrispondenti attraverso copie ripetute e rimane invariato dopo l’esecuzione dei servizi successivi alla copia. Interrompi la migrazione e proteggi la sorgente se le mancate corrispondenze seguono uno specifico disco, controller, client o offset di file riproducibile.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
