In heterogener Umgebung ist SMB das Protokoll der Wahl. Gegenüber NFS authentifiziert es seine Benutzer auf dem Server. Intern ist SMB aber reichlich verworren – Samba-Experten vermuten, dass selbst Microsofts eigene Dokumentation riesige Löcher hat.

Das Server-Message-Block-Protokoll zu beschreiben ist in weiten Teilen unmöglich (siehe Kasten “SMB war BAF”). Die Kommunikation zwischen zwei Windows- oder Samba-Rechnern “Protokoll” zu nennen, schon das halten viele für euphemistisch. Intern ist SMB letztlich eine Sammlung von Sonderfällen und historisch bedingten Ausnahmen. Trotzdem oder gerade deshalb ist es spannend zu sehen, womit sich das Samba-Team[1] herumschlägt.

Samba ist die wohl wichtigste unabhängige SMB-Implementation. Wahrscheinlich ist sie sogar die vollständigste, die ohne interne Informationen von Microsoft entwickelt wurde. Samba realisiert die Aufgaben auf jedem Unix-Server ohne Lizenzkosten. Als GPL-Software steht sie im Quellcode bereit, jedermann darf sie inspizieren und verändern.

Der Großteil der Kommunikation zwischen Microsoft-Systemen läuft per SMB ab. SMB und benachbarte Protokolle bewirken, sehr vereinfacht gesagt, dass andere Rechner in der Netzwerkumgebung eines Clients auftauchen und dort Dienste anbieten. Das sind unter anderem:

• Dateifreigaben machen die Festplatten eines Servers für
  Workstations im LAN transparent verfügbar. Diese Anwendung ist
  die wichtigste Rechtfertigung für SMB.
• Druckfreigaben stellen für die SMB-Clients entfernte
  Drucker ins Netz. Seit Windows NT gibt es dafür zwei
  gänzlich unterschiedliche Varianten.
• Beim Browsing erhalten SMB-Rechner sowohl die Liste von
  Rechnern in einer Arbeitsgruppe oder Domäne als auch deren
  Freigabeliste.
• Bei der Authentifizierung per SMB überprüft der
  zuständige Server im Auftrag des Clients das Passwort.
• Zur Autorisierung stellt das SMB-Protokoll in verschiedenen
  Varianten eine Benutzerdatenbank zur Verfügung, anhand derer
  die Clients nach erfolgter Authentifizierung lokale Zugriffsrechte
  steuern.
• Named Pipes über SMB sind ein allgemeines,
  zuverlässiges Transportmedium für Daten.

Unter Unix funktioniert eine Named Pipe nur zwischen lokalen Prozessen. Selbst Pipes auf einem NFS-Volume übertragen keine Daten von Rechner zu Rechner. Windows dagegen tut dies über Rechnergrenzen hinweg.

Named Pipes bilden die Grundlage für die Microsoft-Variante der Remote Procedure Calls im Distributed Computing Environment, den MS-RPCs. Einige der genannten Aufgaben des SMB-Protokolls sind als RPCs implementiert. Vermutlich werden RPCs in Zukunft mehr und mehr Aufgaben übernehmen. Schon heute sind RPC-Schnittstellen ein essenzieller Bestandteil jedes SMB-Servers.

In seiner Grundidee ist SMB ein klassisches Client-Server-Protokoll. Der Client stellt eine Anfrage, der Server antwortet. Herr Feigenbaum und alle folgenden Entwickler (siehe Kasten “SMB war BAF”) haben zum Glück bei jedem Schritt genügend Raum für Erweiterungen gelassen. Manche aktuelle Extension folgt dem Anfrage-Antwort-Schema nicht mehr uneingeschränkt.

Basis-Paketformat

Abbildung 1 zeigt den Aufbau jedes SMB-Paketheaders. Die tiefen Details, welche Bytes in welcher Reihenfolge auf dem Netz auftauchen, sind nur für SMB-Entwickler wichtig. Eine gute Paketformat-Referenz ist der Quellcode von Samba 4. Im Gegensatz zu Version 3 trennt Samba 4 die Umsetzung der Pakete auf dem Netz sauber von der verwendeten Semantik. Die wesentlichen Felder im SMB-Header tauchen sowohl in den Anfragen als auch in den Antworten auf, obwohl beispielsweise die Fehlercodes nur in Antworten Sinn haben.

