Les clients Windows ne rafraîchiront pas le fichier samba Linux localement s'ils lisent le fichier à des intervalles <= 10 secondes

Si un client Windows lit un fichier sur un partage smb Linux à un intervalle <= 10 secondes, le client Windows affichera des informations incorrectes (mises en cache?) De ce fichier.

J'ai reproduit cela sur plusieurs systèmes.

Exemples d'étapes pour reproduire:

1) configurer le partage linux samba - pour cet exemple, utiliser Debian et installer samba. exemple:

sudo mkdir /test
sudo chmod 777 /test

Ajout de smb.conf:

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

2) Mappez ce répertoire en tant que lecteur dans un client Windows (ce test utilisera L :)

3) créer un fichier avec du texte sur le serveur samba

nano /test/test.txt
ORIGINAL

4) Créez un fichier batch simple sur la machine Windows pour afficher le fichier toutes les 5 secondes:

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

5) Exécutez le fichier batch, il devrait afficher ORIGINAL toutes les 5 secondes.

6) sur le serveur Linux, modifiez le contenu du fichier

nano /test/test.txt
CHANGED

7) afficher le fichier batch en cours d'exécution sur Windows, il dira toujours "ORIGINAL" toutes les cinq secondes, et non "CHANGÉ" comme le fait le vrai fichier.

8) fermez le fichier de commandes et attendez ~ 15 secondes, OU changez le délai d'attente à quelque chose> 10 secondes, et il se mettra à jour correctement.

J'espère que j'ai expliqué et expliqué comment tester cela suffisamment.

Quelqu'un peut-il reproduire ce comportement et / ou suggérer comment y remédier?

.

.

.

REMARQUES:

Client Linux> Hôte SMB Linux affiche le contenu de fichier approprié.

Client Windows> Hôte SMB Windows affiche le contenu de fichier approprié.

C'est spécifiquement Windows Client> Linux SMB Host qui n'affiche pas le contenu de fichier approprié à un intervalle de rafraîchissement <= 10 secondes.

Toutes les versions de Windows avec lesquelles j'ai testé (Win7, Win10, Server2016) présentent le même comportement.

J'ai également testé différents protocoles sur mon partage samba 'NT1, SMB2, SMB3', et ils ne changent pas le comportement.

REMARQUE: Je pense que c'est probablement un problème Windows, mais je n'ai reçu aucune réponse sur technet ou superutilisateur depuis une semaine. Cela devrait être assez facile à tester, quelqu'un peut-il confirmer ce comportement ou dire le contraire?

Les valeurs par défaut pour les paramètres pertinents sont:

• oplocks = yes
• kernel oplocks = no

(Voir la documentation de Samba smb.conf )

Vous pouvez désactiver les oplocks, selon une autre réponse .

Par ailleurs, si vous utilisez un système d' exploitation Linux / S avec un noyau moderne (2.4 ou plus récent), vous pouvez laisser oplocks = yeset place ajouter une ligne smb.confpour permettre oplocks du noyau. Selon la section oplocks (S) du noyau dans la documentation:

La prise en charge des oplocks du noyau permet d'interrompre les oplocks de Samba lorsqu'un processus UNIX local ou une opération NFS accède à un fichier que smbd (8) a verrouillé. Cela permet une cohérence complète des données entre SMB / CIFS, NFS et l'accès aux fichiers locaux

Lorsque oplockset kernel oplockssont tous deux activés, vous devriez obtenir de bonnes performances (de la mise en cache) et une invalidation du cache lorsque les fichiers sont mis à jour.

Pour activer les oplocks du noyau, ajoutez cette ligne à votre fichier de configuration Samba:

kernel oplocks = yes

J'ai résolu cela en plaçant

oplocks = False

dans mon smb.conf sous mes paramètres de partage.

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