Wie kann verhindert werden, dass Samba eine Dateisperre hält, nachdem ein Client die Verbindung getrennt hat?

11

Hier habe ich einen Samba-Server (Debian 5.0), der zum Hosten von Windows XP-Profilen konfiguriert ist.

Clients stellen eine Verbindung zu diesem Server her und bearbeiten ihre Profile direkt auf der Samba-Freigabe (das Profil wird nicht lokal kopiert).

Hin und wieder wird ein Client möglicherweise nicht ordnungsgemäß heruntergefahren, sodass Windows die Dateisperren nicht aufhebt. Wenn wir uns die Samba-Sperrtabelle ansehen, sehen wir, dass viele Dateien immer noch gesperrt sind, obwohl der Client nicht mehr verbunden ist. In unserem Fall scheint dies bei von Mozilla Thunderbird und Firefox erstellten Sperrdateien der Fall zu sein. Hier ist ein Beispiel für die Samba-Sperrtabelle:

# smbstatus -L | grep DENY_ALL | head -n5
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
15494        10345      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user1   app.profile/user1.thunderbird/parent.lock   Mon Nov 22 07:12:45 2010
18040        10454      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user2   app.profile/user2.thunderbird/parent.lock   Mon Nov 22 11:20:45 2010
26466        10056      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user3   app.profile/user3.firefox/parent.lock   Mon Nov 22 08:48:23 2010

Wir können sehen, dass die Dateien von Windows geöffnet wurden und eine DENY_ALL-Sperre auferlegt haben.

Wenn sich ein Client erneut mit dieser Freigabe verbindet und versucht, diese Dateien zu öffnen, gibt Samba an, dass sie gesperrt sind, und verweigert den Zugriff.

Gibt es eine Möglichkeit, diese Situation zu umgehen, oder fehlt mir etwas?

Edit: Wir möchten , dass Dateisperren zu deaktivieren auf dem Samba - Server vermeiden , weil es gibt gute Gründe , diejenigen zu aktivieren.

linux samba server-message-block

— Jean-Francois Chevrette
quelle

11

Die folgenden Schritte haben mir bei mehreren Gelegenheiten geholfen, genau dieses Problem zu lösen:

Melden Sie sich beim Samba-Server an.
Führen Sie einen "smbstatus" aus.
Suchen Sie im dritten Abschnitt der Ausgabe die PID des Prozesses, bei dem die Datei gesperrt ist.
Stellen Sie sicher, dass es mit dem erwarteten Benutzer- und Hostnamen im ersten und zweiten Abschnitt der smbstatus-Ausgabe übereinstimmt.
Führen Sie "ps -ef" aus und sehen Sie, wie lange die smbd mit dieser PID ausgeführt wurde.
Wenn es seit dem letzten Neustart des Computers ausgeführt wurde, ist es ein übrig gebliebener smbd. Töte nur diesen einen smbd. (Und stellen Sie sicher, dass Sie die richtige erhalten - es sollte eine sein, deren Eltern-PID ungleich 1 ist.)

— Socceroos
quelle

Möglicherweise werden auch einige smbd-Pids einige Stunden lang ausgeführt, und die gesperrten Dateien sind die, die Sie benötigen. Wie oben, töten Sie einfach diese Prozesse und es sollte Ihnen gut gehen. Wenn Sie versehentlich den Haupt-SMBD-Prozess beenden, können Sie ihn mit dem folgenden Befehl neu starten: sudo /etc/init.d/smbd restart

— Socceroos

5

Schauen Sie sich an:

reset on zero vc = yes / no

und sehen Sie, ob dies Ihr Problem beheben wird oder nicht.

Von der smb.confManpage:

Diese boolesche Option steuert, ob ein Setup für eingehende Sitzungen andere Verbindungen beenden soll, die von derselben IP stammen. Dies entspricht dem Standardverhalten von Windows 2003. Das Setzen dieses Parameters auf yes ist erforderlich, wenn Sie ein flockiges Netzwerk haben und Windows beschließt, die Verbindung wiederherzustellen, während in der alten Verbindung noch Dateien mit geöffneten Freigabemodi vorhanden sind. Auf diese Dateien kann über die neue Verbindung nicht mehr zugegriffen werden. Der Client sendet eine VC von Null für die neue Verbindung, und Windows 2003 beendet alle anderen Verbindungen, die von derselben IP stammen. Auf diese Weise kann wieder auf die gesperrten Dateien zugegriffen werden. Bitte beachten Sie, dass durch Aktivieren dieser Option Verbindungen hinter einem maskierenden Router unterbrochen werden.

