Samba - file locking ohne erkennbaren Grund

Ich grüße alle Mitadmins.

Hier eine Frage an die Sambaexperten.
Auf einem Sambaserver (aktuelle Version in SuSe Linux) liegt ein Skript, was von allen PCs der Windowsdomäne (Win10) genutzt wird.
Aus das Skript sind alle Nutzer nur read+execute berechtigt.
Es wird pro Stunde 10-20 Mal geöffnet.
Es fiel nun auf, dass das Skript plötzlich nicht mehr gestartet werden konnte, da die Skript-Datei vom Server laut smbstatus read-only gelockt war, was offenbar Ausführung verbietet.

Zur Frage: warum sollte ein wie auch immer geartetes clientseitiges Problem in der Lage sein, eine Datei dauerhaft zu locken, wenn doch nur ausgeführt wird und nicht geschrieben wird? Die Logik verschließt sich mir.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 73011934665

Url: https://administrator.de/contentid/73011934665

Ausgedruckt am: 22.11.2024 um 00:11 Uhr

14 Kommentare

Neuester Kommentar

Mahlzeit,
ich würde jetzt mal auf Opportunistic Locking tippen.

Mahlzeit ebenso.

Welchen Sinn ergäbe das bei einer Datei, auf die man nur read und execute hat?
Ursächlich ließ sich übrigens feststellen, dass zur Zeit des Problems die NIC am Client neu gestartet wurde.
Aber darum geht es nicht, es geht darum, ob man erklären und abstellen kann, dass der Server ein dauerhaftes Locking zulässt.

Was auch immer da passiert ist: es ist nicht richtig, dass der Server so vorgeht. Eine Datei darf nicht dauerhaft gelockt werden, da Clients ja auch mitunter abstürzen und der Sambabetrieb für andere Clients dennoch ungestört weitergehen muss.

Nochmal: die Datei blieb über Stunden gelockt, bis auf dem Server der zugehörige Prozess gekillt wurde.
Der NIC-Restart am Client hat den Sambaserver offenbar vor unbekannte Probleme gestellt und dieses Fehlverhalten provoziert.

Hast du eine deadtime definiert?

Nein, und das möchte ich auch nicht, da das global wirken würde, soweit ich weiß (oder?).

Die Deadtime gilt ja auch nur für Sessions, die bereits inaktiv sind. Damit kickt man keine aktiven Sessions raus. Wenn ein Client länger inaktiv war, hat er ja blitzschnell wieder eine neue Session aufgebaut. Wenn ein Client inaktiv wird, während er eine Datei offen hat, sollte die Datei ja auch nicht so lange gesperrt bleiben, bis der eine Client wieder mal online geht. Wenn ein Client eine Datei öffnet und dann offline geht, sollte er nicht damit rechnen, dass er am nächsten Tag diese Datei immer noch diesen Stand hat - erst recht nicht, wenn ständig mehrere Leute daran arbeiten. Also kannst du es testweise einfach mal probieren. Stelle es nicht auf zu gering. Ich hätte mal 60 Minuten vorgeschlagen.

Ok, zur Not.
Es wäre unschön, einen Workaround einzuführen für ein Fehlverhalten, dass man evtl. regulieren kann.
Ich hätte gerne eine Sambakonfig, die sagt: "bei Read-only-Dateien kein dauerhaftes Locking", denn das ergibt ja nun keinen Sinn.

Z.B. hiermit das OpLocking für bestimmte Dateitypen deaktivieren

veto oplock files = /*.ps1/*.cmd/

Gruß siddius

Na, das schaut doch gut aus, @7907292512.
Da ich das Fehlverhalten halbwegs gut reproduzieren konnte, werde ich das bei Zeiten testen.
Danke

Wieso wurde denn dann das OpLocking auf dem Share überhaupt in der Config des Shares aktiviert wenn es eh nur ein ReadOnly Share ist, oder nutzen das andere auch mit Schreibzugriff ?