Los clientes de Windows no actualizarán el archivo samba de Linux localmente si leen el archivo a intervalos <= 10 segundos

8

Si un cliente de Windows lee un archivo en un recurso compartido de Linux smb en un intervalo <= 10 segundos, el cliente de Windows mostrará información incorrecta (¿en caché?) De ese archivo.

He reproducido esto en múltiples sistemas.

Ejemplos de pasos para reproducir:

1) configurar Linux Samba Share - para este ejemplo, usando Debian e instalando Samba. ejemplo:

sudo mkdir /test
sudo chmod 777 /test

Además de smb.conf:

[test]    
read only = no    
locking = no    
path = /test/    
guest ok = yes

2) Asigne este directorio como una unidad en un cliente de Windows (esta prueba usará L :)

3) crea un archivo con algo de texto en el servidor samba

nano /test/test.txt
ORIGINAL

4) cree un archivo por lotes simple en la máquina de Windows para ver el archivo cada 5 segundos:

copy con test.bat
@echo off
cls
:1
type L:\test.txt
timeout 5
goto 1

5) ejecute el archivo por lotes, debe mostrar ORIGINAL cada 5 segundos.

6) en el servidor Linux, cambie el contenido del archivo

nano /test/test.txt
CHANGED

7) vea el archivo por lotes en ejecución en Windows, seguirá diciendo "ORIGINAL" cada cinco segundos y no "CAMBIADO" como lo ha hecho el archivo real.

8) finalice el archivo por lotes y espere ~ 15 segundos, O cambie el tiempo de espera a algo> 10 segundos, y se actualizará correctamente.

Espero haber explicado y esbozado cómo probar esto lo suficiente.

¿Alguien puede reproducir este comportamiento y / o sugerir cómo solucionarlo?

.

.

.

NOTAS

Linux Client> Linux SMB Host muestra el contenido de archivo adecuado.

Windows Client> Windows SMB Host muestra el contenido del archivo adecuado.

Es específicamente Windows Client> Linux SMB Host que no muestra el contenido de archivo adecuado en un intervalo de actualización de <= 10 segundos.

Todos los sabores de Windows que he probado con (Win7, Win10, Server2016) exhiben el mismo comportamiento.

También he probado diferentes protocolos en mi recurso compartido de samba 'NT1, SMB2, SMB3', y no cambian el comportamiento.

NOTA: Creo que es muy probable que sea un problema de Windows, pero no he recibido ninguna respuesta en technet o superusuario en una semana. Esto debería ser bastante fácil de probar, ¿alguien puede confirmar este comportamiento o decir lo contrario?

linux command-line windows samba R. StackUser
fuente
¡Hola! Quizás el cliente de Windows esté almacenando en caché el archivo. ¿Has intentado configurar un servidor de archivos de Windows para ver si se comporta igual? Sé que necesitas ventanas, pero estoy bromeando. La mejor solución: desinstalar Windows.
ncomputers
He probado esto en Server 2016 con la función del servidor de archivos instalada. Se produce el mismo comportamiento.
R. StackUser
Ok tal vez el siguiente paso sería probar la desactivación del almacenamiento en caché en el lado del servidor y en el lado del cliente ...
ncomputers

Respuestas:

8

Los valores predeterminados para las configuraciones relevantes son:

  • oplocks = yes
  • kernel oplocks = no

(Consulte la documentación de Samba smb.conf )

Puede deshabilitar oplocks, según otra respuesta .

Como alternativa, si está ejecutando un Linux O / S con un núcleo moderno (2.4 o posterior), puede dejar oplocks = yesy en vez añadir una línea a smb.confpara permitir bloqueos oportunistas del núcleo. Según la sección de oplocks del kernel (S) en la documentación:

El soporte de bloqueos de kernel permite que los bloqueos de Samba se rompan siempre que un proceso UNIX local o una operación NFS acceda a un archivo que smbd (8) ha bloqueado. Esto permite una consistencia completa de datos entre SMB / CIFS, NFS y acceso a archivos locales

Cuando oplocksy kernel oplocksse habilitan tanto, usted debe obtener un buen rendimiento (de almacenamiento en caché) y la invalidación de caché cuando se actualizan los archivos.

Para habilitar los bloqueos de kernel, agregue esta línea a su archivo de configuración de Samba:

kernel oplocks = yes
Sarga
fuente
1
En la primera parte de su respuesta, enfatiza que oplocksdebe estar deshabilitado. En la segunda parte, la cita dice habilitarlos junto con kernel oplocks. ¿Sería correcto sugerir que su ejemplo final debería tener no solo kernel oplocks = yessino también oplocks = yes?
roaima
@roaima, la configuración predeterminada es: oplocks = yesy kernel oplocks = no. Entonces no hay necesidad de agregar oplocks = yes; solo necesitamos especificar el kernel oplocksvalor.
Serge
2
Estaba pensando que tal vez, dado que la primera parte de su pregunta sugiere deshabilitarla, valdría la pena conectar eso en su propuesta final.
roaima