Cette discussion illustre bien un diagnostic par élimination. Au départ, une copie Windows qui échouait dans les derniers pourcents ressemblait à un problème d’écriture SMB ou RAID. La communauté a vérifié l’état du RAID, les données SMART, les journaux du noyau, Robocopy et la MTU. L’utilisateur a même reconstruit le NAS sous la forme d’un nouveau tableau RAID5 avec des disques différents — et les mêmes fichiers échouaient toujours depuis le même PC Windows.
Le test décisif est arrivé plus tard : les mêmes fichiers ont été copiés avec succès vers le même partage ZimaOS depuis d’autres machines Windows. Cela circonscrit le problème au client Ryzen Windows 11 d’origine ou à sa pile réseau/son chemin de pilote, et non au tableau de stockage ZimaOS. La réparation exacte côté client n’a jamais été établie.
L’Explorateur et Robocopy échouaient vers 99,9 %
Les fichiers concernés étaient des enregistrements télévisés .ts fichiers. L’Explorateur Windows échouait vers la fin, et Robocopy reproduisait le même comportement avec :
ERROR 665 / 0x00000299L’utilisation d’un autre outil de copie n’a donc pas résolu le problème initial.
Les vérifications SMART et RAID n’ont révélé aucune défaillance de disque
Les captures d’écran SMART publiées indiquaient zéro secteur en attente, réalloué ou irrécupérable sur les disques vérifiés, et le RAID signalait [UUUU].
Un tout nouveau RAID avec des disques différents échouait toujours depuis le même PC
Didier a reconstruit le système avec quatre disques de 3 To différents en RAID5. Le même problème de transfert persistait. Cela constitue un indice fort contre une implication des disques d’origine de 1 To ou d’un tableau spécifique.
Les mêmes fichiers fonctionnaient depuis d’autres PC Windows
L’auteur initial a ensuite testé le même contenu depuis d’autres machines et a indiqué que la copie s’était déroulée normalement. En mars, il a renouvelé l’expérience depuis un autre PC Windows 11 Pro et a de nouveau réussi.
Il s’agit du test d’isolation le plus probant de toute la discussion.
La MTU était déjà de 1500 partout
La communauté a suggéré d’écarter une incompatibilité de trames jumbo. L’utilisateur a confirmé que tous les appareils utilisaient une MTU de 1500 ; le problème observé ne s’expliquait donc pas par un lien utilisant des trames jumbo alors qu’un autre ne le faisait pas.
SMB1 était déjà désactivé
Un autre test a vérifié si un ancien protocole SMB pouvait être en cause. L’utilisateur a indiqué que SMB1 était déjà désactivé, ce qui est approprié pour les réseaux Windows/ZimaOS modernes.
Les journaux du serveur méritaient toujours d’être vérifiés, mais le test inter-PC était plus probant
La communauté a demandé les journaux ZimaOS en lecture seule immédiatement après l’échec :
dmesg -T | tail -200
journalctl -n 200 --no-pagerCeux-ci peuvent révéler des réinitialisations ou des délais d’attente. Mais une fois que d’autres PC ont copié les mêmes fichiers vers le même NAS avec succès, le client Windows d’origine est devenu le point prioritaire du dépannage.
Éléments à vérifier sur le PC Windows concerné
- le pilote et le micrologiciel de la carte réseau ;
- les paramètres avancés de déchargement ou d’économie d’énergie de la carte réseau ;
- les logiciels VPN, de filtrage ou de sécurité ;
- la corruption de la pile réseau de Windows ;
- l’adaptateur Ethernet/Wi-Fi et le câble ou chemin réseau concernés ;
- un démarrage minimal ou une autre carte réseau comme test contrôlé.
Une réinstallation complète de Windows a été suggérée par la communauté comme la réinitialisation la plus sûre, mais l’utilisateur à l’origine de la source n’a pas confirmé en avoir effectué une ni avoir trouvé le pilote défaillant exact.
L’extension de fichier .ts n’était pas la cause première
Seuls certains enregistrements au format transport stream échouaient depuis le PC d’origine, ce qui avait d’abord rendu le type de fichier suspect. Mais ces mêmes fichiers exacts étaient copiés avec succès depuis une autre machine Windows. Cela exclut une règle de ZimaOS qui rejetterait simplement les .ts fichiers.
Essayez un autre adaptateur réseau avant de réinstaller Windows
Comme les éléments finaux pointent vers un seul PC, un prochain test peu risqué consiste à utiliser un autre adaptateur Ethernet, une autre interface Wi-Fi, une carte réseau USB, un autre câble ou un autre port du commutateur, tout en conservant la même installation de Windows et le même fichier. Si le transfert réussit, le problème peut être circonscrit au chemin de la carte réseau ou du pilote d’origine, sans reconstruire toute la station de travail.
Isolez temporairement les filtres réseau tiers
Les clients VPN, les logiciels de sécurité des terminaux, les façonneurs de trafic, les commutateurs virtuels, les pilotes de capture de paquets et les suites réseau des cartes mères peuvent insérer des pilotes de filtrage dans la pile réseau de Windows. Un démarrage minimal ou un test contrôlé de désactivation/désinstallation peut permettre d’identifier cette couche.
Ne désactivez pas définitivement la sécurité des terminaux simplement pour faire fonctionner SMB ; l’objectif est le diagnostic.
La différence de « taille sur le disque » de la source était compatible avec un transfert incomplet
L’utilisateur a ensuite remarqué que la copie réseau occupait moins d’espace que l’original. Comme le PC défaillant s’arrêtait systématiquement à la dernière étape, un fichier de destination plus petit ou incomplet est attendu et n’indique pas à lui seul que ZimaOS a compressé ou corrompu le fichier.
Une réinstallation complète de Windows a été suggérée, mais pas démontrée
La communauté considérait une réinstallation propre du système d’exploitation comme le moyen le plus sûr de réinitialiser un problème réseau inconnu côté client. L’auteur du message d’origine n’a pas indiqué avoir effectué une installation propre complète ; cette option doit donc rester un dernier recours plutôt qu’une solution confirmée par la source.
FAQ sur les erreurs de copie SMB
La source a-t-elle prouvé que le RAID de ZimaOS était corrompu ?
Non. Le RAID et SMART étaient sains, un nouveau volume avec des disques différents se comportait de la même manière, et d’autres PC copiaient les mêmes fichiers avec succès.
Robocopy a-t-il résolu le problème ?
Non. Robocopy a reproduit l’erreur 665 vers 99,9 %.
Qu’est-ce que les éléments finaux ont permis d’isoler ?
Le PC Windows 11 Ryzen d’origine ou sa pile réseau/client, tandis que le correctif exact côté client restait indéterminé.
