I client Windows non aggiornano il file samba Linux localmente se leggono il file a intervalli <= 10 secondi


8

Se ho un client Windows che legge un file su una condivisione SMB Linux a intervalli <= 10 secondi, il client Windows mostrerà informazioni errate (memorizzate nella cache?) Di quel file.

L'ho riprodotto su più sistemi.

Passaggi di esempio per riprodurre:

1) configurare la condivisione samba di Linux - per questo esempio, usare Debian e installare samba. esempio:

sudo mkdir /test
sudo chmod 777 /test

aggiunta smb.conf:

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

2) Mappa questa directory come unità in un client Windows (questo test utilizzerà L :)

3) crea un file con del testo sul server samba

nano /test/test.txt
ORIGINAL

4) creare un semplice file batch sul computer Windows per visualizzare il file ogni 5 secondi:

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

5) eseguire il file batch, dovrebbe mostrare ORIGINAL ogni 5 secondi.

6) sul server Linux, modificare il contenuto del file

nano /test/test.txt
CHANGED

7) visualizza il file batch in esecuzione su Windows, continuerà a dire "ORIGINALE" ogni cinque secondi, e non "CAMBIATO" come ha il file reale.

8) termina il file batch e attendi ~ 15 secondi, O cambia il timeout in qualcosa> 10 secondi e si aggiornerà correttamente.

Spero di aver spiegato e delineato come testarlo sufficientemente.

Qualcuno può riprodurre questo comportamento e / o suggerire come risolverlo?

.

.

.

APPUNTI:

Client Linux> Host SMB Linux mostra il contenuto del file corretto.

Client Windows> L'host SMB di Windows mostra il contenuto del file corretto.

È specificamente client Windows> Host SMB Linux che non mostra il contenuto del file corretto a un intervallo di aggiornamento di <= 10 secondi.

Tutte le versioni di Windows che ho provato con (Win7, Win10, Server2016) mostrano lo stesso comportamento.

Ho anche testato protocolli diversi sulla mia condivisione samba 'NT1, SMB2, SMB3' e non cambiano il comportamento.

NOTA: credo che questo sia molto probabilmente un problema di Windows, ma non ho ricevuto alcuna risposta su technet o superutente in una settimana. Questo dovrebbe essere abbastanza facile da testare, qualcuno può confermare questo comportamento o dichiarare diversamente?


Ciao! Forse il client Windows memorizza nella cache il file. Hai provato a configurare un file server Windows per vedere se si comporta allo stesso modo. So che hai bisogno di Windows, ma sto solo scherzando. La migliore soluzione di sempre: disinstallare Windows.
— ncomputers

Ho provato questo su Server 2016 con il ruolo di File Server installato. Si verifica lo stesso comportamento.
— R. StackUser,

Ok forse il prossimo passo sarebbe testare la disabilitazione della cache sul lato server e sul lato client ...
— ncomputers

Risposte:


8

I valori predefiniti per le impostazioni pertinenti sono:

  • oplocks = yes
  • kernel oplocks = no

(Vedi documentazione Samba smb.conf )


È possibile disabilitare gli oplock, come per un'altra risposta .

In alternativa, se stai eseguendo un sistema operativo Linux con un kernel moderno (2.4 o più recente), puoi lasciare oplocks = yese invece aggiungere una linea smb.confper abilitare gli oplock del kernel. Come da sezione oplock del kernel (S) nella documentazione:

Il supporto degli oplock del kernel consente di interrompere gli oplock di Samba ogni volta che un processo UNIX locale o un'operazione NFS accede a un file che smbd (8) ha bloccato. Ciò consente la completa coerenza dei dati tra SMB / CIFS, NFS e accesso ai file locali

Quando oplockse kernel oplockssono entrambi abilitati, dovresti ottenere buone prestazioni (dalla cache) e invalidare la cache quando i file vengono aggiornati.

Per abilitare gli oplock del kernel, aggiungi questa linea al tuo file di configurazione di Samba:

kernel oplocks = yes

1
Nella prima parte della tua risposta sottolinei che oplocksdovrebbe essere disabilitato. Nella seconda parte la citazione dice abilitarli insieme a kernel oplocks. Sarebbe giusto suggerire che il tuo esempio finale non dovrebbe avere solo kernel oplocks = yesma anche oplocks = yes?
— roaima,

@roaima, la configurazione predefinita è: oplocks = yese kernel oplocks = no. Quindi non è necessario aggiungere oplocks = yes; dobbiamo solo specificare il kernel oplocksvalore.
— Serge,

2
Stavo solo pensando che forse dato che la prima parte della tua domanda suggerisce di disabilitarla, varrebbe la pena collegarla nella tua proposta finale.
— roaima,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.