Abbildung 1: Die wesentlichen Felder im SMB-Header tauchen sowohl in Anfrage-Paketen als auch in den Antworten auf.

Das SMB-Kommando ist das Byte, das den ganzen Rest festlegt. Es fängt bei der »0« mit dem Kommando »MKDIR« an, »1« ist »RMDIR«, »2« ist »OPEN« und so weiter. Von den möglichen 256 Kommandos sind in Samba 4 zurzeit 66 mit Code hinterlegt. Es ist zu vermuten, dass irgendwelche (Windows-)SMB-Server mehr als die 66 Befehle für unklare Aufgaben benutzen.

Jeder Request kann einen Fehler als Antwort geben. Die folgenden 4 Bytes sind Statusbytes, die die Fehlerart genau spezifizieren. Es gibt zwei Hauptarten, ein Bit der nachfolgenden Flag-Felder bestimmt die aktuelle.

Die alten DOS-Error-Codes bestehen aus 2 Byte für die Fehlerklasse und 2 Byte mit dem eigentlichen Fehler. Windows NT führte ein neues Schema von Fehlerklassifizierungen ein, die NT-Fehlercodes. Sie sind in einem geschlossenen 32-Bit-Feld dargestellt. Für eine Untermenge gibt es eine 1:1-Abbildung zwischen DOS- und NT-Fehlercodes, die aussagekräftigeren Fehler bekommt jedoch, wer NT-Fehlercodes aushandelt. Samba 2.2 und früher handeln DOS-Fehlercodes aus, Samba 3 und 4 benutzen die moderneren NT-Fehlercodes.

An die Fehlercodes schließen zwei Flagfelder an, einmal 1 und einmal 2 Byte. Sie legen unter anderem fest, ob die Dateinamen in diesem Paket Ascii mit einer Codepage-Definition oder Unicode sind. Bis XP verwenden alle Windows’ bei Unicode UCS-2, Windows 2003 und XP Service Pack 1 haben zu UTF-16 gewechselt, das analog zu Ascii/UTF-8 im Bereich von UCS-2 kompatibel ist.

Flag-Analyse mit Ethereal

Wer sich die restlichen Flagfelder erschließen will, kann Ethereal[6] ein paar Kommentare entlocken. Letztlich muss man sich die Bits mit Probieren ersniffen, da Ethereal teilweise verwirrend oder falsch Auskunft erteilt. Ethereal deklariert die auf die Kodierungsflags folgenden 12 Byte als reserviert. Die mittleren 8 Byte nehmen SMB-Signaturen auf (siehe Abbildung 2), sie verhindern, dass Angreifer eine authentifizierte Verbindung übernehmen können.

Windows ab NT 4 Service Pack 4 unterstützt SMB-Signaturen, Windows 2003 ist als Domänencontroller (DC) das erste Betriebssystem, das sie per Default erzwingt. Windows 2003 als DC überträgt nämlich Teile der Active-Directory-Gruppenrichtlinien über das SMB-Protokoll an seine Domänenmitglieder. Die Gruppenrichtlinien erzwingen auf den Mitgliedern privilegierte Operationen. Jemand, der die SMB-Verbindung während eines Domänenlogins übernimmt, könnte so die Kontrolle über ein Domänenmitglied erhalten.

Samba 2.2 kennt keine SMB-Signaturen, weshalb es ohne Modifikation der Registry des Domänencontrollers eine Windows-2003-Domäne nicht betreten kann. Samba 3 dagegen beherrscht Signaturen sowohl als Client als auch als Server.

Kontext im SMB-Protokoll

Ein Unix-NFS-Client mit NFS öffnet nur eine einzige Verbindung zu seinem Fileserver. Das tut ein Windows-Terminalserver zu einem SMB-Dateiserver auch. Ein wesentlicher Unterschied zwischen NFS und SMB ist aber, dass ein SMB-Server nicht blind dem Client vertraut, er habe die User vernünftig authentifiziert. Ein SMB-Server verlangt für jeden User auf dem Client eine eigene Authentifizierung und führt die Zugriffskontrollen für jeden User Server-seitig durch.

