Este tópico é um bom exemplo de diagnóstico por eliminação. Inicialmente, uma cópia do Windows que falhava nos últimos pontos percentuais parecia ser um problema de escrita SMB ou da RAID. A comunidade verificou o estado da RAID, o SMART, os registos do kernel, o Robocopy e o MTU. O utilizador chegou a reconstruir o NAS como uma nova matriz RAID5 utilizando discos diferentes — e os mesmos ficheiros continuaram a falhar a partir do mesmo PC Windows.
O teste decisivo surgiu mais tarde: os mesmos ficheiros foram copiados com sucesso para a mesma partilha do ZimaOS a partir de outras máquinas Windows. Isto circunscreve o problema na origem ao cliente Windows 11 com Ryzen original ou ao percurso da respetiva pilha de rede/controlador, e não à matriz de armazenamento do ZimaOS. A reparação exata do lado do cliente nunca foi determinada.
O Explorer e o Robocopy falharam perto dos 99,9%
Os ficheiros afetados eram gravações de TV .ts ficheiros. O Windows Explorer falhou perto do fim, e o Robocopy reproduziu o mesmo comportamento com:
ERROR 665 / 0x00000299Por isso, utilizar uma ferramenta de cópia diferente não resolveu o problema na origem.
As verificações SMART e da RAID não revelaram nenhuma falha de disco
As capturas de ecrã SMART publicadas mostravam zero setores pendentes, realocados e incorrigíveis nas unidades verificadas, e a RAID indicava [UUUU].
Uma RAID completamente nova, com discos diferentes, continuou a falhar a partir do mesmo PC
O Didier reconstruiu o sistema utilizando quatro unidades de 3 TB diferentes em RAID5. O mesmo problema de transferência manteve-se. Isto é uma forte evidência contra as unidades originais de 1 TB ou uma matriz específica como causa.
Os mesmos ficheiros funcionaram a partir de outros PCs Windows
Mais tarde, o autor original testou o mesmo conteúdo a partir de outras máquinas e afirmou que a cópia foi concluída normalmente. Em março, repetiu a experiência a partir de outro PC com Windows 11 Pro e voltou a ter sucesso.
Este é o teste de isolamento mais conclusivo de todo o tópico.
O MTU já era 1500 em todo o lado
A comunidade sugeriu excluir uma incompatibilidade de jumbo frames. O utilizador confirmou que todos os dispositivos estavam com MTU 1500, pelo que o caso original não era explicado por uma ligação usar jumbo frames e outra não.
O SMB1 já estava desativado
Outro teste verificou se poderia estar envolvido um protocolo SMB antigo. O utilizador informou que o SMB1 já estava desativado, o que é adequado para redes modernas com Windows/ZimaOS.
Os registos do servidor continuavam a valer a pena consultar, mas o teste entre PCs foi mais esclarecedor
A comunidade pediu imediatamente registos do ZimaOS em modo só de leitura após a falha:
dmesg -T | tail -200
journalctl -n 200 --no-pagerPodem revelar reinicializações/expirações de tempo. No entanto, quando outros PCs copiaram com êxito os mesmos ficheiros para o mesmo NAS, o cliente Windows original tornou-se o local de maior valor para a resolução de problemas.
O que verificar no PC Windows afetado
- controlador e firmware da placa de rede;
- definições avançadas de descarga de processamento/energia da placa de rede;
- software de VPN/filtragem/segurança;
- corrupção da pilha de rede do Windows;
- o adaptador Ethernet/Wi-Fi específico e o cabo/percurso;
- um arranque limpo ou uma placa de rede diferente como teste controlado.
A comunidade sugeriu uma reinstalação completa do Windows como a reposição mais segura, mas o utilizador da origem não confirmou tê-la efetuado nem ter encontrado o controlador exato responsável pela falha.
A extensão de ficheiro .ts não era a causa principal
Apenas algumas gravações de fluxo de transporte falharam no PC original, o que inicialmente fez com que o tipo de ficheiro parecesse suspeito. Contudo, exatamente os mesmos ficheiros foram copiados com êxito a partir de outro computador Windows. Isso exclui uma política do ZimaOS que simplesmente rejeite .ts ficheiros.
Experimente outro adaptador de rede antes de reinstalar o Windows
Como a evidência final aponta para um único PC, um próximo teste de baixo risco consiste em utilizar outro adaptador Ethernet, uma interface Wi-Fi, uma placa de rede USB, um cabo ou uma porta do comutador, mantendo a mesma instalação do Windows e o mesmo ficheiro. Se a transferência for bem-sucedida, o problema poderá ser circunscrito ao percurso da placa de rede/controlador original, sem reconstruir toda a estação de trabalho.
Isole temporariamente os filtros de rede de terceiros
Clientes VPN, software de segurança do endpoint, modeladores de tráfego, comutadores virtuais, controladores de captura de pacotes e conjuntos de ferramentas de rede da placa-mãe podem inserir controladores de filtragem na pilha de rede do Windows. Um arranque limpo ou um teste controlado de desativação/desinstalação pode identificar esta camada.
Não desative permanentemente a segurança do endpoint apenas para fazer o SMB funcionar; o objetivo é diagnosticar o problema.
A diferença de “Tamanho no disco” da origem era compatível com uma transferência incompleta
Mais tarde, o utilizador reparou que a cópia através da rede ocupava menos espaço do que o original. Como o PC com falhas parava repetidamente na fase final, é esperado que o ficheiro de destino seja menor/incompleto, o que, por si só, não indica que o ZimaOS tenha comprimido ou corrompido o ficheiro.
Foi sugerida uma reinstalação completa do Windows, mas não foi comprovada
A comunidade considerou que uma reinstalação limpa do sistema operativo era a forma mais segura de repor um problema de rede desconhecido no cliente. O autor da publicação original não indicou ter efetuado uma instalação limpa completa, pelo que esta deve continuar a ser uma opção de último recurso, e não uma solução confirmada pela origem.
FAQ sobre erros de cópia SMB
A origem comprovou que o RAID do ZimaOS estava corrompido?
Não. O RAID/SMART estava em bom estado, uma nova matriz com discos diferentes comportou-se da mesma forma e outros PCs copiaram os mesmos ficheiros com êxito.
O Robocopy resolveu o problema?
Não. O Robocopy reproduziu o ERRO 665 perto dos 99,9%.
O que isolou a evidência final?
O PC original com Windows 11 e Ryzen ou a respetiva pilha de rede/cliente, embora a correção exata do lado do cliente tenha permanecido por resolver.
