Questa discussione è un buon esempio di diagnosi per eliminazione. Inizialmente, una copia Windows che si interrompeva negli ultimi punti percentuali sembrava indicare un problema di scrittura SMB o RAID. La community ha controllato lo stato del RAID, i dati SMART, i log del kernel, Robocopy e l'MTU. L'utente ha persino ricostruito il NAS come nuovo array RAID5 usando dischi diversi, ma gli stessi file continuavano a non funzionare dallo stesso PC Windows.
Il test decisivo è arrivato in seguito: gli stessi file venivano copiati correttamente nella stessa condivisione ZimaOS da altri computer Windows. Questo circoscrive il problema al client Windows 11 Ryzen originale o al relativo stack di rete/percorso del driver, non all'array di archiviazione ZimaOS. La riparazione esatta lato client non è mai stata determinata.
Esplora file e Robocopy si interrompevano intorno al 99,9%
I file interessati erano registrazioni televisive .ts file. Esplora file di Windows si interrompeva verso la fine e Robocopy riproduceva lo stesso comportamento con:
ERROR 665 / 0x00000299L'uso di uno strumento di copia diverso non ha quindi risolto il problema originale.
I controlli SMART e RAID non hanno rilevato guasti ai dischi
Gli screenshot SMART pubblicati mostravano zero settori pendenti, riallocati e non correggibili sulle unità controllate, e il RAID indicava [UUUU].
Un RAID completamente nuovo con dischi diversi continuava a non funzionare dallo stesso PC
Didier ha ricostruito il sistema usando quattro unità diverse da 3 TB in RAID5. Lo stesso problema di trasferimento è rimasto. È una prova significativa contro l'ipotesi che la causa fossero i dischi originali da 1 TB o uno specifico array.
Gli stessi file funzionavano da altri PC Windows
In seguito, l'autore del post originale ha testato gli stessi contenuti da altri computer e ha riferito che la copia è avvenuta normalmente. A marzo ha ripetuto l'esperimento da un altro PC Windows 11 Pro, ottenendo nuovamente esito positivo.
Questo è il test di isolamento più significativo dell'intera discussione.
L'MTU era già impostato su 1500 ovunque
La community ha suggerito di escludere un'incompatibilità delle dimensioni dei jumbo frame. L'utente ha confermato che tutti i dispositivi usavano un MTU di 1500, quindi il problema originale non era spiegato da un collegamento che utilizzava jumbo frame mentre un altro no.
SMB1 era già disabilitato
Un altro test ha verificato se potesse essere coinvolto un vecchio protocollo SMB. L'utente ha riferito che SMB1 era già disabilitato, una configurazione appropriata per le reti Windows/ZimaOS moderne.
Valeva comunque la pena controllare i log del server, ma il test tra PC era più significativo
La community ha chiesto i log di ZimaOS in sola lettura subito dopo il problema:
dmesg -T | tail -200
journalctl -n 200 --no-pagerPossono rivelare reset o timeout. Tuttavia, quando altri PC hanno copiato correttamente gli stessi file sullo stesso NAS, il client Windows originale è diventato il punto più importante da esaminare.
Cosa controllare sul PC Windows interessato
- driver e firmware della scheda di rete;
- impostazioni avanzate di offload/risparmio energetico della scheda di rete;
- software VPN/filtro/sicurezza;
- corruzione dello stack di rete di Windows;
- la scheda Ethernet/Wi-Fi e il percorso del cavo specifici;
- un avvio pulito o una scheda di rete diversa come test controllato.
La community ha suggerito una reinstallazione completa di Windows come il ripristino più certo, ma l’utente della fonte non ha confermato di averne eseguita una né di aver individuato il driver responsabile del problema.
L’estensione di file .ts non era la causa principale
Solo alcune registrazioni in formato transport stream non riuscivano a essere copiate dal PC originale, facendo inizialmente sembrare sospetto il tipo di file. Tuttavia, gli stessi identici file venivano copiati correttamente da un altro computer Windows. Ciò esclude una policy di ZimaOS che rifiuti semplicemente .ts file.
Prova un altro adattatore di rete prima di reinstallare Windows
Poiché le prove finali indicano un unico PC, un test successivo a basso rischio consiste nell’usare un altro adattatore Ethernet, un’interfaccia Wi-Fi, una scheda di rete USB, un cavo o una porta dello switch, mantenendo la stessa installazione di Windows e lo stesso file. Se il trasferimento riesce, il problema può essere circoscritto al percorso della scheda di rete o del relativo driver originale senza ricostruire l’intera workstation.
Isola temporaneamente i filtri di rete di terze parti
I client VPN, i software di sicurezza degli endpoint, i sistemi di gestione del traffico, gli switch virtuali, i driver di acquisizione dei pacchetti e le suite di rete della scheda madre possono inserire driver filtro nello stack di rete di Windows. Un avvio pulito o un test controllato di disabilitazione/disinstallazione può identificare questo livello.
Non disabilitare permanentemente la sicurezza degli endpoint solo per far funzionare SMB; l’obiettivo è la diagnosi.
La differenza “Dimensioni su disco” della fonte era coerente con un trasferimento incompleto
In seguito, l’utente ha notato che la copia in rete occupava meno spazio dell’originale. Poiché il PC problematico si arrestava ripetutamente nella fase finale, è normale aspettarsi un file di destinazione più piccolo/incompleto e questo, da solo, non indica che ZimaOS abbia compresso o danneggiato il file.
È stata suggerita una reinstallazione completa di Windows, ma non è stata dimostrata
La community ha indicato una reinstallazione pulita del sistema operativo come il modo più certo per reimpostare un problema di rete del client sconosciuto. L’autore del post originale non ha riferito di aver eseguito una reinstallazione completa, quindi questa dovrebbe rimanere un’opzione di ultima istanza, non una soluzione confermata dalla fonte.
FAQ sugli errori di copia SMB
La fonte ha dimostrato che il RAID di ZimaOS era corrotto?
No. RAID/SMART erano integri, un nuovo array con dischi diversi si comportava allo stesso modo e altri PC copiavano correttamente gli stessi file.
Robocopy ha risolto il problema?
No. Robocopy ha riprodotto l’ERRORE 665 intorno al 99,9%.
Che cosa hanno isolato le prove finali?
Il PC Ryzen originale con Windows 11 o il relativo stack di rete/client, mentre la soluzione esatta lato client restava irrisolta.