Das heißt: Eine SMB-Verbindung multiplext Anfragen im Auftrag unterschiedlicher Benutzer. Genau dafür ist das Feld »UID« im SMB-Header gemacht. Ein Benutzer authentifiziert sich und der Server weist ihm für diese eine Sitzung eine temporäre UID zu. (Sie hat nichts mit den Unix-UIDs zutun.) Der Client schreibt sie in den SMB-Request, wenn eine entsprechende Anfrage eintrifft.

TID, PID und MID

Das Feld »TID« bezeichnet die Tree-ID: Jeder Benutzer kann sich innerhalb einer SMB-Verbindung an beliebig viele Freigaben verbinden, jedenfalls bis zum Limit von 2¹⁶. In der Antwort zum Tree Connect, der eigentlichen Verbindung zu einer Freigabe, liefert der Server dem Client eine Tree-ID, die den Pfad der Freigabe für die Sitzung angibt.

Das Feld »PID« transportiert die ID des Prozesses auf dem Client, der den Request initiiert hat. Diese Nummer ist für die Byte Range Locks wichtig: Die Kombination aus SMB-Session, Tree-ID und PID bezeichnet den Lock Context, der das Verhalten von Byte Range Locks bestimmt. Daneben gibt es einen Request »SMBexit«, mit dem ein SMB-Client alle von einem bestimmten Prozess geöffneten Dateien schließt.

Abbildung 2: Der Paket-Sniffer Ethereal listet Flags und die Signatur eines SMB-Pakets.

Das Feld »MID« bezeichnet eine Anfrage eindeutig, ähnlich der LDAP-Message-ID. Das erlaubt es dem Server, Anfragen des Clients in einer beliebigen Reihenfolge zu beantworten. Windows als Server ist vermutlich multi-threaded und ein Pool von Worker-Threads wartet auf eingehende SMB-Anfragen. Wenn nun eine schnell zu beantwortende Anfrage nach einer aufwändigeren hereinkommt, kann der Server die Antworten in umgekehrter Reihenfolge verschicken.

Das kann etwa beim Video-Streaming von Dateien, die auf einem Samba-Server liegen, problematisch sein. Der streamende Client verlangt Daten sehr stetig, Samba liefert sie auch einwandfrei. Wenn aber mittendrin jemand im Dateisystem arbeitet, kommt das Video ins Stocken. Richtig wäre, wenn der Server die Beantwortung der zweiten Anfrage zu Gunsten des Streams zurückstellte. Das müssen jedoch Client und Server unterstützen. Windows-Clients tun dies, Samba 3 als Server leider nicht. Samba 4 ist für die Multi-threaded-Struktur besser geeignet.

Abhängig vom einzelnen Kommando wird der SMB-Request durch weitere Daten ergänzt. Ist zum Beispiel ein Verzeichnis mit dem Kommando »0« zu erzeugen, muss natürlich der Name des Verzeichnisses angegeben werden. Die anderen Parameter aller Requests kann man grob in Parameter und Datenwörter einteilen, die genaue Aufschlüsselung ufert wegen der sehr individuellen Ausführung aber schnell aus.

SMB-Sitzungen

Für die Fehlerdiagnose in jeder möglichen Windows-Samba-Kombination ist es sinnvoll, den Anfang der Kommunikation zwischen Client und Server verstanden zu haben. Besonders die Authentifizierungsprobleme werden in den ersten paar Paketen deutlich. Wie die meisten Protokolle arbeitet SMB nach dem Schema: Die Clients fragen an, der Server antwortet. SMB verlässt sich dabei auf ein darunter liegendes zuverlässiges Transportprotokoll, zum Beispiel den Sitzungsdienst Netbios oder das heute gebräuchliche TCP.

