Ich habe mit oplocks auf einem ähnlichen Linux-System ähnliche Probleme, die zwar nicht so tragisch enden, aber auch unschön sind. Ich habe eine QNAP-NAS mit einer SAMBA 3.XXX drauf und Möglichkeit per WebIF pro share oplocks aktivieren/deaktivieren. Seit Anfang an waren sie aktiviert. Plötzlich bekam ich Probleme von meinem Technisat-Receiver per SAMBA auf einige Fotos zuzugreifen. Komischerweise könnte ich auf die Fotos von jedem beliebigen Windows-Rechner zugreifen. Aufgefallen war mir auch, dass speziell die Bilder Probleme machten, die ich von Windows aus auf der share von QNAP (also über SAMBA direkt) gedreht hatte. Sprich: Einer der Windows-Rechner hatte mal einen schreibenden Zugriff auf die Datei gehabt und seitdem ging es nicht.
Ich hatte schon alles Mögliche ausprobiert und den Dateien alle möglichen Rechte verpasst, es half nichts. Ich vermute den Fehler im Zusammenspiel zwischen dem Technisat / QNAP-SAMBA und den Windows-Rechner. Die Idee von oplocks besteht ja gerade darin, dass auf den Clients gewisse "lokalen" Kopien von den Dateien angelegt werden, sobald mehr als einen Zugriff auf die Datei erfolgen. Sollte sich bei einem der Clients was schreibmäßig ändern, sollten sich alle Clients irgendwie synchronisieren und die aktualisierten Kopien austauschen. Und genau das scheint irgendwie schief zu gehen, sodass die Clients auf ihren lokalen Kopien (die teilweise korrupt sind) beharren. Zumindest so scheint es bei meinem Technisat zuzugehen. Das blöde daran ist: Das nachträgliche setzen von oplocks auf "no" hat zumindest bei mir keine Verbesserung gebracht. Das einzige, was bei mir geholfen hat: Dateien per SAMBA und Windows von QNAP wegholen und wieder über SAMBA auf QNAP draufzuschreiben, sodass sie in einem anderen Verzeichnis liegen. Dann werden sie plötzlich auch vom Technisat gelesen.
Ich wollte mit diesem Beispiel nur darstellen, dass oplocks zwar eine gute Idee sind, die Realisierung ist aber zumindest jetzt noch so buggy, dass man es von Anfang an am besten auf "no" setzen sollte.
MfG