Edit :
Ich habe gerade über eine andere mögliche Lösung nachgedacht. Sie könnten so etwas für die betreffende Aktie tun.

veto oplock files = /*.lock/

Dies würde nur Oplocks für .lock-Dateien verhindern.

— 3dinfluence
quelle

0

Einige sehr kluge Leute bei Samba haben beschlossen, diese Option zu entfernen, und es gibt keinen Ersatz dafür.

Bisher für die SMB-Kompatibilität, da dies in der Tat das Standard-Gewinnverhalten ist.

Sofern ein Benutzer nicht mit der Linux-Befehlszeile vertraut ist und nicht weiß, wie geöffnete Dateien / Prozesse beendet werden, müssen Sie SMBD oder den Server selbst neu starten, um dies zu löschen.

Wunderbar gemacht, Samba.org.

— Michael
quelle

Hast du ein Zitat dafür?

— BE77Y

Sie müssen sich ein paar ansehen, um dorthin zu gelangen, aber: lists.samba.org/archive/samba-technical/2011-July/078621.html (zeigen Sie den Denkprozess und die Jungs , die dafür plädieren, dass er nicht entfernt wird) Listen .samba.org / archive / samba-technisch / 2008-Oktober /… (zeigt, dass der Parameter in 4.0 entfernt wurde)

— Michael

Ab 2019 ist die reset on zero vcOption in Debian 9 - Samba 4.5.12 weiterhin im Handbuch aufgeführt und wird auch von angezeigt testparm. Entweder ist es zurück oder es wurde wirklich nicht entfernt.

— Mivk

0

Ich hatte ein ähnliches Problem, ein Client stürzte beim Kopieren einer großen Datei ab und die Datei wurde nach dem Neustart gesperrt. Glücklicherweise passiert dies nicht sehr oft, aber es ist trotzdem ziemlich ärgerlich, den Samba-Prozess abbrechen zu müssen. reset on zero vcschien nur die Lösung zu sein, aber es wurde angeblich aus Samba4 entfernt, obwohl Version 4.7.6 auf Fedora (27) es noch hat (möglicherweise von RH gepatcht). Es wird sowieso nicht viel helfen, wie die Manpage jetzt sagt, dass es nur mit SMB1 funktioniert (das nicht mehr verwendet werden sollte) und nichts mit SMB2- und SMB3-Verbindungen tut. Die einzige Möglichkeit, dies zu handhaben, wird in erwähnt der von Micheal verlinkte Thread . Ich kenne die Gründe für die Entfernung nicht und weiß nicht, woran es so schlimm istreset on zero vcIch würde die Verwendung von TCP-Timeout für diesen Zweck eher als Hack betrachten. Jedenfalls könnte etwas Vernünftiges zB sein

socket options = TCP_NODELAY SO_KEEPALIVE TCP_KEEPIDLE=30 TCP_KEEPCNT=3 TCP_KEEPINTVL=3

Dadurch wird die Verbindung etwa 40 Sekunden (30 + 3 * 3) nach der letzten Kommunikation beendet. Dies ist normalerweise mehr als ausreichend, um einen Absturz und einen Neustart zu bemerken (vorausgesetzt, der TCP-Stack des Servers ist intelligent genug, um die Verbindung zu schließen, wenn der Client lehnt seine Keepalive-Pakete nach dem Neustart ab).

Beachten Sie, dass dies die Belastung Ihres Netzwerks erhöht, aber ich bezweifle, dass dies selbst bei vielen Clients spürbar ist.

— Jakob
quelle

Wissen Sie, ob dies bei dem bizarren Windows 10-Client-Zombie-Thread-Problem "Nobody Nogroup" hilft? Viele meiner Windows10-Clients an mehreren Standorten haben begonnen, Hunderte (gelegentlich Tausende) von Zombiethreads zu hinterlassen, die der "Niemand-Nogruppe" zugewiesen werden, bis ihr Handler-Prozess beendet wird / in den Ruhestand geht. Normalerweise würde das Setzen deadtime = 10oder so es löschen, aber da die Dateisperren für SMB3_11-Verbindungen für immer bestehen bleiben, hat dies keine Auswirkung, da die Totzeit nicht überprüft wird, solange noch Dateisperren für eine PID vorhanden sind. Extrem frustrierend.

— zxq9

Ich habe noch nie von dem von Ihnen beschriebenen Problem gehört oder es erlebt. deadtimetut nichts, wenn Ihre Clients Dateien geöffnet haben, daher wäre die Frage, welche Dateien sie offen halten. Aber das ist wahrscheinlich ein ganz anderes Thema als das hier diskutierte. Sie sollten daher eine neue Frage dazu stellen. Mein socket optionsVorschlag hilft nur bei Verbindungen, die nicht ordnungsgemäß geschlossen sind (weil die Clients abstürzen, ein Netzwerkausfall usw.), aber wahrscheinlich nicht, wenn Ihre WX-Clients nur ohne weitere Maßnahmen oder mithilfe einer anonymen Sitzung eine Verbindung zum Server herstellen (was nobody.nogroupdarauf hindeutet) ).

— Jakob

Es scheint eine Frage zu diesem Problem zu geben, aber ohne eine echte Lösung. Es klingt so, als könnte es sich um ein Samba-Problem handeln, das in einer neueren Version behoben werden könnte.

— Jakob

Es gibt einige Erwähnungen auf der Mailingliste, keine wirkliche Lösung, die irgendwo vorgestellt wird, und keine Version, die ich ausprobiert habe (jeder aktuelle Zweig außer 4.9), behebt das Problem. Es ist nur mit Windows10-Clients. Die Sache mit Nobody: Nogroup ist verwirrend, da Gäste global deaktiviert sind, keine Freigaben sie akzeptieren und die PID der Nobody-Einträge immer mit einem einzelnen gültigen Eintrag mit einem gültigen Benutzernamen identisch ist. Sie sehen also 12345 someuser somegroup...auf einem Eintrag 800 12345 nobody nogroup ...Einträge, aber nur eine Handvoll Dateisperren (nicht 800). Sehr merkwürdig. Betrifft jetzt 3 meiner Kundenstandorte.

— zxq9

Dies wird nur auf Websites mit hoher Aktivität zu einer Ressourcenbeschränkung, weshalb ich denke, dass dies so wenig Beachtung findet. Meistens gibt es kein Problem, daher bemerken die Leute es einfach nicht und es klärt sich irgendwie auf, wenn die Clients tatsächlich ihre Verbindung schließen.

— zxq9

0

Sie können Oplocks pro Aktie folgendermaßen deaktivieren:

[acctdata]
oplocks = False
level2 oplocks = False

Der Standard-Oplock-Typ ist Level1. Level2-Oplocks werden pro Aktie in der Datei smb.conf aktiviert. Alternativ können Sie Oplocks pro Datei innerhalb der Freigabe deaktivieren:

veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/

Wenn Sie Probleme mit Oplocks haben, wie aus Sambas Protokolleinträgen hervorgeht, sollten Sie auf Nummer sicher gehen und Oplocks und Level2-Oplocks deaktivieren.

Deaktivieren von Kernel-Oplocks Kernel-Oplocks ist ein Parameter von smb.conf, der Samba benachrichtigt (wenn der UNIX-Kernel einem Windows-Client eine Oplock-Unterbrechung senden kann), wenn ein UNIX-Prozess versucht, die zwischengespeicherte Datei zu öffnen. Dieser Parameter befasst sich mit der Freigabe von Dateien zwischen UNIX und Windows mit aktivierten Oplocks auf dem Samba-Server: Der UNIX-Prozess kann die vom Windows-Client Oplocked (zwischengespeicherte) Datei öffnen, und der smbd-Prozess sendet keine Oplock-Unterbrechung, für die die Datei verfügbar gemacht wird das Risiko der Datenkorruption. Wenn der UNIX-Kernel die Möglichkeit hat, eine Oplock-Unterbrechung zu senden, ermöglicht der Parameter Kernel-Oplocks Samba, die Oplock-Unterbrechung zu senden. Kernel-Oplocks werden pro Server in der Datei smb.conf aktiviert.

kernel oplocks = yes

Der Standardwert ist nein.

Quelle

— ajcg
quelle