Ein SMB-Server bietet seine Dienste auf den Ports 139 und 445 an, wobei es nicht ganz korrekt ist, SMB auf Port 139 als TCP-basiertes SMB zu bezeichnen. Vielmehr lauscht hier der Netbios-Sitzungsdienst, wenn nach RFC 1001/1002 Netbios über TCP/UDP angeboten wird [4]. SMB auf Port 445 dagegen ist reines SMB ohne Netbios-Schicht. In der Praxis ist es völlig egal, ob SMB auf Port 139 oder 445 angeboten wird, moderne Clients schicken ohnehin gleichzeitig SYN- Pakete an beide Ports, wenn sie sich mit einem Server verbinden wollen. Der für die Samba-Konfiguration relevante Unterschied besteht darin, dass der Parameter »%L« bei Port 445 unzulässig ist.

Negotiate Protocol

Das Anfordern von Serverdiensten läuft in Schritten ab, deren Reihenfolge vorgeschrieben ist. Angenommen der Client hat die IP-Adresse des Servers herausbekommen und bereits die TCP-Verbindung aufgebaut. Zuerst handeln Client und Server die Protokollvariante aus, die beide beherrschen. Bei diesem Request, dem Negotiate Protocol, schickt der Client eine Liste seiner Protokollversionen an den Server (Abbildung 3). Die haben sprechende Namen wie PC NETWORK PROGRAM 1.0 oder NT LM 0.12. DOS, die ersten Versionen von LAN Manager sprachen CORE miteinander.

Seine ursprüngliche Bedeutung hat das Negotiate Protocol verloren, da heute alle Clients und Server immer »NT LM 0.12« aushandeln. Alle Samba-Clients bieten die Protokollvariante »Samba« mit an. Proprietäre Server-Implementationen ignorieren diesen Umstand.

Früher gab es eine Xenix-Variante, die im SMB-Protokoll Unix-spezifische Informationen übertragen konnte. Sie verschwand aber wieder in einer Schublade zu Gunsten anderer Unix-Erweiterungen. Microsoft hatte aber zugestimmt, ein Bit in der Neg-Prot-Antwort für Unix vorzusehen. Mit dem Setzen des Bits signalisiert ein Server, dass er die Unix-Protokollerweiterungen beherrscht.

Microsoft hat zugesichert, einen bestimmten Bereich des Protokolls nicht selbst zu verwenden. Dank der Erweiterungen ist es zum Beispiel möglich, die Unix-Zugriffsrechte an einer Datei auszulesen und zu setzen, ohne wilde Abbildungen auf Windows-NT-ACLs durchzuführen. Samba als Server beherrscht diese Erweiterungen, Smbfs unter Linux als Client nicht. Wer sie nutzen möchte, sollte auf das CIFS von Steve French (Common Internet File System,[5]) zurückgreifen.

Der Neg-Prot-Request ist aus anderem Grund bedeutsam: Der Server teilt dem Client die Parameter mit, mit denen er sich nachfolgend authentifizieren soll. Klassisch entscheidet der Server, ob Passwörter im Klartext oder verschlüsselt übers Netz laufen sollen. Heute benutzt niemand mehr ernsthaft SMB mit Klartextpasswörter, also werden andere Parameter wichtig.

Bei normalen verschlüsselten Passwörtern schickt der Server dem Client die Challenge, die er anhand des eingegebenen Passworts beantworten soll. Läuft auf dem Server Samba 3, ein Windows 2000 oder höher, bietet er dem Client über einen komplexen Mechanismus namens SPNEGO diverse Authentifizierungsverfahren an, zum Beispiel NTLMSSP (NT Lan Manager Security Service Provider) und Kerberos. Kerberos bietet der Server nur an, wenn er sich in einem Active Directory befindet. Dann liefert die Antwort des Neg-Prot-Requests auch gleich den Namen des Kerberos Principal, für den sich der Client ein Ticket besorgen soll.

Authentifizierung im Session Setup

Der nächste Request nennt sich Session Setup. In ihm findet die Benutzerauthentifizierung statt, bei der mindestens drei Dinge über die Leitung laufen:

• Name des Benutzers
• Domäne des Benutzers: Bei lokalen Logins ist das der Namen
  seiner Workstation, bei einem Domänenbenutzer der Name der
  Domäne
