¿Por qué un recurso compartido NAS muestra archivos antiguos después de reemplazar la carpeta?
Un recurso compartido NAS puede mostrar archivos antiguos cuando el cliente o el servicio de recursos compartidos sigue apuntando a un estado de directorio almacenado en caché o a la ruta anterior.
Reemplazar una carpeta en el NAS no garantiza que cada sesión SMB, aplicación, montaje, ruta inversa o espacio de nombres cambie de inmediato al nuevo árbol de directorios. Es posible que el servidor todavía exporte la ruta antigua, que el reemplazo se haya ubicado dentro de otro montaje o que el cliente conserve metadatos de directorio, información de archivos, identificadores abiertos o una referencia almacenada en caché. El diagnóstico más seguro compara la vista del sistema de archivos, el destino activo del recurso compartido y una sesión de cliente completamente nueva antes de modificar cualquier ajuste de caché.
Confirma qué capa sigue mostrando el árbol de directorios antiguo
Compara el cliente SMB afectado con el shell del NAS, el administrador de archivos web del NAS y un segundo cliente que no haya abierto recientemente el recurso compartido. Registra un nombre de archivo que debería haber desaparecido y otro nuevo que debería estar visible.
Si el shell del NAS y el administrador de archivos web también muestran el árbol antiguo, el problema está por debajo de SMB: el reemplazo se realizó en el directorio equivocado, falta un montaje esperado u otro conjunto de datos está cubriendo la ruta. IBM señala que las notificaciones de cambios de SMB dependen de cómo llegan los cambios al servicio de archivos, por lo que un solo cliente obsoleto no demuestra por sí mismo que los datos del servidor sean antiguos.
No actualices repetidamente el mismo explorador de archivos y lo consideres una prueba nueva. Una comparación significativa utiliza otro proceso del cliente, otra sesión de usuario o una vista directa del sistema de archivos local que no reutilice los mismos metadatos SMB.
Verifica el destino activo del recurso compartido después de reemplazar la carpeta
Inspecciona la configuración de recursos compartidos del servidor y resuelve la ruta exportada hasta su objeto real del sistema de archivos. Comprueba los montajes vinculados, los enlaces simbólicos, los puntos de montaje de conjuntos de datos, las asignaciones de volúmenes de contenedores y si la carpeta de reemplazo se creó antes o después de que se activara un montaje de almacenamiento.
Un fallo habitual ocurre cuando el administrador reemplaza archivos dentro de un directorio desmontado y, después, vuelve el montaje de almacenamiento real y oculta ese reemplazo. El manual de montaje de Linux explica que montar oculta la vista anterior del directorio mientras el sistema de archivos permanece conectado, por lo que la ruta visible debe comprobarse frente a la tabla de montajes activa.
La guía de migración de datos NAS de ZimaSpace proporciona la secuencia de verificación complementaria para demostrar que las rutas de origen y destino previstas contienen los datos esperados antes de eliminar la copia antigua.
Prueba las cachés SMB de directorios e información de archivos
Cierra todas las aplicaciones que utilicen el recurso compartido, desconecta la asignación SMB y establece una sesión nueva. Compara el resultado con un segundo equipo o una sesión de usuario nueva que no haya enumerado el directorio anteriormente.
Los clientes SMB de Windows pueden almacenar en caché los metadatos de directorio y la información de archivos durante un periodo configurado. La guía de Microsoft sobre ajustes de servidores de archivos explica que la duración de la caché de directorios controla cuánto tiempo pueden permanecer almacenados los metadatos cuando no hay concesiones de directorio disponibles.
Si una sesión nueva muestra inmediatamente el árbol correcto mientras que la sesión antigua no lo hace, los datos no faltan y el destino del recurso compartido probablemente es correcto. Vuelve a conectar correctamente el cliente afectado e investiga por qué su sesión no recibió o no respetó la notificación de cambios esperada antes de modificar globalmente los valores de caché.
Comprueba los identificadores abiertos, las concesiones y las aplicaciones de larga duración
Enumera las sesiones SMB activas y los archivos abiertos en el NAS. Los gestores multimedia, las aplicaciones de fotos, las herramientas de copia de seguridad, las ventanas del shell, los indexadores y los exploradores de archivos pueden mantener abiertos directorios o archivos mucho después de que finalice la operación de copia visible.
Cierra primero la aplicación y, después, desconecta únicamente la sesión SMB afectada. La documentación SMB de NetApp explica que los oplocks de concesión conservan el estado de la caché del cliente, por lo que desactivar las concesiones en todo el NAS es un cambio mucho mayor que restablecer una conexión obsoleta.
Si el árbol antiguo desaparece solo después de cerrar una aplicación concreta, conserva ese resultado y vuelve a probar la aplicación con la carpeta nueva. La corrección corresponde a su comportamiento de reconexión, supervisión o actualización, no al conjunto de almacenamiento.
Descarta las referencias DFS y los nombres de servidor duplicados
Comprueba si el cliente llegó al NAS mediante un nombre de host directo, una dirección IP, un alias DNS, un espacio de nombres DFS o un nombre de servidor antiguo que ahora se resuelve en otro lugar. Dos rutas que parecen similares en el explorador de archivos pueden terminar en destinos de recursos compartidos diferentes.
Los clientes DFS almacenan en caché las referencias de espacios de nombres y carpetas durante un periodo definido. Los clientes DFS también pueden conservar las referencias de espacios de nombres y carpetas durante cierto tiempo, lo que puede enviar temporalmente a un cliente a un destino antiguo después de un cambio en el espacio de nombres.
Compara la identidad del servidor, la dirección resuelta, el nombre del recurso compartido y la ruta final de las sesiones funcional y obsoleta. No vacíes todas las cachés de DNS y DFS hasta demostrar que el cliente afectado está llegando a un destino diferente.
Compara una ruta directa nueva con la ruta normal del usuario
Abre el recurso compartido una vez mediante el nombre de host habitual y otra mediante la dirección directa verificada del servidor, desde una sesión limpia del cliente. Utiliza esto solo como método de diagnóstico, no como sustituto permanente de un nombre de host administrado.
Si la ruta directa muestra el árbol nuevo mientras que el nombre habitual muestra el antiguo, centra la investigación en los alias, las referencias, las credenciales guardadas o un segundo NAS que utilice el mismo nombre. El modelo de rutas de mount.cifs de Debian demuestra por qué deben compararse el destino exacto del servidor y del recurso compartido y el punto de montaje local, en lugar de confiar en un nombre conocido que aparece en pantalla.
Compara también el número de archivos y el hash de un archivo entre la ruta local del NAS y la ruta SMB. Un archivo antiguo coincidente confirma una selección de ruta o caché; un archivo diferente con el mismo nombre apunta a un reemplazo incompleto, carpetas duplicadas o contenido generado por una aplicación.
Corrige el fallo mínimo y verifica que persista tras reiniciar
Corrige el destino del recurso compartido cuando exporte la carpeta equivocada, restaura el montaje que falte cuando la ruta esté cubierta incorrectamente, vuelve a conectar la sesión obsoleta del cliente cuando solo un cliente esté afectado o actualiza el destino DFS cuando el espacio de nombres siga haciendo referencia a la ubicación antigua.
Evita cambiar la duración de las cachés SMB, desactivar las concesiones o volver a crear el recurso compartido, a menos que una prueba controlada demuestre que esa capa es responsable. La vista de sesiones y bloqueos activos de Samba permite comprobar la conexión afectada antes de aplicar un cambio en todo el servidor.
El problema se resuelve cuando el shell del NAS, el administrador de archivos web, una sesión SMB nueva y la ruta normal del cliente muestran el mismo contenido de carpeta después de reiniciar el servicio y el equipo host. Mantén la carpeta antigua sin conexión, pero intacta, hasta superar esa verificación y confirmar que ninguna aplicación continúa escribiendo en ella.
Productos recomendados
Soporte y Consejos
Más para leer
¿Por qué restaurar un volumen de Docker recrea el contenido de los archivos, pero elimina los atributos extendidos?
Un diagnóstico de restauración de volúmenes que abarca el inventario de atributos extendidos, las opciones de tar y Rsync, los espacios de nombres, la...
¿Por qué un contenedor en ejecución mantiene su antiguo límite de memoria después de cambiar el archivo de Compose?
Un diagnóstico del límite de memoria que abarca los cgroups activos, el reinicio frente a la recreación, los campos de Compose, los límites estrictos...
¿Por qué reiniciar un proxy inverso invalida todas las sesiones de una aplicación autoalojada?
Un diagnóstico de pérdida de sesión que abarca el alcance del reinicio, la propiedad de las cookies, la rotación de secretos, las sesiones respaldadas...
