Este hilo es un buen ejemplo de diagnóstico por eliminación. Al principio, una copia de Windows que fallaba en los últimos porcentajes parecía un problema de escritura de SMB o RAID. La comunidad comprobó el estado del RAID, SMART, los registros del kernel, Robocopy y la MTU. El usuario incluso reconstruyó el NAS como una nueva matriz RAID5 usando discos diferentes, y aun así los mismos archivos seguían fallando desde el mismo PC con Windows.
La prueba decisiva llegó después: exactamente los mismos archivos se copiaron correctamente al mismo recurso compartido de ZimaOS desde otros equipos con Windows. Esto limita el problema de origen al cliente original con Windows 11 y Ryzen, o a su ruta de red/controlador, no a la matriz de almacenamiento de ZimaOS. Nunca se estableció con exactitud cuál era la reparación del lado del cliente.
Explorer y Robocopy fallaron cerca del 99,9 %
Los archivos afectados eran grabaciones de TV .ts archivos. Windows Explorer falló cerca del final, y Robocopy reprodujo el mismo comportamiento con:
ERROR 665 / 0x00000299Por lo tanto, usar otra herramienta de copia no resolvió el problema de origen.
Las comprobaciones de SMART y del RAID no mostraron ningún fallo de disco
Las capturas de SMART publicadas mostraban cero sectores pendientes, reasignados e incorregibles en las unidades comprobadas, y el RAID informaba [UUUU].
Un RAID completamente nuevo con discos diferentes seguía fallando desde el mismo PC
Didier reconstruyó el sistema usando cuatro unidades de 3 TB diferentes en RAID5. El mismo problema de transferencia persistió. Esto demuestra claramente que la causa no eran los discos originales de 1 TB ni una matriz específica.
Los mismos archivos funcionaron desde otros PC con Windows
Posteriormente, el autor original probó el mismo contenido desde otros equipos y dijo que se copió con normalidad. En marzo repitió el experimento desde otro PC con Windows 11 Pro y volvió a tener éxito.
Esta es la prueba de aislamiento más contundente de todo el hilo.
La MTU ya era de 1500 en todas partes
La comunidad sugirió descartar una discrepancia en las tramas jumbo. El usuario confirmó que todos los dispositivos tenían una MTU de 1500, por lo que el caso no se explicaba porque un enlace usara tramas jumbo y otro no.
SMB1 ya estaba desactivado
Otra prueba comprobó si podía estar implicado un protocolo SMB antiguo. El usuario informó que SMB1 ya estaba desactivado, lo cual es apropiado para redes modernas con Windows/ZimaOS.
Los registros del servidor seguían siendo útiles, pero la prueba entre equipos fue más contundente
La comunidad pidió registros de ZimaOS de solo lectura inmediatamente después del fallo:
dmesg -T | tail -200
journalctl -n 200 --no-pagerPueden revelar reinicios o tiempos de espera. Sin embargo, una vez que otros PC copiaron correctamente los mismos archivos al mismo NAS, el cliente Windows original se convirtió en el lugar prioritario para solucionar el problema.
Qué comprobar en el PC Windows afectado
- controlador y firmware de la NIC;
- configuración avanzada de descarga de la NIC/ahorro de energía;
- software de VPN, filtros o seguridad;
- corrupción de la pila de red de Windows;
- el adaptador Ethernet/Wi‑Fi específico y el cable o la ruta;
- un arranque limpio o una NIC diferente como prueba controlada.
La comunidad sugirió una reinstalación completa de Windows como el restablecimiento más seguro, pero el usuario de la fuente no confirmó haberla realizado ni haber encontrado el controlador exacto que fallaba.
La extensión de archivo .ts no era la causa principal
Solo algunas grabaciones de flujo de transporte fallaban desde el PC original, lo que inicialmente hizo que el tipo de archivo pareciera sospechoso. Sin embargo, esos mismos archivos exactos se copiaron correctamente desde otro equipo Windows. Eso descarta una política de ZimaOS que simplemente rechace .ts archivos.
Prueba otro adaptador de red antes de reinstalar Windows
Como la evidencia final apunta a un solo PC, una siguiente prueba de bajo riesgo consiste en usar otro adaptador Ethernet, una interfaz Wi‑Fi, una NIC USB, otro cable o un puerto diferente del conmutador, manteniendo la misma instalación de Windows y el mismo archivo. Si la transferencia se realiza correctamente, el problema puede acotarse hacia la ruta de la NIC/controlador original sin reconstruir toda la estación de trabajo.
Aísla temporalmente los filtros de red de terceros
Los clientes VPN, el software de seguridad de endpoints, los moldeadores de tráfico, los conmutadores virtuales, los controladores de captura de paquetes y las suites de red de la placa base pueden insertar controladores de filtro en la pila de red de Windows. Un arranque limpio o una prueba controlada de desactivación/desinstalación puede identificar esta capa.
No desactives permanentemente la seguridad de los endpoints solo para hacer funcionar SMB; el objetivo es diagnosticar el problema.
La diferencia de «Tamaño en disco» del origen era coherente con una transferencia incompleta
Más tarde, el usuario observó que la copia de red ocupaba menos espacio que el original. Como el PC con problemas se detenía repetidamente en la etapa final, era de esperar que el archivo de destino fuera más pequeño o estuviera incompleto, y eso por sí solo no indica que ZimaOS comprimiera o dañara el archivo.
Se sugirió una reinstalación completa de Windows, pero no se demostró
La comunidad consideró que una reinstalación limpia del sistema operativo era la forma más segura de restablecer un problema de red desconocido del cliente. El autor original no informó haber realizado una instalación limpia completa, por lo que debe seguir siendo una opción de último recurso, no una solución confirmada por la fuente.
Preguntas frecuentes sobre errores de copia SMB
¿La fuente demostró que el RAID de ZimaOS estaba dañado?
No. RAID/SMART estaban en buen estado, una matriz nueva con discos diferentes se comportó igual y otros PC copiaron correctamente los mismos archivos.
¿Robocopy resolvió el problema?
No. Robocopy reprodujo el ERROR 665 cerca del 99,9 %.
¿Qué aisló la evidencia final?
El PC original con Windows 11 y Ryzen o su pila de red/cliente, mientras que la solución exacta del lado del cliente seguía sin resolverse.