• Logon-Credentials

Im einfachsten Fall sind die Logon-Credentials das Klartextpasswort des Benutzers. Je nachdem, was der Server in der Antwort zum Negotiate Protocol Request angeboten hat, sind die Logon-Credentials auch kompliziert. Neben dem Klartextpasswort sind zwei Hauptvarianten zu unterscheiden: Challenge-Response-basierte Verfahren und Kerberos.

Bei den Challenge-Response-Verfahren verarbeitet der Client die im Net-Prot-Reply vom Server gesendete Herausforderung zusammen mit dem Passwort vom Client zu einer Antwort. Hier gibt es viele Varianten; wer sich für die Details interessiert, frage im IRC den Samba-Mann Andrew Bartlett nach seinem Paper über Samba 4 und Active Directory, an dem er gerade (Oktober 2004) arbeitet.

Ordentlich nachgehakt

Eine der Challenge-Response-Varianten verlangt, dass der Server beim Client noch einmal nachfragt. Der Fehlercode »MORE_PROCESSING_REQUIRED« im Ethereal ist also kein echter Fehler, der Server fordert vom Client nur mehr Informationen an. Beim Überprüfen der Benutzerpasswörter sind mindestens drei Fälle zu unterscheiden:

• Ein allein stehender Server muss auf jeden Fall die Anfrage
  selbst beantworten können. Bei einem Samba-Server liest der
  »smbd« dazu seine »smbpasswd«-Datei oder
  das entsprechende »passdb«-Äquivalent aus und
  überprüft das Passwort.
• Ein Domänenmitglied muss unterscheiden, ob die vom Client
  gelieferte Domäne der eigene Servername ist. Dann ist es ein
  lokaler User, der wie beim allein stehenden Server zu behandeln
  ist. Ist der User nicht lokal, baut der Host eine gesicherte
  Verbindung zum eigenen Domänencontroller auf und übergibt
  ihm alle Informationen zur Überprüfung. Ob es eine
  Domäne ist, in der der Server Mitglied ist, bleibt
  unerheblich.E
• Ein Domänencontroller führt im Prinzip die gleichen
  Überprüfungen durch wie ein Mitglied. Benutzer der
  Domäne sind für ihn die lokalen Benutzer, die er anhand
  seiner eigenen Benutzerdatenbank überprüft. Kommt ein
  für ihn nicht lokaler Benutzer mit einer
  Authentifizierungsanfrage, so vermag er sie nur zu beantworten,
  wenn ihm die Domäne vertraut ist. Dann baut er genau wie das
  Mitglied zu einem entfernten Domänencontroller eine gesicherte
  Verbindung auf und schickt die Anfrage weiter.

Viel einfacher ist die Sache für den SMB-Server, wenn der Client ein Kerberos- Ticket zur Authentifizierung mitschickt. Bei Samba 3 geschieht dies nur, wenn sich der Server als ADS-Domänenmitglied in einem Active Directory befindet. Nur so vermag Samba im Neg-Prot-Reply Kerberos überhaupt anzunehmen. Zwischen Neg-Prot-Reply und Session Setup hat sich der Client selbstständig mit seinem Domänencontroller in Verbindung gesetzt, um ein korrektes Kerberos-Ticket zu bekommen.

Hat das geklappt und ist das Ticket korrekt zum SMB-Server abgeschickt, muss dieser es nur noch auspacken. Die Tatsache, dass das Auspacken des Tickets inklusive erfolgreicher Konsistenzprüfungen geklappt hat, reicht dem SMB-Server aus, um den Benutzer als korrekt authentifiziert anzusehen. Er muss keinen Domänencontroller mehr fragen. In der Antwort zum Session Setup liefert der Server dem Client die erwähnte, nur für diese Verbindung gültige UID mit, die in allen folgenden Anfragen den authentifizierten Benutzer repräsentiert.

Tree Connect

