¿Qué causa que las sumas de comprobación de los archivos cambien después de copiarlos a través de un recurso compartido SMB?
SMB normalmente transporta los bytes de los archivos sin cambios, por lo que una discrepancia de suma de comprobación significa que el contenido comparado cambió, se leyó de forma inconsistente o no correspondía al mismo flujo de datos.
La discrepancia puede deberse a calcular el hash del origen antes de que una aplicación termine de escribir, comparar un resource fork o un flujo alternativo en uno de los lados, permitir que una aplicación multimedia o de seguridad reescriba el destino, leer desde una caché obsoleta del cliente o encontrar errores de almacenamiento y transporte. La prueba correcta bloquea el origen, calcula el hash de ambos archivos con la misma herramienta y el mismo modo, y repite la transferencia por una ruta controlada antes de culpar al propio SMB.
Verifique que ambas sumas de comprobación cubran los mismos datos del archivo
Registre la ruta exacta de origen, la ruta de destino, el comando de hash, el algoritmo, el modo binario o de texto y la hora en que se generó cada suma de comprobación. Confirme que ningún comando haya leído un acceso directo, el destino de un enlace simbólico, un archivo temporal o un archivo auxiliar.
La utilidad SHA-256 calcula un resumen a partir de los bytes que lee del archivo especificado. La referencia de sha256sum permite usar el mismo algoritmo y la misma invocación en ambos extremos.
Si los tamaños difieren, diagnostique primero una copia incompleta o modificada antes de comparar los hashes. Si los tamaños coinciden pero los hashes difieren, continúe con la estabilidad del origen, el alcance de los flujos, las lecturas del almacenamiento y las modificaciones del destino.
Detenga las aplicaciones que puedan modificar el origen durante la copia
Detenga las bases de datos, los clientes de descarga, las máquinas virtuales, los editores multimedia, las herramientas de sincronización y cualquier aplicación que escriba en el archivo de origen. Genere una nueva suma de comprobación del origen solo después de cerrar el archivo.
La documentación de Rsync advierte que los archivos deben trasladarse a un directorio de origen supervisado únicamente después de que se hayan escrito por completo, porque un archivo de origen cambiante puede transferirse de forma inconsistente.
Compare la suma de comprobación del origen antes y justo después de la copia mediante SMB. Si los dos hashes del origen difieren, SMB no es la primera causa; el origen cambió durante la prueba.
Compruebe los bloqueos oportunistas, los escritores locales y el estado almacenado en caché
Enumere los identificadores de archivos SMB abiertos y los procesos locales que acceden al origen y al destino. Preste especial atención cuando el mismo recurso compartido se escriba simultáneamente mediante SMB y directamente en el host del NAS.
Samba explica que los bloqueos oportunistas permiten a un cliente almacenar localmente en caché los cambios de los archivos y sincronizarlos con el servidor cuando sea necesario. Su modelo de bloqueos y bloqueos oportunistas muestra por qué los escritores locales y SMB simultáneos deben controlarse durante las pruebas de integridad.
No desactive los bloqueos oportunistas en todo el servidor como primera respuesta. Cierre las aplicaciones en conflicto, abra una sesión nueva y repita la copia de un solo archivo para comprobar si hubo concurrencia.
Separe el contenido del archivo de los atributos extendidos y los flujos alternativos
Decida si la suma de comprobación esperada cubre únicamente los datos principales del archivo o un archivo que también incluya resource forks, atributos extendidos, flujos alternativos, ACL y metadatos. Use el mismo alcance en ambos lados.
ArchWiki describe los atributos extendidos como metadatos almacenados por separado del contenido normal de los archivos. Perder o traducir esos metadatos puede cambiar el hash de un archivo comprimido o paquete sin cambiar la suma de comprobación del flujo de datos principal.
En los archivos de macOS, compare por separado el data fork principal con cualquier resource fork o archivo auxiliar AppleDouble. No interprete una discrepancia de metadatos como una prueba de que cambiaron los bytes del archivo principal.
Use una herramienta de copia con reanudación y registro
Repita la transferencia con un único método de copia conocido y un nombre de archivo de destino nuevo. Guarde el registro de reintentos, reanudaciones, omisiones y fallos en lugar de depender del cuadro de progreso de un explorador de archivos.
Microsoft define SMB como un protocolo que permite a las aplicaciones leer, crear y actualizar archivos remotos. Su modelo de acceso a archivos SMB permite considerar una suma de comprobación cambiada como un problema de la ruta de datos o de un escritor, no como una transformación esperada del protocolo.
Si una copia registrada desde la línea de comandos coincide y la de arrastrar y soltar no, compare la aplicación, el comportamiento de los reintentos, el tratamiento de archivos parciales, el análisis antivirus y el procesamiento posterior a la copia en lugar de cambiar el servidor SMB.
Compare el destino antes de que los indexadores o las aplicaciones lo reescriban
Calcule el hash del destino inmediatamente después de la copia, mientras esté cerrado y antes de que los analizadores multimedia, los convertidores de documentos, los gestores de fotos, las herramientas antivirus o los clientes de sincronización puedan modificarlo.
La guía de Robocopy de Oregon State destaca la copia registrada y reanudable, que establece un límite más claro entre la finalización de la transferencia y las acciones posteriores de las aplicaciones sobre el destino.
Si el hash inmediato del destino coincide pero cambia después, identifique el primer proceso que abra el archivo para escribir. La solución permanente corresponde al comportamiento de esa aplicación respecto a los metadatos, la optimización o la sincronización.
Repita la prueba a través de los límites del almacenamiento y la red
Copie el mismo archivo de prueba cerrado localmente en el NAS de origen, localmente en el sistema de archivos de destino, mediante SMB desde otro cliente y mediante el cliente original. Calcule el hash después de cada paso.
La guía de ZimaSpace sobre la conservación de metadatos durante la migración de un NAS proporciona la regla relacionada: los hashes del contenido y los campos de metadatos deben validarse como criterios de aceptación independientes.
El problema se resuelve cuando un archivo de origen cerrado produce hashes coincidentes en copias repetidas y permanece sin cambios después de ejecutar los servicios posteriores a la copia. Detenga la migración y proteja el origen si las discrepancias siguen a un disco, controlador, cliente o desplazamiento de archivo reproducible concreto.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
