Samba Sharing Problem

[.micha]

Hallo,

ich habe unter Suse OSS 10.0. ein recht eigentümliches Sharing Problem.

Jeder Client, der eine Datei öffnet, blockiert diese Datei für weitere Zugriff durch Sharing deny_dos.

Bisherige Tests:
share = on oder share=off
alle locking-Kombinationen
In der Windows Registry EnableOplocks=1 oder =0
Alles bewirkt keine Änderung. Jeder WIn-Client blockt die Datei komplett, unabhängig ob Win95/98 oder WinNT oder WinXP.

Swat sagt folgendes:
PID Sharing R/W Oplock Datei Datum
7933 DENY_DOS RDWR EXCLUSIVE+BATCH /mnt/prochem/Server/Kopie von Neu Microsoft Word-Dokument.doc Thu Jan 12 12:21:50 2006
7481 DENY_DOS RDWR EXCLUSIVE+BATCH /mnt/prochem/Server/Neu Microsoft Word-Dokument.doc Thu Jan 12 12:16:14 2006

Weiß jemand Rat?

Gruß
.micha

 

[stka]

Ein geöffnetes Dokument muss gesperrt sein, was würde passieren, wenn zwei Benutzer gleichzeitig das Dokument bearbeiten? Das Dokument kann von weiteren Benutzern nur read-only geöffnet werden.

 

[jengelh]

Man kann es abstellen (drei verschiedene Möglichkeiten), indem man dies in /etc/samba/smb.conf hinzufügt:

  oplocks = no
  posix locking = no
  locking = no

Manchmal hilft das ungemein, weil Linux-Programme meist hängen, bis Windowslocks wieder freigegeben werden!

 

[.micha]

Hallo stka, Hallo jengelh,

was den Tauschgang angeht, würde ich dir (stka) rechtgeben.
Ansonsten bin ich anderer Meinung. Die Kombination Linux-Server-Windows-Client erlaubt ja genau dieses. Wie sollten sonst mehrere Clients z.B. auf eine Access-Datenbank zugreifen, die auf einem Linux-Server liegt?

Linux gibt diverse Hilfen, um Kollisionen zu vermeiden wie Locking Oplocks, Byte Range Locking, Share mode...

Wie betreiben seit etlichen Jahren eine Access-Datenbank, die auf einem Suse-8.0-Server liegt. Der Zugriff klappt bestens. Normal sieht es so aus:

PID Sharing R/W Oplock File Date
20134 DENY_NONE RDWR NONE /backup/prochem/Lims/Stammdaten/prüfleiter.ldb Fri Jan 13 14:52:49 2006
19229 DENY_NONE RDWR NONE /backup/Vorlagen/Emissionsberichte/xxx_Meldung_Serie.dot Fri Jan 13 13:45:44 2006
20134 DENY_NONE RDONLY NONE /backup/prochem/Lims/Stammdaten/prüfleiter.mdb Fri Jan 13 14:52:49 2006
20134 DENY_NONE RDWR NONE /backup/prochem/Lims/lims.ldb Fri Jan 13 09:28:23 2006
31489 DENY_NONE RDWR NONE /backup/prochem/yyy/Literatur/xxxund andere/Inhaltsverzeichnis_xxx.doc Fri Jan 13 10:25:11 2006
20134 DENY_NONE RDWR NONE /backup/prochem/Lims/Gesichert.mdw Fri Jan 13 09:28:23 2006
20134 DENY_NONE RDWR NONE /backup/prochem/Lims/Auftragsverwaltung/auftrag.ldb Fri Jan 13 12:41:33 2006
20134 DENY_NONE RDWR NONE /backup/prochem/Kunden/Kd1501-2000/01543in/berichte/50896.doc Fri Jan 13 14:53:21 2006
20134 DENY_NONE RDONLY NONE /backup/prochem/Lims/Abfragen.mdb Fri Jan 13 12:41:20 2006
20134 DENY_NONE RDWR NONE /backup/prochem/Lims/Stammdaten/personal.ldb Fri Jan 13 13:10:34 2006
19229 DENY_NONE RDWR NONE /backup/prochem/Autorech/kunden.ldb Fri Jan 13 13:45:47 2006
20134 DENY_NONE RDWR NONE /backup/prochem/Autorech/kunden.ldb Fri Jan 13 11:06:31 2006
20134 DENY_NONE RDWR NONE /backup/prochem/Lims/Stammdaten/bestimmung.ldb Fri Jan 13 13:10:15 2006
20134 DENY_NONE RDWR NONE /backup/prochem/Autorech/lieferanten.ldb Fri Jan 13 13:06:55 2006
20134 DENY_NONE RDWR NONE /backup/prochem/Lims/Stammdaten/personal.mdb Fri Jan 13 13:10:34 2006
20134 DENY_NONE RDWR NONE /backup/prochem/Lims/Stammdaten/bestimmung.mdb Fri Jan 13 13:10:15 2006
20134 DENY_NONE RDWR NONE /backup/prochem/Lims/Abfragen.ldb Fri Jan 13 12:41:20 2006
19229 DENY_NONE RDWR NONE /backup/prochem/Emission/Anmeldung Messauftraege/hhh/2006/0604br_ppp.doc Fri Jan 13 13:58:33 2006
20134 DENY_WRITE RDONLY EXCLUSIVE+BATCH /mnt/home/Micha Laptop/D05 ddd/dddGold Master.iso Tue Jan 10 17:36:11 2006
20134 DENY_NONE RDONLY NONE /backup/prochem/Autorech/kunden.mdb Fri Jan 13 14:52:49

Alles bestens locking, oplocks und sharing so, wie es sein soll.

Da aber unser jetziger Server an Altersschwäche und Gicht leidet, ist es zeit, einen neuen aufzubauen. Größer, schneller, schöner.

Da bietet sich Suse OSS10.0 ja geradezu an.

Leider blockt bei OSS 10.0 Samba den Zugriff über den Share mode. Normal sollte er deny_none, deny_write, deny_all oder auch deny_read sein (deny_fcb kann man vergessen). Niemals jedoch deny_dos. Denn deny_dos erlaubt einem Client beliebig oft auf eine Datei zuzugreifen, sperrt jedoch alle anderen Clients komplett (auch Lesezugriffe, Ausnahmen sind ausführbare Dateien wie exe com dll u.a.), wenn der 1. Client schreibend zugreift.

Für eine Datenbank echt :evil:

Der Share mode erlaubt es eigentlich, den Clients das locking zu bestimmen. Und so doof Windoof auch sein mag, dieses beherrscht es normalerweise. Wie man ober sieht.

Posix locking betrifft eigentlich nur das locking, wenn zusätzlich z.B. über NFS zugegriffen wird.
locking auszuschalten ist keine gute Idee, da dann Datenverluste vorprogrammiert sind.
oplocks kann man ausschalten, hat aber Geschwindigkeitsvorteile.

Soweit die (graue) Theorie.

Das eigentümliche ist, dass ich alle Locking and sharing Varianten ohne Erfolg ausprobiert habe. Auch wenn diese nicht bewirken können, ist try und error doch manchesmal eine nützliche Methode.

Also alles, was in der smb.conf steht und share und lock im Namen hat aus oder an. Keine Änderung.

Tja, was nun?

Gruß
.micha

 

[Frankie777]

Welche Samba Version?

bei 3.0.21 gab es Probleme mit oplocks.

 

[.micha]

Probleme mit oplocks oder auch dem gesamten locking?

Ist jedenfalls die 3.0.20-b.

Gruß
.micha