Bevor ein Client Dateien öffnen kann, muss er sich mit einer Freigabe verbinden. Der entsprechende Aufruf heißt Tree Connect und ist relativ simpel. Er prüft, ob die Freigabe existiert und ob der Client die entsprechenden Zugriffsrechte besitzt. Wenn alles stimmt, denkt sich der Server eine Tree-ID aus und schickt sie in der Antwort mit.

Sowohl zum Session Setup als auch zum Tree Connect gibt es Gegenstücke für das Abmelden. So kann es sein, dass im Laufe der SMB-Sitzung sowohl UID als auch TID mehrfach unterschiedlich verwendet werden.

Abbildung 3: Ethereal zeigt die Antwort auf einen Negotiate Protocol Request. Darin berichtet der Server von seinen eigenen Protokoll-Kenntnissen.

Für Groß und Klein

Ist die Freigabe klar, kann der Client den Server mit Aufgaben betrauen, etwa mit dem Öffnen von Dateien. Dateinamen im SMB-Protokoll haben eine andere Semantik als in Unix. Der wichtigste Unterschied: SMB unterscheidet Groß- und Kleinschreibung nicht, Unix-Dateisysteme dagegen wohl. (JFS ist das einzige dem Autor bekannte Linux-Dateisystem, das zumindest optional auf die Windows-Semantik umschaltbar ist.)

Das Öffnen einer Datei versucht Samba zunächst mit dem vom Client direkt gelieferten Namen. Ist die Datei so nicht zu finden, muss Samba das Verzeichnis durchsuchen und jeden Dateinamen nicht Case-sensitiv vergleichen – bei vielen Dateien innerhalb eines Verzeichnisses eine sehr aufwändige Operation.

Das Locking ist komplex

Im SMB-Protokoll gibt es zwei echte Arten des Locking und eine, die zwar so heißt, aber mit wirklichem Sperren von Dateien nichts zu tun hat. Die erste Art, die Share Modes, tritt auf, wenn ein Prozess eine Datei exklusiv für sich öffnet. War der Versuch erfolgreich, kann der Prozess sicher sein, dass niemand anderes auf die Datei zugreift.

Das hört sich einfach an, ist aber komplex. Es gibt viele Varianten der Share Modes, die beispielsweise anderen Prozessen alle Dateioperationen inklusive Umbenennen verweigern. Eine andere Variante untersagt nur das Schreiben, bei einer dritten hängt das Verhalten vom Namen der zu öffnenden Datei ab: Alles, was sich nach Programm anhört (».com«, ».dll«, ».exe« und ».sym«) behandelt sie anders als den Rest.

Richtig haarig wird’s, wenn das Öffnen einer Datei tatsächlich wegen eines Share-Mode-Konflikts verweigert wird: Die entsprechende Fehlermeldung verzögert sich um eine Sekunde. Beispiel: Wenn Client A eine Datei so geöffnet hält, dass niemand sie lesen darf, und Client B die Datei öffnen will, wartet der Server eine Sekunde, bevor er B auf die Finger haut. Wenn Client A die Datei während dieser Sekunde schließt, geht alles gut – B bekommt die Datei.

Dieses Verhalten ist für Samba als Single-threaded-Applikation ein Problem, denn das verzögerte Open darf andere Requests nicht aufhalten – es könnte ja der entscheidende Close-Request dabei sein. Dafür muss Samba ein händisches Multi-Threading vorsehen, das den Open-Request von Client B in eine Warteschlange stellt, die Samba bei allen relevanten Anfragen prüft. Auf der Suche nach dem Grund für dieses eigenartige Verhalten machte auf einer CIFS-Konferenz[3] ein unwidersprochenes Gerücht die Runde: Es habe früher einen Bug in dem Benchmark Netbench gegeben, der durch das Verzögern von Open zu umgehen war. Da Microsoft Netbench wichtig sei, hätten die Entwickler den Server geändert, um das Netbench-Problem zu fixen. Seither würden alle anderen Server dieses Verhalten emulieren.

Server für kaputte Clients ändern – das ist durchaus üblich. Während der Betaphase von Windows 2000 gab es einen Release Candidate, der einen Aspekt der Authentifizierung falsch ausführte. Da es weniger Server als Workstations gibt, war es einfacher, den Server an das kaputte Verhalten anzupassen.

