Windows-Clients aktualisieren die Linux-Samba-Datei nicht lokal, wenn die Datei in Intervallen von <= 10 Sekunden gelesen wird

Wenn ein Windows-Client in einem Intervall von <= 10 Sekunden eine Datei auf einer Linux-SMB-Freigabe liest, zeigt der Windows-Client falsche (zwischengespeicherte?) Informationen zu dieser Datei an.

Ich habe dies auf mehreren Systemen reproduziert.

Beispielschritte zur Reproduktion:

1) Richten Sie die Linux-Samba-Freigabe ein - in diesem Beispiel mit Debian und der Installation von Samba. Beispiel:

sudo mkdir /test
sudo chmod 777 /test

smb.conf zusätzlich:

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

2) Ordnen Sie dieses Verzeichnis als Laufwerk in einem Windows-Client zu (dieser Test verwendet L :)

3) Erstellen Sie eine Datei mit Text auf dem Samba-Server

nano /test/test.txt
ORIGINAL

4) Erstellen Sie eine einfache Batchdatei auf einem Windows-Computer, um die Datei alle 5 Sekunden anzuzeigen:

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

5) Batch-Datei ausführen, sollte alle 5 Sekunden ORIGINAL anzeigen.

6) Ändern Sie auf dem Linux-Server den Dateiinhalt

nano /test/test.txt
CHANGED

7) Wenn Sie die laufende Batch-Datei unter Windows anzeigen, wird weiterhin alle fünf Sekunden "ORIGINAL" und nicht "GEÄNDERT" wie in der realen Datei angezeigt.

8) Beenden Sie die Batch-Datei und warten Sie ~ 15 Sekunden, ODER ändern Sie das Zeitlimit auf etwas> 10 Sekunden, und es wird ordnungsgemäß aktualisiert.

Hoffentlich habe ich erklärt und skizziert, wie man dies ausreichend testet.

Kann jemand dieses Verhalten reproduzieren und / oder vorschlagen, wie dies behoben werden kann?

.

.

.

ANMERKUNGEN:

Linux Client> Linux SMB Host zeigt den richtigen Dateiinhalt an.

Windows Client> Windows SMB Host zeigt den richtigen Dateiinhalt an.

Es ist speziell Windows Client> Linux SMB Host, der in einem Aktualisierungsintervall von <= 10 Sekunden nicht den richtigen Dateiinhalt anzeigt.

Alle Windows-Varianten, mit denen ich getestet habe (Win7, Win10, Server2016), zeigen dasselbe Verhalten.

Ich habe auch verschiedene Protokolle auf meiner Samba-Freigabe 'NT1, SMB2, SMB3' getestet, die das Verhalten nicht ändern.

HINWEIS: Ich glaube, dass dies höchstwahrscheinlich ein Windows-Problem ist, aber ich habe seit einer Woche keine Antworten auf Technet oder Superuser erhalten. Dies sollte ziemlich einfach zu testen sein. Kann jemand dieses Verhalten bestätigen oder etwas anderes angeben?

Die Standardwerte für die relevanten Einstellungen sind:

• oplocks = yes
• kernel oplocks = no

(Siehe Dokumentation zu Samba smb.conf )

Sie können Oplocks gemäß einer anderen Antwort deaktivieren .

Wenn Sie ein Linux-Betriebssystem mit einem modernen Kernel (2.4 oder neuer) ausführen , können Sie alternativ eine Zeile verlassen oplocks = yesund stattdessen hinzufügen smb.conf, um Kernel-Oplocks zu aktivieren. Wie pro Kern oplocks (S) Abschnitt in der Dokumentation:

Durch die Unterstützung von Kernel-Oplocks können Samba-Oplocks unterbrochen werden, wenn ein lokaler UNIX-Prozess oder eine NFS-Operation auf eine Datei zugreift, die von smbd (8) blockiert wurde. Dies ermöglicht eine vollständige Datenkonsistenz zwischen SMB / CIFS, NFS und lokalem Dateizugriff

Wenn oplocksund kernel oplocksbeide aktiviert sind, sollten Sie eine gute Leistung (durch Caching) und eine ungültige Cache-Ungültigkeit erzielen, wenn die Dateien aktualisiert werden.

Fügen Sie diese Zeile Ihrer Samba-Konfigurationsdatei hinzu, um Kernel-Oplocks zu aktivieren:

kernel oplocks = yes

Ich habe das durch Platzieren gelöst

oplocks = False

in meiner smb.conf unter meinen Freigabeeinstellungen.

https://www.samba.org/samba/docs/old/Samba3-HOWTO/locking.html#id2615926