Sambas eigene Range Locks

Die zweite Art sind die von Unix bekannten Byte Range Locks. Mit ihnen reserviert ein Prozess den Bereich einer Datei für sich exklusiv. Leider unterscheiden sich die Semantiken der Byte Range Locks von Windows und Unix sehr deutlich. Das beginnt damit, dass Unix-Locking mit vorzeichenbehafteten Offsets arbeitet. Damit können 32-Bit-Unixe nur die unteren 2 GByte einer Datei sperren. Bei 64-Bit-Unixen sind es entsprechend mehr, aber immer noch nur die untere Hälfte des verfügbaren Bereichs. Windows arbeitet hier ohne Vorzeichen, sodass es immer den gesamten Zahlenbereich sperren kann.

Byte Range Locks unter Unix sind Advisory Locks, reine Hinweise für die beteiligten Prozesse. Unix geht also von kooperativen Programmen aus: Wer eine (gemeinsam genutzte) Datei schreiben oder lesen will, soll sich erst ein entsprechendes Lock holen. Damit sind Locks unter Unix eher Mechanismen zur Interprozesskommunikation als Sperren. Es gibt zwar auch unter Unix erzwungene Locks, doch sind die sehr verschieden und anstrengend, sodass sie niemand benutzt. Windows-Locks sind grundsätzlich erzwungen – ein gesperrter Bereich ist für niemanden außer für die sperrende Applikation zugänglich.

Abbildung 4: Überlappende Locks sind ein Problem.

Ein dritter Unterschied zwischen Unix- und Windows-Locking besteht in der Behandlung überlappender Locks. Das Beispiel in Abbildung 4 nimmt an, dass eine Anwendung mit Lock A die Bytes 1 und 2 sperrt sowie mit Lock B die Bytes 2 und 3. Wenn die Applikation das Lock A wieder aufgibt, ist Byte 2 dann noch gesperrt? Unter Windows bleibt es wegen Lock B tatsächlich gesperrt.

Unix/Linux hat die Locks zu einem einzigen verschmolzen, sodass Byte 2 nicht mehr gesperrt ist. Diese semantischen Unterschiede bedingen, dass Samba die Byte Range Locks in Gänze selbst implementieren muss. Sofern die Locks in den von Unix gedeckten Bereich passen, reicht Samba sie aber weiter.

Caching schont Ressourcen

Eine wichtige Regel beim Tuning lautet: Vermeide Netzwerkzugriffe, wo es geht. Es ist oft nicht so sehr die Bandbreite, die entscheidet, sondern vielmehr die Latenz, die die Gesamtleistung beeinträchtigt. Daher gibt es überall Caching-Mechanismen, um Daten möglichst lokal parat zu halten. Im SMB-Protokoll heißt dieses Caching Opportunistic Locks oder Oplocks. Dazu fragt der Client auch nach einem Oplock, wenn er eine Datei öffnet. Gewährt der Server die Bitte, ist dies seine Zusicherung, dass niemand sonst die Datei am Wickel hat.

Zögern ist nicht schädlich

Der Sinn dieses Locks ist, dass der Client Schreibaufträge verzögert zum Server schicken kann. Er darf auch sicher sein, dass einmal gelesene Inhalte niemand nachträglich ändert. So weit funktionieren Oplocks und normale Locks ähnlich. Damit ist es vorbei, wenn ein zweiter Client dieselbe Datei öffnen will.

Der Server merkt, dass für die Datei ein Oplock existiert, und informiert den ersten Client davon, dass ein anderer die Datei öffnen will. Jetzt verhält sich der Client im besten Sinne opportunistisch: Er gibt sein Lock auf, sobald er seine nur lokal gecachten Änderungen zurückgeschrieben hat. Insofern sind Oplocks kein echter Sperrmechanismus, sie erlauben aber das kontrollierte Caching von Datei-Inhalten.

Die Vielfalt des SMB-Protokolls macht die Arbeit des Samba-Teams zwar kompliziert, sorgt aber auch ständig für Überraschungen. Der Artikel konnte nur einen kleinen Teil zeigen. (jk)