Samba, 
2. Auflage

Samba, 2. Auflage

Von Jay Ts, Robert Eckstein, and David Collier-Brown
2. Auflage, August 2003
O'Reilly Verlag, ISBN: 3-89721-359-1
www.oreilly.de/catalog/samba2ger/

Dieses Buch ist unter der GNU Free Documentation License (FDL) erschienen. Bitte beachten Sie den Text der GNU FDL.


TOC PREV NEXT INDEX

Kapitel 8

Erweiterte Verzeichnisfreigaben

Dieses Kapitel setzt unsere Besprechung der Konfiguration von Samba aus Kapitel 6 fort. Wir werden einige komplexere Fragen bezüglich der Integration der Dateisysteme von Unix und Windows klären. Dies schließt verborgene Dateien, Unix-Links, Dateiberechtigungen, die Namensverkürzung, Groß- und Kleinschreibung von Dateinamen, Dateisperren, Oplocks (engl. Opportunistic Locking), Verbindungsskripten, die Unterstützung von Microsoft-Dfs-(Distributed filesystem-)Freigaben und die Verwendung von NIS-Home-Verzeichnissen ein.

Unterschiede zwischen Dateisystemen

Eines der größten Probleme für Samba sind die Unterschiede zwischen Unix- und Microsoft-Dateisystemen. Dazu gehört die Behandlung von symbolischen Links, versteckten Dateien und Dateinamen, die einen Punkt enthalten. Darüber hinaus können die Dateiberechtigungen einige Kopfschmerzen bereiten, wenn Sie sie nicht korrekt berücksichtigen.

Versteckte und unsichtbare Dateien

Manchmal müssen Sie dafür sorgen, dass ein Benutzer eine Datei weder sehen noch überhaupt auf sie zugreifen kann. Ein anderes Mal wollen Sie die Benutzer nicht vom Zugriff auf eine Datei abhalten - Sie wollen sie nur verstecken, wenn die Benutzer den Inhalt des Verzeichnisses betrachten. Windows-Systeme kennen ein Versteckt-Attribut, während bei Unix versteckte Dateien traditionell mit einem Punkt (.) als erstem Zeichen des Dateinamens gekennzeichnet sind. Dadurch bleiben Benutzern Konfigurationsdateien oder Dateien mit Vorgabewerten verborgen, wenn sie einen gewöhnlichen ls-Befehl eingeben. Wollen Sie einem Benutzer jedoch den Zugriff auf Dateien verweigern, müssen Sie mit Berechtigungen für Dateien und Verzeichnisse arbeiten.

Die erste Option, die wir nennen wollen, ist die Boolesche Option hide dot files. Wenn ihr Wert yes ist, werden Dateien, deren Namen mit einem Punkt (.) beginnen, von Samba als versteckt gekennzeichnet. Hat der Benutzer beschlossen, beim Durchsuchen auch die verborgenen Dateien anzeigen zu lassen (z.B. über den Menüeintrag Ordneroptionen im Menü Ansicht von Windows 98), kann er die Dateien sehen, ihre Symbole erscheinen allerdings ausgegraut. Wenn der Client so konfiguriert ist, dass er keine verborgenen Dateien anzeigt, erscheinen die Dateien überhaupt nicht.

Anstatt einfach die Dateien auszublenden, die mit einem Punkt beginnen, können Sie auch für Samba ein String-Muster zum Ausblenden festlegen. Dazu verwenden Sie die Option hide files. Nehmen wir zum Beispiel an, Sie haben Folgendes in der Beispielfreigabe [data] festgelegt:

[data]
 
	hide files = /*.java/*README*/
 

Jeder Eintrag für diese Option muss mit einem Schrägstrich ( / ) beginnen, enden oder von einem anderen Eintrag getrennt sein. Diese Vereinbarung lässt auch Leerzeichen in Dateinamen zu. Die Schrägstriche haben nichts mit Unix-Verzeichnissen zu tun; stattdessen dienen sie als Trennzeichen für die hide files-Werte.

Wollen Sie ganz und gar verhindern, dass Benutzer Dateien sehen können, verwenden Sie die Option veto files. Diese Option, die die gleiche Syntax hat wie die Option hide files, gibt eine Liste mit Dateien an, die nie vom Benutzer gesehen werden dürfen. Lassen Sie uns zum Beispiel die Freigabe [data] folgendermaßen ändern:

[data]
 
	veto files = /*.java/*README*/
 

Die Syntax dieser Option ist identisch mit der der Konfigurationsoption hide files: Jeder Eintrag muss mit einem Schrägstrich (/) beginnen, enden oder von einem anderen Eintrag getrennt sein, auch wenn nur ein Muster aufgeführt ist. Wenn Sie so vorgehen, verschwinden Dateien, auf die das Muster zutrifft - wie etwa hello.java oder README.txt -, einfach aus dem Verzeichnis, und der Benutzer kann über SMB nicht auf sie zugreifen.

Wir müssen uns noch mit einer weiteren Frage befassen. Was passiert, wenn der Benutzer versucht, ein Verzeichnis zu löschen, das unsichtbare Dateien enthält? An dieser Stelle kommt die Option delete veto files ins Spiel. Ist diese Boolesche Option auf yes gesetzt, darf der Benutzer sowohl die normalen als auch die unsichtbaren Dateien in dem Verzeichnis löschen. Auch das Verzeichnis selbst wird entfernt. Ist die Option auf no gesetzt, kann der Benutzer die unsichtbaren Dateien nicht löschen, und auch das Verzeichnis bleibt folglich bestehen. Aus Sicht des Benutzers scheint das Verzeichnis leer zu sein, lässt sich aber nicht löschen.

Die Anweisung dont descend gibt eine Liste mit Verzeichnissen an, deren Inhalt Samba nicht anzeigen soll. Beachten Sie, dass wir vom Inhalt sprechen, nicht vom Verzeichnis selbst. Benutzer können in ein Verzeichnis wechseln, das so gekennzeichnet ist, es ist ihnen allerdings verboten, den Verzeichnisbaum weiter hinabzusteigen - sie sehen immer einen leeren Ordner. Lassen Sie uns zum Beispiel diese Option mit einer einfacheren Form der Freigabe nutzen, die wir weiter vorn in diesem Kapitel definiert haben:

[data]
 
	dont descend = config defaults
 

Darüber hinaus wollen wir annehmen, dass das Verzeichnis /home/samba/data folgenden Inhalt hat:

drwxr-xr-x   6 tom      users     1024 Jun 13 09:24 .
 
drwxr-xr-x   8 root     root      1024 Jun 10 17:53 ..
 
-rw-r--r--   2 tom      users     1024 Jun  9 11:43 README
 
drwxr-xr-x   3 tom      users     1024 Jun 13 09:28 config
 
drwxr-xr-x   3 tom      users     1024 Jun 13 09:28 defaults
 
drwxr-xr-x   3 tom      users     1024 Jun 13 09:28 market
 

Wenn der Benutzer sich mit der Freigabe verbindet, sieht er die Verzeichnisse in der Freigabe. Der Inhalt der Verzeichnisse /config und /defaults wäre für ihn jedoch nicht zu sehen, auch wenn es in diesen Verzeichnissen Ordner oder Dateien gäbe. Außerdem dürfen die Benutzer keine Daten in den Ordner schreiben (was verhindert, dass sie eine Datei oder einen Ordner mit dem Namen eines bereits vorhandenen, wenn auch unsichtbaren Objekts anlegen). Unternimmt ein Benutzer einen entsprechenden Versuch, erhält er die Meldung »Zugriff verweigert«. Die Option dont descend dient administrativen Zwecken und nicht der Sicherheit und bildet daher keinen Ersatz für gut gewählte Dateiberechtigungen.

Links

Wenn ein Client versucht, auf einer Samba-Server-Freigabe einen symbolischen Link zu öffnen, versucht Samba, dem Link zu folgen, um die eigentliche Datei zu finden und den Client diese öffnen zu lassen, so als würde der Benutzer an einer Unix-Maschine sitzen. Wollen Sie dies nicht zulassen, stellen Sie die Option follow symlinks so ein:

[data]
 
	follow symlinks = no
 

Sie können diese Einstellung testen, indem Sie einen symbolischen Link einrichten und versuchen, auf ihn zuzugreifen. Legen Sie unter der Benutzerkennung, die Sie zur Anmeldung an Samba verwenden, auf dem Unix-Server ein Verzeichnis an. Geben Sie folgende Befehle ein:

$ echo "Dies ist ein Test" >hello.txt
 
$ ln -s hello.txt hello-link.txt
 

Sie erhalten die Textdatei hello.txt und einen symbolischen Link mit dem Namen hello-link.txt auf diese Datei. Wenn Sie auf eines von beiden doppelklicken, bekommen Sie normalerweise eine Datei, die den Text »Dies ist ein Test« enthält. Wenn die Option follow symlinks jedoch auf no gesetzt ist, erhalten Sie nur eine Fehlermeldung, nachdem Sie doppelt auf hello-link.txt geklickt haben.

Die Option wide links verhindert, wenn sie auf no gesetzt ist, dass der Client-Benutzer symbolischen Links folgt, die auf Ziele außerhalb des freigegebenen Verzeichnisbaums verweisen. Lassen Sie uns beispielsweise annehmen, dass wir die Freigabe [data] folgendermaßen verändert haben:

[data]
 
	follow symlinks = yes
 
	wide links = no
 

Solange die Option follow symlinks deaktiviert ist, lehnt Samba es ab, symbolischen Links außerhalb des aktuellen Freigabebaums zu folgen. Wenn wir eine Datei außerhalb der Freigabe anlegen (zum Beispiel im Home-Verzeichnis eines Benutzers) und dann auf die folgende Weise einen Link darauf in der Freigabe erzeugen:

ln -s ~tom/datafile ./datafile
 

kann der Client die Datei in Toms Home-Verzeichnis nicht öffnen.

Dateisystem-Optionen

Tabelle 8-1 zeigt eine Zusammenfassung der zuvor besprochenen Optionen. Für die meisten empfehlen wir die Vorgabewerte. Ausnahmen bilden die in den folgenden Beschreibungen aufgeführten Werte.

Tabelle 8-1
Optionen zur Konfiguration des Dateisystems 
Option
Parameter
Funktion
Vorgabewert
Geltungsbereich
dont descend
String (Liste mit Verzeichnissen)
Legt eine Liste mit Verzeichnissen fest, deren Inhalt Samba vor den Clients verbergen soll.
keiner
Freigabe
follow symlinks
Boolescher Wert
Auf no gesetzt, werden symbolische Links nicht verfolgt.
yes
Freigabe
getwd cache
Boolescher Wert
Auf yes gesetzt, wird ein Zwischenspeicher für getwd( )-Aufrufe verwendet.
yes
global
wide links
Boolescher Wert
Auf yes gesetzt, werden symbolische Links außerhalb der Freigabe verfolgt.
yes
Freigabe
hide dot files
Boolescher Wert
Auf yes gesetzt, werden verborgene Unix-Dateien wie verborgene Windows-Dateien behandelt.
yes
Freigabe
hide files
String (Liste mit Dateien)
Liste mit Dateimustern, die als verborgene Dateien behandelt werden sollen.
keiner
Freigabe
veto files
String (Liste mit Dateien)
Liste mit Dateien, die unsichtbar sein sollen.
keiner
Freigabe
delete veto files
Boolescher Wert
Auf yes gesetzt, werden Dateien gelöscht, auf die veto files zutrifft, wenn das Verzeichnis gelöscht wird, in dem sie sich befinden.
no
Freigabe

dont descend

Die Option dont descend kann verwendet werden, um verschiedene Verzeichnisse festzulegen, die für den Client leer erscheinen sollen. Beachten Sie, dass das Verzeichnis selbst angezeigt wird. Samba zeigt jedoch dem Client-Benutzer den Inhalt des Verzeichnisses nicht an. Diese Option ist nicht als Sicherheitsmechanismus geeignet; sie dient einfach nur dazu, Benutzer davon abzuhalten, in Verzeichnissen herumzusuchen, die sensible Daten enthalten. Beachten Sie dazu auch das Beispiel weiter oben in diesem Abschnitt.

follow symlinks

Diese Option steuert, ob Samba einem symbolischen Link im Unix-Dateisystem folgt oder ob der Benutzer eine Fehlermeldung erhalten soll. Ist die Option auf yes gesetzt, wird das Ziel des Links als Datei interpretiert. Bei no wird beim Zugriff auf einen symbolischen Link ein Fehler ausgegeben.

getwd cache

Diese globale Option gibt an, ob Samba einen lokalen Zwischenspeicher für den Unix-Systemaufruf getwd(  ) ( get current working directory; aktuelles Arbeitsverzeichnis beziehen) verwenden soll. Sie können den Vorgabewert yes folgendermaßen überschreiben:

[global]
 
	getwd cache = no
 

Wenn Sie diese Option auf no setzen, dauert es deutlich länger, das Arbeitsverzeichnis zu ermitteln, vor allem, wenn Sie die Option wide links auf no gesetzt haben. Normalerweise sollte es nicht erforderlich sein, diese Option zu verändern.

wide links

Hiermit geben Sie an, ob der Benutzer symbolischen Links folgen kann, deren Ziel außerhalb des freigegebenen Verzeichnisbaums liegt. Dazu gehören Dateien und Verzeichnisse am anderen Ende der Links, solange die Berechtigungen dafür vorliegen. Der Vorgabewert für diese Option ist yes. Beachten Sie, dass diese Option keine Wirkung hat, wenn der Wert der Option follow symlinks auf no steht. Wenn Sie hier den Wert no angeben, arbeitet smbd deutlich langsamer, weil er jeden Link prüfen muss, den er entdeckt.

hide dot files

Die Option hide dot files versteckt alle Dateien auf dem Server, die mit einem Punkt (.) beginnen, um die entsprechende Funktion verschiedener Shell-Befehle nachzubilden, die es auf Unix-Systemen gibt. Wie bei hide files ist das DOS-Attribut »versteckt« (hidden) bei Dateien aktiviert, die mit einem Punkt beginnen. Das garantiert jedoch nicht, dass ein Client die Dateien nicht sieht. Der Vorgabewert für diese Option ist yes.

hide files

Die Option hide files liefert Samba ein oder mehrere Verzeichnis- oder Dateinamenmuster. Jede Datei, die diesem Muster entspricht, wird aus Sicht des Clients als verborgene Datei behandelt. Beachten Sie, dass diese Option lediglich das entsprechende DOS-Attribut setzt. Clients können versteckte Dateien durchaus anzeigen, wenn ihr Benutzer dies möchte.

Jeder Eintrag in der Liste muss mit einem Schrägstrich (/) beginnen, enden oder von anderen Einträgen getrennt sein. Dadurch können die einzelnen Muster Leerzeichen enthalten. Sternchen gelten als Platzhalter für null oder mehr Zeichen, Fragezeichen als Platzhalter für genau ein Zeichen. Hier ein Beispiel:

hide files = /.jav*/README.???/
 
veto files

Die Konfigurationsoption veto files hat eine stärkere Einschränkung zur Folge als die Optionen hide files und hide dot files. Samba würde es nicht einmal zugeben, dass diese Dateien existieren. Man kann unsichtbare Dateien vom Client aus weder anzeigen noch öffnen. Aber auch diese Option schafft keine optimale Sicherheit. Sie hat lediglich den Zweck, PCs davon abzuhalten, besondere Dateien zu löschen, wie zum Beispiel jene, die den Resource Fork von Mac-Dateien auf Unix-Dateisystemen darstellen. Wenn sowohl Mac-Computer als auch Windows-Systeme auf dieselben Dateien zugreifen, kann diese Option verhindern, dass nicht ausreichend informierte Benutzer mit entsprechenden Berechtigungen Dateien löschen, die Mac-Benutzer benötigen.

Die Syntax dieser Option ist identisch mit der der Konfigurationsoption hide files: Jeder Eintrag muss mit einem Schrägstrich ( / ) beginnen, enden oder von anderen Einträgen getrennt sein, selbst wenn es nur ein Muster gibt. Sternchen gelten als Platzhalter für null oder mehr Zeichen, Fragezeichen als Platzhalter für genau ein Zeichen. Hier ein Beispiel:

veto files = /*config/*default?/
 

Diese Option dient vor allem administrativen Zwecken und kann gute Dateiberechtigungen nicht ersetzen.

delete veto files

Diese Option weist Samba an, unsichtbare Dateien zu löschen, wenn ein Benutzer versucht, das Verzeichnis zu entfernen, in dem sie sich befinden. Vorgabewert ist no. Wenn also ein Benutzer versucht, ein Verzeichnis zu löschen, das eine unsichtbare Datei enthält, wird die Datei (und das Verzeichnis) nicht gelöscht. Stattdessen bleibt das Verzeichnis vorhanden und erscheint aus Sicht des Benutzers leer. Ist die Option auf yes gesetzt, werden das Verzeichnis und die unsichtbaren Dateien gelöscht.

Dateiberechtigungen und Attribute unter MS-DOS und Unix

DOS war niemals als Mehrbenutzer-Netzwerkbetriebssystem gedacht, Unix dagegen war von Anfang an so konzipiert. Samba muss daher Unterschiede und Lücken zwischen den Dateisystemen dieser beiden Betriebssysteme nicht nur beachten, sondern in Konfliktfällen auch für Lösungen sorgen. Zu den größten Unterschieden zwischen DOS und Unix gehört die Behandlung von Dateiberechtigungen.

Schauen wir uns zunächst an, wie Unix Berechtigungen zuweist. Alle Unix-Dateien besitzen Bits für die Lese-, Schreib- und Ausführungsberechtigung, und zwar jeweils getrennt für den Besitzer, die Gruppe und den Rest der Welt. Sie sehen die Berechtigungen ganz links, wenn Sie den Befehl ls -al in einem Unix-Verzeichnis eingeben. Hier ein Beispiel:

-rwxr--r--   1 tom     users   2014 Apr 13 14:11 access.conf     
 

Windows kennt für jede Datei die folgenden vier Bits: schreibgeschützt, System, versteckt und Archiv. Sie können sie sehen, indem Sie im Windows-Explorer mit der rechten Maustaste auf eine Datei klicken und aus dem Kontextmenü den Eintrag Eigenschaften auswählen. Daraufhin erscheint ein Dialogfenster, das dem in Abbildung 8-1 ähnelt.1
Abbildung 8-1
DOS- und Windows-Dateieigenschaften

Hier die Definition der einzelnen Bits:

Schreibgeschützt
Ein Benutzer kann den Inhalt der Datei lesen, ihn aber nicht verändern.
System
Die Datei wird vom Betriebssystem verwendet.
Versteckt
Die Datei ist als unsichtbar gekennzeichnet, so dass Benutzer sie normalerweise nicht sehen, es sei denn, das Betriebssystem erlaubt ausdrücklich das Anzeigen der Datei.
Archiv
Diese Datei wurde seit dem letzten DOS-Backup verändert.

Beachten Sie, dass es kein Bit gibt, das ausführbare Dateien kennzeichnet. DOS- und Windows NT-Dateisysteme erkennen ausführbare Dateien an den Erweiterungen .exe, .com, .cmd oder .bat.

Folglich gibt es keine Verwendung für die drei Bits für ausführbare Dateien unter Unix, die eine Datei auf einer Samba-Verzeichnisfreigabe besitzt. DOS-Dateien jedoch haben ihre eigenen Attribute, die beim Speichern in einer Unix-Umgebung beibehalten werden müssen: die Archiv-, System- und Versteckt-Bits. Samba kann diese Bits schützen, indem es die Bits wiederverwendet, die Ausführungsberechtigungen auf Unix-Dateien signalisieren - wenn es entsprechend konfiguriert ist. Diese Zuordnung hat aber eine unerwünschte Nebenwirkung: Wenn ein Windows-Benutzer eine Datei in einer Samba-Freigabe speichert und Sie sich die Datei auf dem Unix-Computer mit ls -al ansehen, haben die Bits für die Ausführbarkeit nicht die Bedeutung, die Sie für gewöhnlich von ihnen erwarten.

Drei Samba-Optionen entscheiden, ob die Bits zugeordnet werden: map archive, map system  und map hidden. Diese Optionen ordnen die Attribute Archiv, System und Versteckt den Ausführbarkeits-Bits Eigentümer, Gruppe bzw. Rest der Welt zu. Legen Sie die Optionen für die Freigabe [data] folgendermaßen fest:

[data]
 
	map archive = yes
 
	map system = yes
 
	map hidden = yes
 

Versuchen Sie anschließend, eine Datei in der Freigabe unter Unix anzulegen - etwa hello.java - und die Dateiberechtigungen auf 755 zu ändern. Wenn Sie die genannten Samba-Optionen verwendet haben und die Dateieigenschaften unter Windows betrachten, sollten die drei Werte im Eigenschaften-Dialogfeld aktiviert sein. Was ist mit dem Attribut für schreibgeschützte Dateien? Standardmäßig setzt Samba dieses Bit, wenn dem Unix-Eigentümer der Datei keine Schreibberechtigung gewährt wurde. Sie können dieses Bit also setzen, wenn Sie die Berechtigungen der Datei auf 555 ändern.

Der Standardwert der Option map archive ist yes, die anderen beiden Optionen dagegen haben den Standardwert no. Dies liegt daran, dass viele Programme nicht richtig arbeiten, wenn das Archiv-Bit für DOS- und Windows-Dateien nicht richtig gespeichert ist. Die Attribute System und Versteckt sind für den Betrieb eines Programms nicht entscheidend und werden dem Ermessen des Administrators überlassen.

Abbildung 8-2 fasst die Unix-Berechtigungs-Bits zusammen und stellt dar, wie Samba diese Bits auf DOS-Attribute abbildet. Beachten Sie, dass die Lese-/Schreib-Bits für die Gruppe und für den Rest der Welt nicht direkt einem DOS-Attribut zugeordnet werden, sondern ihre ursprünglichen Unix-Definitionen auf dem Samba-Server behalten.

Erstellungsmasken

Datei- und Verzeichnis-Erstellungsmasken ähneln den Umasks, mit denen Sie beim Arbeiten auf Unix-Systemen möglicherweise bereits zu tun hatten. Sie helfen beim Definieren der Berechtigungen, die einer Datei oder einem Verzeichnis zum Zeitpunkt seiner Erstellung zugewiesen werden. Sambas Masken funktionieren ein wenig anders. Bei Samba werden die Bits, die gesetzt werden können, in der Erstellungsmaske gesetzt, während bei Unix-Umasks die Bits nicht in der Umask gesetzt werden können. Vermutlich werden Sie die Samba-Methode intuitiver finden. Gelegentlich müssen Sie eine Unix-Umask in die äquivalente Samba-Maske konvertieren. Das ist einfach: die eine ist das bitweise Komplement der anderen. Beispielsweise hat ein oktaler Umask-Wert von 0022 die gleichen Auswirkungen wie eine Samba-Maske von 0755.
Abbildung 8-2
Wie Samba und Unix die Berechtigungen einer Datei sehen

Unix-Umasks werden auf Grundlage der Benutzer gesetzt, üblicherweise beim Ausführen der Startskripten der grafischen Oberfläche oder der Shell. Wenn Benutzer sich von einem Netzwerk-Client aus an einer Samba-Freigabe anmelden, werden diese Skripten nicht ausgeführt. Samba bietet also die Fähigkeit, die Erstellungsmasken für Dateien und Verzeichnisse einzustellen. Normalerweise wird dies auf Basis der Freigabe erledigt, obwohl Sie auch den Parameter include in der Samba-Konfigurationsdatei verwenden können (wie in Kapitel 6 erläutert), um Masken benutzerweise zuzuweisen und damit dem herkömmlichen Unix-Verhalten zu folgen.

Um zu demonstrieren, wie die Erstellungsmasken von Samba funktionieren, nehmen Sie einmal an, es gibt einen Windows Me-Benutzer, der sich über Samba an seinem Unix-Home-Verzeichnis anmeldet. Samba wiederum ist mit create mask = 777 in der Freigabe [homes] konfiguriert. Mit diesem Wert beeinflusst create mask nicht die Bits, die auf neuen Dateien gesetzt werden. Wenn der Benutzer eine Datei mit Wordpad erzeugt, taucht diese im Unix-Dateisystem so auf:

$ ls -l file.doc
 
-rwxrw-rw-    1 jay      jay             0 Sep 21 11:02 file.doc
 

Wordpad hat die Datei mit Lese-/Schreibberechtigung erzeugt (d.h., das MS-DOS-Attribut Schreibgeschützt wurde nicht gesetzt), Samba hat also die MS-DOS-Attribute den Unix-Lese-/Schreibrechten für Benutzer, Gruppe und Rest zugeordnet. Für den Eigentümer wurde das Ausführbarkeits-Bit gesetzt, weil der Parameter map archive standardmäßig auf yes gesetzt ist. Die anderen Ausführbarkeits-Bits sind nicht gesetzt worden, weil map system und map hidden standardmäßig no sind. Sie können dieses Verhalten an Ihre Bedürfnisse anpassen. Vermutlich wollen Sie map archive = no festlegen, um zu vermeiden, dass Windows-Dateien auf Unix-Systemen als ausführbare Dateien erscheinen, es sei denn, Sie machen Backups von MS-DOS- oder Windows-Systemen.

Stellen Sie sich nun vor, Sie setzen create mask, um eine Wirkung zu erzielen, zum Beispiel:

[homes]
 
	create mask = 664
 

Dies ist äquivalent zu einem Unix-Umask-Wert von 113. Erzeugt der Benutzer das Wordpad-Dokument so wie zuvor, sieht dieses so aus:

$ ls -l file.doc
 
-rw-rw-r--    1 jay      jay             0 Sep 22 16:38 file.doc
 

Bei einem Vergleich mit dem vorherigen Beispiel sollten Sie feststellen, dass - wie erwartet - nicht nur die Schreibberechtigung für den Rest der Welt verschwunden ist, sondern dass es auch keine Ausführungsberechtigung mehr für den Eigentümer gibt. Dies ist geschehen, weil der Wert von create mask die Berechtigungen des Eigentümers mit einer 6 logisch UND-verknüpft hat, wodurch das Ausführbarkeits-Bit demaskiert wurde. Falls Sie daher map archive, map system oder map hidden aktivieren wollen, müssen Sie unbedingt darauf achten, dass Sie nicht das korrespondierende Ausführbarkeits-Bis mit Ihrem create mask demaskieren.

Die Option directory mask funktioniert ähnlich. Sie maskiert die Berechtigungen für neu erschaffene Verzeichnisse. Das folgende Beispiel sorgt dafür, dass die Berechtigungen eines neu erzeugten Verzeichnisses höchstens bei 755 liegen:

[data]
 
	directory mask = 755
 

Sie können auch verschiedene Bits mit den Optionen force create mode und force directory mode erzwingen. Diese Optionen führen eine logische ODER-Verknüpfung mit den Datei- und Verzeichniserstellungsmasken durch. Dadurch wird sichergestellt, dass die angegebenen Bits immer gesetzt sind. Üblicherweise würden Sie diese Optionen global setzen, um sicherzustellen, dass Lese-/Schreibrechte für neue Dateien oder Verzeichnisse in den einzelnen Freigaben für Gruppen und den Rest der Welt richtig gesetzt sind.

Falls Sie die Unix-Benutzer- und Gruppen-Attribute einer Datei, die auf der Windows-Seite erzeugt wurde, explizit setzen wollen, können Sie ähnlich vorgehen und die Optionen force user und force group verwenden; beispielsweise:

[data]
 
	create mask = 744
 
	directory mask = 755
 
	force user = joe
 
	force group = accounting
 

Diese Optionen weisen jedem Client, der sich an der Freigabe anmeldet, den gleichen Unix-Benutzernamen und die gleiche Unix-Gruppe zu. Dies geschieht jedoch, nachdem der Client sich authentifiziert hat; es wird kein freier Zugriff auf die Freigabe erlaubt. Diese Optionen werden häufig verwendet, damit neue Dateien und Verzeichnisse einem bestimmten Benutzer und einer bestimmten Gruppe zugeordnet werden. Verwenden Sie diese Optionen nach persönlichem Gusto.

Schließlich fehlt DOS eine Unix-Funktion: DOS kann schreibgeschützte Dateien nicht löschen, auch wenn die Schreibberechtigung für das Verzeichnis besteht, in dem sich die Datei befindet. Wenn ein Verzeichnis unter Unix schreibbar ist, können Sie auch schreibgeschützte Dateien löschen. Demnach kann man Dateien in jedem beliebigen Verzeichnis löschen, und zwar unabhängig davon, wer sie erstellt hat.

DOS-Dateisysteme sind nicht für die Verwendung durch mehrere Benutzer gedacht, und so haben ihre Entwickler das Schreibschutz-Bit als Sicherung gegen versehentliches Ändern oder Löschen vorgesehen anstatt als Schutz vor einem anderen Benutzer auf einer Einbenutzermaschine. Die Entwickler von DOS haben daher das Löschen schreibgeschützter Dateien verboten. Windows zeigt selbst heutzutage noch das gleiche Verhalten.

Normalerweise ist das harmlos. Windows-Programme versuchen nicht, schreibgeschützte Dateien zu löschen, weil sie wissen, dass das keine gute Idee ist. Allerdings laufen verschiedene Source-Code-Control-Programme - die es zuerst für Unix gab - unter Windows und erfordern die Fähigkeit, schreibgeschützte Dateien löschen zu können. Samba unterstützt dieses Verhalten mit der Option delete readonly. Um diese Funktion zu aktivieren, setzen Sie die Option auf yes:

[data]
 
	delete readonly = yes 
 

Optionen für Datei- und Verzeichnisberechtigungen

Die Optionen für Datei- und Verzeichnisberechtigungen sind in Tabelle 8-2 zusammengefasst; alle Optionen werden anschließend im Detail beschrieben.

Tabelle 8-2
Optionen für Datei- und Verzeichnisberechtigungen 
Option
Parameter
Funktion
Vorgabewert
Geltungsbereich
create mask (create mode)
numerischer Wert
Maximal mögliche Berechtigungen für Dateien, die von Samba erstellt wurden.
0744
Freigabe
directory mask (directory mode)
numerischer Wert
Maximal mögliche Berechtigungen für Verzeichnisse, die von Samba erstellt wurden.
0755
Freigabe
force create mode
numerischer Wert
Erzwingt die angegebenen Berechtigungen (bitweise ODER-verknüpft) für Dateien, die über Samba erstellt wurden.
0000
Freigabe
force directory mode
numerischer Wert
Erzwingt die angegebenen Berechtigungen (bitweise ODER-verknüpft) für Verzeichnisse, die über Samba erstellt wurden.
0000
Freigabe
force group (group)
String
(Gruppenname)
Effektive Gruppe für einen Benutzer, der auf diese Freigabe zugreift.
keiner
Freigabe
force user
String
(Benutzername)
Effektiver Benutzername für einen Benutzer, der auf diese Freigabe zugreift.
keiner
Freigabe
delete readonly
Boolescher Wert
Erlaubt einem Benutzer, eine schreibgeschützte Datei aus einem schreibbaren Verzeichnis zu löschen.
no
Freigabe
map archive
Boolescher Wert
Speichert das DOS-Archiv-Attribut im Ausführbarkeits-Bit des Benutzers (0100).
yes
Freigabe
map system
Boolescher Wert
Speichert das DOS-System-Attribut im Ausführbarkeits-Bit der Gruppe (0010).
no
Freigabe
map hidden
Boolescher Wert
Speichert das DOS-Versteckt-Attribut im Ausführbarkeits-Bit für »Welt« (0001).
no
Freigabe
inherit permissions
Boolescher Wert
Wenn yes, werden die Berechtigungen für neue Dateien und Verzeichnisse vom übergeordneten Verzeichnis übernommen.
no
Freigabe

create mask

Das Argument für diese Option ist eine oktal geschriebene Zahl, die die Berechtigungs-Flags angibt, die von einem Client bei der Erzeugung einer Datei in einer Freigabe gesetzt werden können. Die Vorgabe ist 0744, so dass der Unix-Besitzer seine eigenen Dateien zumindest lesen, schreiben und optional ausführen kann, während Mitglieder der Gruppe des Benutzers und andere die Dateien lediglich lesen können. Wenn Sie dies zu nicht-ausführbaren Dateien ändern wollen, empfehlen wir, 0644 oder rw-r--r-- zu verwenden. Denken Sie daran, dass der Server möglicherweise die Ausführungs-Bits verwendet, um bestimmte DOS-Attribute zu speichern, wie wir bereits beschrieben haben. Wenn Sie die Erstellungsmaske ändern, müssen diese Bits ebenfalls Teil der Erstellungsmaske sein.

directory mask

Der Wert dieser Option ist eine oktal geschriebene Zahl für die Berechtigungs-Flags von Verzeichnissen, die Clients in einer Freigabe anlegen. Die Voreinstellung ist 0755, so dass jeder auf dem Unix-Server die Verzeichnisse zumindest lesen und in sie wechseln kann, während nur Sie sie ändern dürfen. Wir empfehlen die Maske 0750, die den Zugriff für »andere« Benutzer unmöglich macht.

force create mode

Diese Option legt die Berechtigungs-Bits fest, die Samba setzt, wenn eine Änderung an den Berechtigungen einer Datei vorgenommen wird. Diese Option wird häufig dazu verwendet, die bereits erwähnten Gruppenberechtigungen zu erzwingen. Mit ihr kann man darüber hinaus beliebige DOS-Attribute standardmäßig aktivieren. Dazu gehören Archiv (0100), System (0010) und Versteckt (0001).


Beim Speichern von Dokumenten benennen viele Windows-Anwendungen ihre Datendateien mit der Erweiterung .bak um und erzeugen neue. Befinden sich die Dateien in einer Samba-Freigabe, werden dadurch die Eigentümerschaft der Dateien und ihre Berechtigungen geändert, so dass Mitglieder der gleichen Unix-Gruppe sie nicht bearbeiten können. Wenn Sie force create mode = 0660 setzen, bleibt die neue Datei für die Mitglieder der Gruppe änderbar.
force directory mode

Diese Option legt die Berechtigungs-Bits fest, die Samba setzt, wenn eine Änderung an den Berechtigungen eines Verzeichnisses vorgenommen oder wenn ein Verzeichnis erstellt wird. Sie wird häufig dazu benutzt, die bereits erwähnten Gruppenberechtigungen zu erzwingen. Der Vorgabewert beträgt 0000 und kann genau wie bei force create mode dazu verwendet werden, Berechtigungen für die Gruppe oder für andere hinzuzufügen, falls dies erforderlich ist.

force group

Diese Option, die manchmal auch als group bezeichnet wird, weist allen Verbindungen zu einer Freigabe eine statische Gruppen-ID zu, nachdem die Authentifizierung eines Clients erfolgreich abgeschlossen wurde. Dadurch gehören alle neuen Dateien oder Verzeichnisse, die von einem SMB-Client erzeugt wurden, zu dieser Gruppe.

force user

Die Option force user weist allen Verbindungen zu einer Freigabe eine statische Benutzer-ID zu, nachdem die Authentifizierung eines Clients erfolgreich abgeschlossen wurde. Dadurch gehören alle neuen Dateien oder Verzeichnisse, die von einem SMB-Client erzeugt wurden, zu diesem Benutzer.

delete readonly

Diese Option erlaubt es einem Benutzer, ein Verzeichnis zu löschen, das eine schreibgeschützte Datei enthält. DOS und Windows erlauben dies normalerweise nicht. Vermutlich werden Sie diese Option deaktiviert lassen, es sei denn, ein Programm (zum Beispiel ein RCS-Programm) benötigt diese Funktionalität; viele Windows-Benutzer wären entsetzt, wenn sie feststellten, dass sie versehentlich eine Datei gelöscht hätten, für die sie einen Schreibschutz aktiviert haben.

map archive

Das DOS-Archiv-Bit kennzeichnet Dateien, die seit ihrer letzten Sicherung (d.h. seit der Sicherung mit dem DOS-Archivprogramm) verändert wurden. Wenn Sie map archive = yes in Ihre Samba-Konfigurationsdatei eintragen, ordnet Samba das Archiv-Bit dem Unix-Bit für die Ausführung durch den Benutzer (0100) zu. Lassen Sie diese Option eingeschaltet, wenn Ihre Windows-Benutzer ihre eigenen Datensicherungen durchführen oder wenn Sie Programme verwenden, die das Archiv-Bit benutzen. Unix fehlt eine Entsprechung vollständig. Backup-Programme für Unix merken sich üblicherweise in einer Datei, welche Dateien sie zu welchem Zeitpunkt gesichert haben, ein Vergleich der Daten der letzten Änderung der Dateien erfüllt daher denselben Zweck.

Wenn Sie yes als Wert für diese Option festlegen, überraschen Sie Unix-Benutzer, weil Datendateien hin und wieder als ausführbar gekennzeichnet sind; dies verursacht aber selten Probleme. Bei dem Versuch, eine Datendatei unter Unix auszuführen, erhält der Benutzer normalerweise eine Reihe von Fehlermeldungen, die von der Shell erzeugt werden, wenn sie die ersten Zeilen der Datei als Befehle zu interpretieren versucht. Der umgekehrte Fall ist ebenfalls möglich, so dass ein Unix-Programm auf einem Windows-Rechner so aussieht, als wäre die Datei nicht kürzlich gesichert worden. Auch dieser Fall ist selten und in der Regel harmlos.

Damit map archive richtig funktioniert, darf das Ausführungs-Bit für den Eigentümer nicht mit dem Parameter create mask demaskiert worden sein.

map system

Das DOS-Attribut System kennzeichnet Dateien, die das Betriebssystem benötigt. Sie sollten nicht ohne besonderen Aufwand gelöscht, umbenannt oder verschoben werden können. Aktivieren Sie dieses Bit nur, wenn Sie Windows-Systemdateien auf dem Unix-Server ablegen. Ausführbare Unix-Dateien erscheinen auf Windows-Clients als nicht löschbare Systemdateien. Das kann zu Unbequemlichkeiten führen, wenn Sie ein Unix-Programm von einem Windows-Client aus löschen oder verschieben wollen. In den meisten Netzwerken ist dies ziemlich harmlos.

Damit map system richtig funktioniert, darf das Ausführungs-Bit für die Gruppe nicht mit dem Parameter create mask demaskiert worden sein.

map hidden

DOS verwendet das Attribut Versteckt für Dateien, die normalerweise bei Verzeichnisauflistungen nicht sichtbar sein sollen. Unix besitzt ein solches Bit nicht, und jedes Programm (hauptsächlich die Shell) kann selbst entscheiden, welche Dateien es anzeigt und welche nicht. Normalerweise haben Sie keine DOS-Dateien, die versteckt werden müssen, so dass Sie diese Option abgeschaltet lassen können.

Wenn Sie als Wert dieser Option yes angeben, ordnet der Server dem Versteckt-Attribut das Ausführungs-Bit für »andere« (0001) zu. Dieses Merkmal kann eine überraschende Wirkung haben: Jedes Unix-Programm, das von anderen ausführbar ist, scheint auf Windows-Clients verschwunden zu sein. Wenn diese Option aber nicht gesetzt ist und ein Windows-Benutzer eine Datei auf einer Samba-Freigabe verstecken will, bleibt dieser Versuch erfolglos - Samba kann das Versteckt-Attribut nicht speichern!

Damit map hidden richtig funktioniert, darf das Ausführungs-Bit für andere (»World«) nicht mit dem Parameter create mask demaskiert worden sein.

inherit permissions

Wenn die Option inherit permissions auf yes gesetzt ist, werden create mask, directory mask, force create mode und force directory mode ignoriert. Das normale Verhalten, bei dem Berechtigungen auf neu erzeugten Dateien gesetzt werden, wird außer Kraft gesetzt. Das heißt, neue Dateien und Verzeichnisse erben ihre Berechtigungen von ihren übergeordneten Verzeichnissen. Neue Verzeichnisse verfügen über genau die gleichen Berechtigungen wie ihr übergeordnetes Verzeichnis, und neue Dateien erben die Lese- und Schreib-Bits ebenfalls vom übergeordneten Verzeichnis. Die Ausführungs-Bits dagegen werden wie gehabt durch die Werte der Parameter map archive, map hidden und map system festgelegt.

Standardmäßig ist diese Option auf no gesetzt.

Windows NT/2000/XP-ACLs

Unix und Windows verwenden unterschiedliche Sicherheitsmodelle. Windows NT/ 2000/XP wiederum benutzt ein Sicherheitsmodell, das sich von Windows 95/98/Me unterscheidet. Ein Bereich, in dem dies offensichtlich ist, ist der Schutz von Dateien. Auf Unix-Systemen wurde traditionell das System »Benutzer, Gruppen, andere« mit seinen 9 Bit verwendet, in dem die Lese-, Schreib- und Ausführungs-Bits separat für den Eigentümer der Datei, die Gruppe, zu der er gehört, und alle anderen Benutzer gesetzt werden können.

Windows 95/98/Me besitzt ein System zum Schutz von Dateien, das eigentlich überhaupt kein Schutz ist. Diese Betriebssystemfamilie wurde aus MS-DOS heraus entwickelt, das als nicht netzwerkfähiges Einbenutzersystem implementiert wurde. Mehrbenutzersicherheit wurde einfach niemals hinzugefügt. Eine offensichtliche Ausnahme hierbei bildet die Sicherheit auf Benutzerebene für freigegebene Dateien, auf die wir in Kapitel 9 näher eingehen. Hier können bestimmten Netzwerk-Client-Benutzern oder -Gruppen eigene Zugriffsrechte zugewiesen werden. Sicherheit auf Benutzerebene auf Windows 95/98/Me-Systemen erfordert jedoch einen Windows NT/2000- oder Samba-Server zur Durchführung der eigentlichen Authentifizierung.

Unter Windows NT/2000/XP stellt Sicherheit auf Benutzerebene eine Erweiterung des systemeigenen Dateisicherheitsmodells dar, das mit Zugriffskontrolllisten (Access Control Lists; ACLs) arbeitet. Dieses System ist ein wenig umfassender als das Unix-Sicherheitsmodell, da es die Festlegung von Zugriffsrechten für einzelne Dateien für eine beliebige Anzahl von Benutzern und/oder Benutzergruppen erlaubt. Die Abbildungen 8-3, 8-4 und 8-5 zeigen die Dialoge, in denen auf einem Windows 2000-System die ACL für eine Datei gesetzt wird. Klicken Sie mit der rechten Maustaste auf das Symbol einer Datei, wählen Sie aus dem Kontextmenü den Eintrag Eigenschaften und klicken Sie auf die Registerkarte Sicherheitseinstellungen. Sie erhalten das Dialogfeld aus Abbildung 8-3. Hier können Sie die grundlegenden Berechtigungen für eine Datei einstellen, die ähnlich den Unix-Berechtigungen sind, allerdings nicht mit ihnen identisch.
Abbildung 8-3
Die Registerkarte Sicherheitseinstellungen des Eigenschaften-Dialogfelds einer Datei

Durch einen Klick auf das Register Erweitert öffnen Sie den Dialog aus Abbildung 8-4, der eine Liste der Berechtigungseinträge in der ACL zeigt. Hier können Einträge in der ACL angelegt oder aus ihr gelöscht werden. Es ist auch möglich, einen existierenden Berechtigungseintrag zu betrachten und zu verändern. Jeder Berechtigungseintrag setzt oder entfernt bestimmte Berechtigungen für einen Benutzer oder eine Gruppe.
Abbildung 8-4
Die Registerkarte Berechtigungen des Dialogfelds Zugriffseinstellungen
Abbildung 8-5
Der Dialog Berechtigungseintrag mit den Einstellungen eines Berechtigungseintrags

Abbildung 8-5 zeigt den Dialog zum Hinzufügen eines Berechtigungseintrags. Wie Sie sehen können, gibt es für die Berechtigungen in einer ACL mehr Optionen, als mit den Berechtigungs-Bits auf typischen Unix-Systemen üblich sind. Mehr über diese Einstellungen erfahren Sie in dem Buch Windows NT System-Administration von O'Reilly.

In einer vernetzten Umgebung, in der ein Samba-Server Windows NT/2000/XP-Clients Dateien bereitstellt, muss Samba die Unix-Berechtigungen für Dateien und Verzeichnisse auf Windows NT/2000/XP-ACLs abbilden. Wenn ein Windows NT/2000/XP-Client auf eine freigegebene Datei oder ein freigegebenes Verzeichnis auf einem Samba-Server zugreift, übersetzt Samba die Eigentümerschaft des Objekts, seine Gruppe und seine Berechtigungen in eine ACL und liefert diese an den Client zurück.

Abbildung 8-6 zeigt den Eigenschaften-Dialog für die Datei shopping_list.doc, die sich auf dem Samba-Server befindet.
Abbildung 8-6
Der Eigenschaften-Dialog für eine Datei auf dem Samba-Server

Aus Sicht von Unix erscheint diese Datei folgendermaßen:

$ ls -l shopping_list.doc
 
-rw-------    1 adilia   users          49 Mar 29 11:58 shopping_list.doc
 

Da die Datei für den Eigentümer eine Leseberechtigung aufweist, ist das Optionsfeld Schreibgeschützt nicht angeklickt, obwohl der Benutzer auf dem Windows-Client (nicht adilia in diesem Beispiel) keine Berechtigung zum Lesezugriff hat. Die Optionsfelder zeigen hier nur die DOS-Attribute. Wenn Sie auf das Register Sicherheit klicken, können Sie die ACLs untersuchen, wie in Abbildung 8-7 zu sehen.
Abbildung 8-7
Die Registerkarte Sicherheitseinstellungen des Eigenschaften-Dialogs für eine Datei auf dem Samba-Server

Der Eigentümer der Datei (adilia) wird als ein Eintrag angezeigt, während die Berechtigungen für die Gruppe (users) und für andere als Gruppen mit der Bezeichnung users und Jeder dargestellt werden. Wenn Sie auf einen der Einträge in den oberen Fenstern klicken, wird die vereinfachte Ansicht der Berechtigungen in diesem Eintrag im unteren Fenster dargestellt. Die Lese-/Schreibberechtigungen für adilia werden hier in einer Weise gezeigt, die das Sicherheitsmodell von Unix und Windows ähnlich erscheinen lässt. Ein Klick auf den Button Erweitert... öffnet jedoch das zusätzliche Dialogfeld aus Abbildung 8-8.
Abbildung 8-8
Der Dialog Zugriffseinstellungen für eine Datei auf dem Samba-Server

In diesem Dialog sehen Sie die tatsächliche ACL der Datei. Die Berechtigungseinträge für users und Jeder sind mit Besitzrechte übernehmen in der Spalte Berechtigung aufgeführt. Dies ist ein Trick, der von Samba für ACLs eingesetzt wird, die keine Berechtigungen auf der Unix-Seite besitzen. Unter Windows ergibt eine ACL, bei der nichts gesetzt ist, überhaupt keine ACL. Deshalb setzt Samba die Berechtigung Besitzrechte übernehmen, um sicherzustellen, dass alle ACLs, die mit den Unix-Berechtigungen für »Benutzer, Gruppe, andere« korrespondieren, unter Windows zu sehen sind. Für die Berechtigung Besitzrechte übernehmen gibt es kein entsprechendes Unix-Attribut, die Einstellung unter Windows hat also keinen Einfluss auf die tatsächliche Datei auf dem Unix-System. Windows-Benutzer könnten jetzt zwar fälschlicherweise annehmen, dass sie Eigentümer der Datei werden (d.h. die Eigentümerschaft der Datei auf sich selbst ändern), ein entsprechender Versuch würde jedoch fehlschlagen.

Die Berechtigung-Spalte für die adilia-ACL ist als Speziell gekennzeichnet, da Samba Berechtigungen für die Datei aufführt, die nicht mit Einstellungen korrespondieren, für die Windows einen aussagekräftigeren Namen hat. Wenn Sie zuerst auf den Eintrag und anschließend auf den Button Anzeigen/Bearbeiten... klicken, öffnet sich der Dialog aus Abbildung 8-9, der die Details der ACL-Berechtigungen zeigt, die möglicherweise geändert werden können.
Abbildung 8-9
Der Dialog Berechtigungseintrag für eine von Samba bereitgestellte Datei

Wir sagen »möglicherweise«, da das Aktivieren oder Deaktivieren von Optionsfeldern in diesem Dialog nicht unbedingt zu Einstellungen führt, die Samba wieder auf das Unix-Sicherheitsmodell zurückführen kann. Wenn ein Benutzer versucht, eine Einstellung (entweder Berechtigungen oder Eigentümerschaft) zu ändern, die er nicht ändern darf oder die nicht mit einer gültigen Einstellung auf dem Unix-System korrespondiert, antwortet Samba entweder mit einer Fehlermeldung, oder es ignoriert diese Einstellungen stillschweigend.

Die ACLs für ein Verzeichnis sind ein wenig anders. Abbildung 8-10 zeigt die ACL nach einem Klick auf den Button Erweitert.
Abbildung 8-10
Der Dialog Zugriffseinstellungen für ein Verzeichnis auf dem Samba-Server

Hier gibt es jeweils zwei ACLs für users und Jeder. Eine ACL legt die Berechtigungen für das Verzeichnis selbst fest, und die andere gibt die Berechtigungen für den Inhalt des Verzeichnisses an. Beim Ändern von Einstellungen im Dialog Anzeigen/Bearbeiten... gibt es ein zusätzliches Drop-down-Menü, um die Einstellungen entweder nur auf das Verzeichnis oder auf eine Kombination aus dem Verzeichnis und den Dateien und Verzeichnissen, die dieses enthält, anzuwenden. Werden die Einstellungen auf mehr als nur das Verzeichnis angewendet, passt sich Samba an das Verhalten eines Windows-Servers an und ändert die Berechtigungen für den Inhalt des Verzeichnisses entsprechend diesem Dialog.

Unix-ACLs

In den meisten Fällen werden Benutzer von Windows-Clients das Unix-Sicherheitsmodell ausreichend finden. Manchmal wollen Anwender jedoch, dass der Samba-Server das komplette Windows-ACL-Sicherheitsmodell unterstützt. Selbst wenn sie die ausgeklügelte Kontrolle über Datei- und Verzeichnisberechtigungen nicht benötigen, werden sie Sambas Übersetzung zwischen ACLs und Unix-Berechtigungen verwirrend und frustrierend finden.

Wenn das zu Grunde liegende Unix-Host-Betriebssystem POSIX.1e-ACLs unterstützt, bietet Samba eine viel bessere Unterstützung für Windows NT/2000/XP-ACLs. Folgende Versionen von Unix enthalten die notwendige Funktionalität:

Sollten Sie in der glücklichen Lage sein, ein Unix-Host-Betriebssystem zu haben, in das die ACL-Unterstützung bereits integriert ist, müssen Sie Samba jetzt lediglich noch einmal mit der Konfigurationsoption --with-acl-support kompilieren, wie wir in Kapitel 2 beschrieben haben. Falls Sie Linux betreiben und einen Kernel-Patch einspielen müssen, wird es etwas komplizierter. Wir empfehlen Ihnen, sich an die Dokumentation zu halten, die mit dem Patch geliefert wurde. Dort finden Sie alle notwendigen Informationen.

Konfigurationsoptionen für ACLs

Tabelle 8-3 zeigt die Samba-Konfigurationsoptionen zum Arbeiten mit Windows NT/2000/XP-Zugriffskontrolllisten.

Tabelle 8-3
ACL-Konfigurationsoptionen
Option
Parameter
Funktion
Vorgabewert
Geltungsbereich
nt acl support
Boolescher Wert
Wenn yes, ist es den Benutzern auf Windows NT/2000/XP-Clients erlaubt, die ACL-Einstellungen zu verändern.
yes
Freigabe
security mask
numerischer Wert
Bit-Maske, die Berechtigungseinstellungen auf Dateien erlaubt oder verbietet.
0777
Freigabe
force security mode
numerischer Wert
Bits, die immer gesetzt sind, wenn die Dateiberechtigungen modifiziert werden.
0000
Freigabe
directory
security mask
numerischer Wert
Bit-Maske, die Berechtigungseinstellungen auf Verzeichnissen erlaubt oder verbietet.
0777
Freigabe
force directory security mode
numerischer Wert
Bits, die immer gesetzt sind, wenn die Verzeichnisberechtigungen modifiziert werden.
0000
Freigabe

nt acl support

Dieser Parameter ist standardmäßig yes. Dadurch ist es Benutzern auf Windows NT/2000/ XP-Clients erlaubt, die ACL-Einstellungen für Dateien auf dem Samba-Server zu verändern. Ist er auf no gesetzt, wird als Eigentümer für die Dateien Jeder angezeigt, die Berechtigungen stehen auf »Vollzugriff«. Als tatsächliche Eigentümerschaft und Berechtigungen werden jedoch die Werte erzwungen, die auf dem Samba-Server eingestellt sind. Der Benutzer auf dem Windows-Client kann sie mit den Dialogfeldern zum Verwalten von ACLs nicht betrachten oder verändern.

Ist die Option aktiviert, ist die Unterstützung für Windows NT/2000/XP-ACLs auf das beschränkt, was Eigentümerschaften und Berechtigungen auf gültige Benutzer und Berechtigungen auf dem Samba-Server abbilden können. Falls der Server ACLs unterstützt (entweder direkt oder mit einem zusätzlichen Patch zum Erweitern des Dateisystems), entspricht die ACL-Unterstützung von Samba eher der eines Windows NT/2000/ XP-Servers.

security mask

Mit der Option security mask ist es möglich zu definieren, welche Dateiberechtigungen Benutzer von Windows NT/2000/XP-Clients aus ändern dürfen. Dies gilt nur für Dateien. Für Verzeichnisse gibt es die Option directory security mask. Dem Parameter wird ein numerischer Wert zugewiesen, bei dem es sich um eine Berechtigungsmaske im Unix-Stil handelt. Für in der Maske gesetzte Bits darf der Client die entsprechenden Bits in den Berechtigungen der Dateien verändern. Ist das Bit null, kann der Client diese Berechtigung nicht modifizieren. Wenn security mask beispielsweise als:

[data]
 
	security mask = 0777
 

gesetzt ist, darf der Client alle Berechtigungen von Benutzer/Gruppen/andere der Dateien in der Freigabe ändern. Das ist die Voreinstellung. Ein Wert von 0 würde den Clients das Ändern der Berechtigungen verbieten. Wird security mask als:

[data]
 
	security mask = 0666
 

gesetzt, ist es den Benutzern auf den Clients erlaubt, die Lese- und Schreibrechte, nicht jedoch die Ausführungsrechte zu verändern.

Verlassen Sie sich nicht auf security mask, wenn Sie eine vollständige Kontrolle wünschen. Wenn nämlich der Benutzer auf einem anderen Weg auf die Dateien auf dem Samba-Server zugreifen kann (zum Beispiel indem er sich direkt auf dem Unix-Host anmeldet), kann er die Berechtigungen über diese Methode verändern.

force security mode

Die Option force security mode kann verwendet werden, um eine Gruppe von Berechtigungen einzustellen, die immer gesetzt bleiben, wenn ein Benutzer auf einem Windows NT/2000/XP-Client die Berechtigungen einer Datei verändert. (Siehe die Option force directory security mode für die Behandlung von Verzeichnissen.)

Sie müssen diese Option unbedingt richtig verstehen. Die Maske, die als Wert des Parameters angegeben wird, ist nicht unbedingt identisch mit den endgültigen Berechtigungen auf der Datei. Die Berechtigungen, die der Benutzer auf dem Client zu verändern versucht, werden mit der Option force security mode mask logisch ODER-verknüpft. Alle Bits, die eingeschaltet sind, veranlassen, dass die entsprechenden Berechtigungen auf der Datei gesetzt sind. Nehmen Sie zum Beispiel an, dass force security mode in einer Freigabe folgendermaßen gesetzt ist:

[data]
 
	force security mode = 0440
 

(Dies setzt das Lese-Bit für den Eigentümer und die Gruppe, nicht jedoch für andere.) Wenn ein Benutzer auf einem Windows NT/2000/XP-Client eine ACL auf einer Datei in der Freigabe [data] verändert und versucht, alle Leseberechtigungen zu entfernen, wird die Leseberechtigung für andere (Jeder) gelöscht, die Leseberechtigungen für den Eigentümer und die Gruppe dagegen bleiben bestehen. Beachten Sie, dass dieser Parameter sich nicht dazu eignet, ein Berechtigungs-Bit auszuschalten.

Wie bei der Option security mask gilt, dass ein Benutzer, der eine andere Möglichkeit als Samba besitzt, auf die Dateien in der Freigabe zuzugreifen, leicht den Einfluss von Samba auf diesen Parameter umgehen kann.

Der Vorgabewert für force security mode lautet 0000, wodurch es Benutzern erlaubt wird, alle Berechtigungen von Dateien zu entfernen.

directory security mask

Diese Option funktioniert genauso wie die Option security mask, allerdings gilt sie für Verzeichnisse und nicht für Dateien. Ebenso wie security mask hat sie den Standardwert 0777, der es Benutzern auf Windows NT/2000/XP-Clients erlaubt, alle Unix-Berechtigungen auf Verzeichnissen in der Freigabe zu verändern.

force directory security mode

Diese Option funktioniert genauso wie die Option force security mode, allerdings gilt sie für Verzeichnisse und nicht für Dateien. Sie besitzt den Vorgabewert 0000, der es Benutzern auf Windows NT/2000/XP-Clients erlaubt, alle Unix-Berechtigungen auf Verzeichnissen in der Freigabe zu entfernen.

Namensverkürzung und Groß-/Kleinschreibung

In den Tagen von DOS und Windows 3.1 durften Dateinamen aus nicht mehr als acht Großbuchstaben, gefolgt von einem Punkt und drei weiteren Großbuchstaben bestehen. Diese Schreibweise wurde als 8.3-Format bezeichnet und stellte ein großes Ärgernis dar. Windows 95/98/Me, Windows NT/2000/XP und Unix haben dieses Problem seither entspannt, indem sie längere Dateinamen erlaubten, die manchmal sogar eine gemischte Schreibweise aufweisen durften. Tabelle 8-4 zeigt die aktuellen Benennungsmöglichkeiten einiger beliebter Betriebssysteme.

Tabelle 8-4
Dateinamenbeschränkungen von Betriebssystemen 
Betriebssystem
Regeln zur Benennung von Dateien
DOS 6.22 oder niedriger
Acht Zeichen, gefolgt von einem Punkt und einer dreibuchstabigen Erweiterung (8.3-Format); Groß-/Kleinschreibung wird nicht beachtet.
Windows 3.1 for Workgroups
Acht Zeichen, gefolgt von einem Punkt und einer dreibuchstabigen Erweiterung (8.3-Format); Groß-/Kleinschreibung wird nicht beachtet.
Windows 95/98/Me
255 Zeichen; Groß-/Kleinschreibung wird nicht beachtet, Schreibweise wird aber beibehalten.
Windows NT/2000/XP
255 Zeichen; Groß-/Kleinschreibung wird nicht beachtet, Schreibweise wird aber beibehalten.
Unix
255 Zeichen; Groß-/Kleinschreibung wird beachtet.

Samba muss mit Netzwerk-Clients kompatibel sein, die ihre Dateien immer noch im 8.3-Format speichern, wie etwa Windows for Workgroups. Erzeugt ein Benutzer auf einer Freigabe eine Datei namens antidisestablishmentarianism.txt, kann ein Windows for Workgroups-Client diese nicht von einer anderen Datei im gleichen Verzeichnis namens antidisease.txt unterscheiden. Ebenso wie Windows 95/98/Me und Windows NT/2000/ XP muss Samba eine besondere Methode entwickeln, um einen langen Dateinamen so in einen 8.3-Dateinamen umzuwandeln, dass ähnliche Dateinamen keine Konflikte auslösen. Dieser Vorgang wird Namensverkürzung genannt. Samba führt ihn in einer Weise aus, die ähnlich, aber nicht identisch mit Windows 95 und seinen Nachfolgern ist.

Funktion der Samba-Namensverkürzung

Und so verkürzt Samba einen langen Dateinamen zu einem 8.3-Dateinamen:

Hier sind einige Beispiele:

virtuosity.dat                       VIRTU~F1.DAT
 
.htaccess                            HTACC~U0._ _ _
 
hello.java                           HELLO~1F.JAV
 
team.config.txt                      TEAMC~04.TXT
 
antidisestablishmentarianism.txt     ANTID~E3.TXT
 
antidisease.txt                      ANTID~9K.TXT
 

Auf diese Weise kann Windows for Workgroups die beiden Dateien für den bedauernswerten Anwender unterscheiden, der gezwungen ist, das Netzwerk nur aus der Perspektive dieses Betriebssystems zu sehen. Beachten Sie, dass ein langer Dateiname mit Samba immer zum selben kurzen Dateinamen gewandelt werden sollte. Das ist bei Windows nicht immer der Fall. Der Nachteil dieses Verfahrens besteht darin, dass es Kollisionen nicht ausschließt. Die Wahrscheinlichkeit von Kollisionen ist aber sehr gering.

Sie werden im Allgemeinen die Namensverkürzung für die Kompatibilität mit den ältesten Clients konfigurieren wollen. Wir empfehlen Ihnen, dies auf eine Weise zu tun, die andere Clients nicht stört. Dazu fügen Sie eine include-Anweisung in die smb.conf-Datei ein:

[global]
 
	include = /usr/local/samba/lib/smb.conf.%a
 

Dies ergibt smb.conf.WfWg, wenn ein Windows for Workgroups-Client eine Verbindung herstellt. Sie können jetzt die Datei /usr/local/samba/lib/smb.conf.WfWg mit folgenden Optionen erstellen:

[global]
 
	case sensitive = no
 
	default case = upper
 
	preserve case = no
 
	short preserve case = no
 
	mangle case = yes
 
	mangled names= yes
 

Falls Sie Windows for Workgroups nicht benutzen, können Sie wahrscheinlich für diese Optionen die Vorgabewerte stehen lassen.

Dateinamen mit Samba speichern und suchen

In diesem Zusammenhang ist auch der Unterschied zwischen dem Speichern und Suchen von Dateinamen im Betriebssystem wichtig. Wenn Sie mit Windows arbeiten, sind Sie sicherlich bereits auf Dateien mit dem Namen README.TXT gestoßen. Der Name der Datei besteht möglicherweise ausschließlich aus Großbuchstaben. Wenn Sie aber die MS-DOS-Eingabeaufforderung öffnen und den Befehl:

C:\> notepad readme.txt
 

eingeben, wird die Datei korrekt in den Windows-Editor geladen, obwohl sie den Namen mit Kleinbuchstaben geschrieben haben.

Der Grund dafür ist, dass die Betriebssystemfamilien Windows 95/98/Me und Windows NT/2000/XP bei der Suche nach Dateinamen die Groß-/Kleinschreibung nicht beachten, während die Groß-/Kleinschreibung beim Speichern von Dateien beachtet und beibehalten wird. Unix-basierte Betriebssysteme unterscheiden im Gegensatz dazu streng zwischen Groß- und Kleinschreibung. Wenn Sie die Datei README.TXT mit dem Befehl:

$ vi readme.txt
 

bearbeiten wollen, erstellt der Editor wahrscheinlich eine neue, leere Datei.

Und so geht Samba mit Groß-/Kleinbuchstaben um: Wenn Sie preserve case auf yes setzen, verwendet Samba immer den vom Client gelieferten Namen zum Speichern (nicht zum Suchen) von Dateinamen. Wenn Sie den Wert dieser Option auf no setzen, verwendet Samba den Wert der Option default case. Dasselbe gilt für short preserve case. Wenn Sie hier yes angeben, verwendet Samba die vorgegebene Groß-/Kleinschreibung des Betriebssystems für 8.3-Dateinamen, bei no den Wert der Option default case. Zur Suche von Dateinamen in seinen Freigaben zieht Samba schließlich den Wert der Option case sensitive heran.

Optionen für die Namensabkürzung

Mit Samba können Sie genau festlegen, wie die Namensverkürzung arbeiten soll: Sie besitzen die Kontrolle über Groß-/Kleinschreibung, das Abkürzungszeichen und können eine direkte Zuordnung von bestimmten Dateinamen angeben. Wir haben die Optionen für die Namensverkürzung in Tabelle 8-5 zusammengefasst.

Tabelle 8-5
Optionen für die Namensverkürzung
Option
Parameter
Funktion
Vorgabewert
Geltungsbereich
case sensitive
(casesignames)
Boolescher Wert
Wenn yes, wird die Groß-/Kleinschreibung bei Dateinamen beachtet (bei Windows nicht der Fall).
no
Freigabe
default case
String (upper oder lower)
Schreibweise, die als Vorgabe betrachtet werden soll (wird nur verwendet, wenn preserve case den Wert no hat).
lower
Freigabe
preserve case
Boolescher Wert
Wenn yes, wird die Schreibweise beibehalten, die der Client liefert (d.h., es wird nicht nach default case konvertiert).
yes
Freigabe
short preserve case
Boolescher Wert
Wenn yes, wird die Schreibweise der Namen im 8.3-Format beibehalten, die der Client liefert.
yes
Freigabe
mangled names
Boolescher Wert
Verkürzt lange Namen zum 8.3-DOS-Format.
yes
Freigabe
mangle case
Boolescher Wert
Verkürzt einen Namen, wenn dieser in gemischter Schreibweise vorliegt.
no
Freigabe
mangling char
String (einzelnes Zeichen)
Legt das Abkürzungszeichen fest.
~
Freigabe
mangled stack
numerischer Wert
Anzahl der verkürzten Namen, die im lokalen Abkürzungs-Stack verbleiben sollen.
50
global
mangled map
String (Liste mit Mustern)
Erlaubt die Zuordnung von Dateinamen von einem Format in ein anderes.
keiner
Freigabe

case sensitive
Diese Option auf Freigabeebene, die auch auf den ungewöhnlichen Namen casesignames hört, legt fest, ob Samba die Groß-/Kleinschreibung beachten soll, wenn es in einer bestimmten Freigabe einen Dateinamen sucht. Die Voreinstellung dieser Option ist no, so dass Samba hier wie Windows verfährt. Wenn Clients ein Betriebssystem verwenden, das die Groß-/ Kleinschreibung nicht nur beim Speichern, sondern auch beim Auffinden von Dateien beachtet, können Sie diese Konfigurationsoption auf yes setzen, wie hier gezeigt wird:
[accounting]
 
	case sensitive = yes
 

Ansonsten empfehlen wir, den Vorgabewert dieser Option stehen zu lassen.

default case

Die Option default case wird zusammen mit preserve case benutzt. Sie legt fest, ob Samba beim Erstellen von Dateien auf einer seiner Freigaben Groß- oder Kleinbuchstaben (upper oder lower) für den Dateinamen verwenden soll. Die Vorgabe ist lower, so dass Namen von neu erstellten Dateien aus Kleinbuchstaben bestehen. Bei Bedarf können Sie diese globale Option außer Kraft setzen. Geben Sie dazu Folgendes an:

[global]
 
	default case = upper
 

Wenn Sie diesen Wert festlegen, erhalten neue Dateien einen Namen aus Großbuchstaben. Dieser Name kann in einem Programm nicht überschrieben werden. Wir empfehlen Ihnen die Verwendung der Vorgabewerte, sofern in Ihr Netz keine Clients mit Windows for Workgroups oder andere Clients eingebunden sind, die lediglich das 8.3-Format beherrschen. In diesen Fällen sollten Sie den Wert auf upper setzen.

preserve case

Diese Option bestimmt, ob eine Datei, die von Samba für den Client erzeugt wurde, die vom Client gelieferte Groß-/Kleischreibung beibehalten oder die von der Konfigurationsoption default case festgelegte Schreibweise annehmen soll. Vorgabewert ist yes, das heißt, es wird die vom Client gelieferte Schreibweise behalten. Ist die Option auf no gesetzt, wird der Wert der Option default case (upper oder lower) verwendet.

Beachten Sie, dass sich diese Option nicht auf 8.3-Dateinamen auswirkt - dazu dient die im nächsten Absatz beschriebene Option short preserve case. Sie sollten hier zum Beispiel yes angeben, wenn Anwendungen, die Dateien auf dem Samba-Server anlegen, die Datei in Großbuchstaben anfordern. Soll Samba dagegen das Verhalten eines Windows NT-Dateisystems nachahmen, können Sie den Vorgabewert (yes) verwenden.

short preserve case

Diese Option gibt an, ob ein 8.3-Dateiname, der von Samba für den Client erzeugt wurde, die vom Client gelieferte Schreibweise beibehält oder ob die durch die Konfigurationsoption default case festgelegte Schreibweise verwendet wird. Vorgabewert ist yes, das heißt, die vom Client vorgegebene Schreibweise wird beibehalten. Sie können Samba die Schreibweise über die Option default case wählen lassen, indem Sie Folgendes einstellen:

[global]
 
	short preserve case = no
 

Soll Samba dagegen das Verhalten eines Windows NT-Dateisystems nachahmen, können Sie den Vorgabewert (yes) verwenden.

mangled names

Diese Option auf Freigabeebene legt fest, ob Samba lange Dateinamen für 8.3-Clients verkürzt. Nehmen Sie den Wert no, verkürzt Samba lange Dateinamen nicht, so dass Betriebssysteme, die lediglich das 8.3-Format kennen, diese Dateien entweder mit abgeschnittenen Namen oder aber gar nicht sehen (je nach Client). Die Voreinstellung ist yes. Sie können diesen Wert in einer Freigabe folgendermaßen außer Kraft setzen:

[data]
 
	mangled names = no
 
mangle case

Der Wert dieser Option bestimmt, ob Samba lange Dateinamen verkürzen soll, die nicht ausschließlich in der von der Option default case angegebenen Schreibweise geschrieben sind, nämlich ausschließlich groß oder klein. Die Vorgabe ist no. Wenn Sie den Wert dieser Option auf yes festlegen, sollten Sie sicher sein, dass alle Clients mit den resultierenden abgekürzten Dateinamen zurechtkommen. Verwenden Sie diese Option wie folgt:

[data]
 
	mangle case = yes
 

Wir empfehlen, nur dann zu dieser Option zu greifen, wenn Sie dafür einen triftigen Grund haben.

mangling char

Diese Option auf Freigabeebene gibt das Abkürzungszeichen an, das abgekürzte 8.3-Dateinamen enthalten sollen. Der Vorgabewert ist die Tilde (~). Sie können jedoch auch jedes andere Zeichen dafür einsetzen, wie im folgenden Beispiel:

[data]
 
	mangling char = #
 
mangled stack

Samba verwaltet einen lokalen Stack kürzlich abgekürzter 8.3-Dateinamen, der herangezogen wird, um die gekürzten Dateinamen wieder in lange Namen zu verwandeln. Das erweist sich als nützlich, wenn Anwendungen eine Datei erstellen, speichern und schließen und sie später wieder verändern wollen. Standardmäßig merkt sich Samba die letzten 50 verwendeten Paare von langen Dateinamen und ihren Abkürzungen. Wenn Sie die CPU-Belastung verringern wollen, die durch die Abkürzung von Dateinamen hervorgerufen wird, können Sie den Stack vergrößern, wodurch Samba natürlich mehr Hauptspeicher beansprucht und der Dateizugriff geringfügig langsamer wird:

[global]
 
	mangled stack = 100
 
mangled map

Wenn das vorgegebene Verfahren zur Namensabkürzung nicht Ihren Wünschen oder Erfordernissen entspricht, können Sie Samba mit der Option mangled map detailliertere Anweisungen geben. Diese Option erlaubt es, Zeichenmuster vorzugeben, die Samba an Stelle der gewöhnlichen Namensverkürzung verwenden soll. Hier ein Beispiel:

[data]
 
	mangled map =(*.database *.db) (*.class *.cls)
 

In diesem Fall durchsucht Samba jeden Dateinamen, auf den es trifft, auf Zeichen im ersten Zeichenmuster hin, konvertiert ihn in das zweite Muster, das innerhalb eines Klammernpaars angegeben ist, und erzeugt so einen 8.3-Dateinamen. Das ist nützlich, wenn bestimmte Namen vom gewöhnlichen Abkürzungsverfahren nicht korrekt konvertiert werden oder wenn dadurch ein Dateiname entsteht, den ein Client nicht richtig erkennt. Die Muster werden durch Leerzeichen voneinander getrennt.

Sperren und Oplocks

Dass zwei Anwendungen gleichzeitig in dieselbe Datei schreiben, ist nicht wünschenswert, und zwar in keinem Betriebssystem. Die meisten Betriebssysteme verwenden Sperren (Locks), um sicherzustellen, dass zu einem bestimmten Zeitpunkt nur jeweils genau ein Prozess in eine Datei schreiben kann. Traditionell sperren Betriebssysteme ganze Dateien, wohingegen neuere Ansätze auch das Sperren von Dateibereichen erlauben. Wenn ein anderer Prozess in die gesperrte Datei (oder in den gesperrten Bereich einer Datei) schreiben will, erhält er eine Fehlermeldung vom Betriebssystem und muss warten, bis die Sperre aufgehoben wird

Samba unterstützt die Standard-(Deny Mode-)Sperranfragen der DOS- und NT-Dateisysteme, mit denen ein Prozess die Sperre einer ganzen Datei oder eines Dateibereichs anfordern kann. Außerdem unterstützt Samba einen Sperrmechanismus, der in der Windows NT-Welt als opportunistisches Sperren (engl. Opportunistic Locking, kurz Oplock) bekannt ist.

Opportunistisches Sperren

Mit Oplocks kann ein Client den Samba-Server darüber benachrichtigen, dass er nicht nur exklusiv in eine Datei schreiben möchte, sondern Änderungen auch lokal zwischenspeichert, also nicht sofort an den Samba-Server schickt. Durch diese lokale Speicherung erhöht sich die Zugriffsgeschwindigkeit, da der Weg über das Netzwerk entfällt. Die erreichte Leistungssteigerung beträgt typischerweise etwa 30 Prozent, gleichzeitig wird Netzwerkbandbreite für andere Aufgaben reserviert.

Da der exklusive Zugriff auf eine Datei auch über normale Dateisperren erreicht werden kann, liegt der Wert der Oplocks nicht so sehr in der Sperre einer Datei, sondern eher im Zwischenspeichern. Eine bessere Bezeichnung für opportunistische Sperren wäre deshalb eigentlich opportunistisches Caching.

Wenn ein Client Samba eine Oplock-Anforderung für eine Datei sendet, markiert Samba die Datei als opportunistisch gesperrt und wartet ab, bis der Client seine Arbeit beendet hat, wobei er alle Änderungen an den Samba-Server schickt, um die Datei abzugleichen.

Fordert ein zweiter Client die Datei an, bevor der erste Client ihre Bearbeitung abgeschlossen hat, kann Samba dem ersten Client eine Oplock-Unterbrechungsanforderung (Oplock-Break) zukommen lassen. Dabei handelt es sich um eine Aufforderung, die Zwischenspeicherungen zu beenden und dem Server die Datei in ihrem gegenwärtigen Zustand zu übermitteln, so dass dieser die Datei an den zweiten Client schicken kann. Ein Oplock ist aber kein Ersatz für das Standard-(Deny Mode-)Sperren. Es kommt vor, dass der unterbrechende Prozess, nachdem ihm eine Oplock-Unterbrechung zugestanden wurde, feststellt, dass der ursprüngliche Prozess zusätzlich eine Deny Mode-Sperre auf die Datei besitzt. Abbildung 8-11 veranschaulicht den Vorgang einer opportunistischen Sperre.
Abbildung 8-11
Opportunistisches Sperren

In den meisten Fällen ist die Leistungssteigerung, die aus dem Einsatz von Oplocks resultiert, äußerst wünschenswert. Allerdings kann es ziemlich riskant sein, dem Client zu erlauben, die Daten zwischenzuspeichern, nämlich dann, wenn die Client- oder die Netzwerk-Hardware nicht sehr zuverlässig ist. Stellen Sie sich vor, ein Client öffnet eine Datei zum Schreiben, wobei er einen Oplock darauf erzeugt. Wenn ein anderer Client ebenfalls versucht, die Datei zu öffnen, wird an den ersten Client eine Oplock-Unterbrechungsanforderung gesandt. Wird diese Anforderung aus welchen Gründen auch immer nicht erfüllt und der zweite Client beginnt mit dem Schreiben der Datei, kann die Datei durch das gleichzeitige Schreiben der zwei Prozesse leicht zerstört werden. Leider ist dieses Szenario nicht unrealistisch. Solch unkoordiniertes Verhalten wurde schon oft zwischen Windows-Clients in SMB-Netzwerken (in denen die Dateien von Windows NT/2000 oder Samba bereitgestellt wurden) beobachtet. Typischerweise handelt es sich bei den betroffenen Dateien um Datenbankdateien, die von mehreren Clients zum gleichzeitigen Schreiben geöffnet wurden.

Ein konkreteres Beispiel für das Fehlschlagen von Oplocks tritt auf, wenn Datenbankdateien sehr groß sind. Wenn einem Client erlaubt wird, eine solche Datei mit einem Oplock zu belegen, kann eine große Verzögerung auftreten, während der Client die Datei vom Server in seinen Zwischenspeicher kopiert, auch wenn nur ein Datensatz aktualisiert werden muss. Es wird noch schlimmer, wenn ein anderer Client versucht, die gesperrte Datei zu öffnen. Der erste Client müsste die gesamte Datei wieder auf den Server zurückschreiben, bevor die Öffnungsanforderung des zweiten Clients erfolgreich sein kann. Dadurch ergibt sich eine weitere große Verzögerung (für beide Clients), die in der Praxis oft dazu führt, dass für den zweiten Client das Öffnen fehlschlägt, da inzwischen ein Timeout aufgetreten ist. Zusätzlich kommt es vermutlich zu einer Warnung vor einer möglichen Zerstörung der Datenbank!

Falls bei Ihnen solche Probleme auftreten, können Sie die Oplocks der betroffenen Dateien mit dem Parameter veto oplock files deaktivieren:

[dbdata]
 
	veto oplock files = /*.dbm/
 

Verwenden Sie den Wert des Parameters (eine Liste von Dateinamensmustern, getrennt durch Schrägstriche), um alle Dateien in der Freigabe zu erfassen, die Ärger verursachen. Die Syntax dieses Parameters ist ähnlich der des Parameters veto files.

Falls Sie wirklich vorsichtig sein wollen und mit einer geringeren Leistung leben können, können Sie Oplocks ganz und gar deaktivieren. Dann tritt das Problem mit den Oplock-Unterbrechungsanforderungen überhaupt nicht auf:

[global]
 
	oplocks = no
 

Dies deaktiviert Oplocks für alle Dateien in allen Freigaben, die vom Samba-Server bereitgestellt werden. Falls Sie die Oplocks nur in einer bestimmten Freigabe deaktivieren wollen, geben Sie den Parameter oplocks = no nur in dieser Freigabe an:

[database]
 
	oplocks = no
 

Dieses Beispiel erlaubt es anderen Freigaben, die weniger sensible Daten enthalten, eine bessere Leistung zu erzielen, während die Leistung in der Freigabe [database] zu Gunsten einer verbesserten Integrität der Daten in der Freigabe geopfert wird.

Unix und Oplocks

Im Normalfall helfen Oplocks den Windows-Client-Systemen, das gegenseitige Überschreiben von Daten zu vermeiden. Unix-Systeme besitzen ebenfalls Dateisperrungsmechanismen, mit deren Unterstützung Unix-Prozesse zusammenarbeiten können. Wird auf eine Datei, die auf einem Samba-System gespeichert ist, jedoch sowohl von einem Windows-Netzwerk-Client als auch von einem lokalen Unix-Prozess zugegriffen - ohne dass eine zusätzliche Koordination zwischen den beiden Systemen erfolgt -, könnte der Unix-Prozess leicht über einen Oplock hinweggehen.

Manche Unix-Systeme verfügen über verbesserte Kernel, die von Samba verwaltete Windows-Oplocks verstehen. Momentan gibt es eine solche Unterstützung nur in SGI Irix und Linux.

Wenn Sie die Oplocks aktiviert lassen und Ihr Unix-System keine Kernel-Oplocks unterstützt, erhalten Sie möglicherweise zerstörte Daten, sobald jemand einen Unix-Prozess startet, der eine Datei schreibt oder liest, auf die Windows-Benutzer ebenfalls Zugriff haben. Auch hier kann der Parameter veto oplock files angewendet werden, vorausgesetzt, Sie können vorhersagen, welche Samba-Dateien dies betrifft. Nehmen Sie beispielsweise an, die Freigabe [usrfiles] enthält einige ASCII-Textdateien mit der Erweiterung .txt sowie OpenOffice-Dokumente mit der Erweiterung .doc, die sowohl von Unix- als auch von Windows-Benutzern modifiziert werden. Sie können veto oplock files folgendermaßen einsetzen:

[usrfiles]
 
	veto oplock files = /*.txt/*.doc/
 

Dies unterdrückt die Anwendung von Oplocks auf .txt- und .doc-Dateien, wodurch die Zwischenspeicherung auf den Clients verhindert wird. Windows- und Unix-Programme können dagegen weiterhin die normalen Dateisperren einsetzen, um ein gleichzeitiges Schreiben der gleichen Datei zu verhindern.

Konfigurationsoptionen für Sperren und Oplocks

Sambas Optionen für Sperren und Oplocks sind in Tabelle 8-6 aufgeführt.

Tabelle 8-6
Konfigurationsoptionen für Sperren und Oplocks 
Option
Parameter
Funktion
Vorgabewert
Geltungsbereich
locking
Boolescher Wert
Wenn yes, werden Dateibereichssperren aktiviert.
yes
Freigabe
strict locking
Boolescher Wert
Wenn yes, wird der Zugriff auf eine ganze Datei verwehrt, wenn eine Dateibereichssperre darin existiert.
no
Freigabe
posix locking
Boolescher Wert
Wenn yes, werden Oplocks im lokalen System auf POSIX-Sperren abgebildet.
yes
Freigabe
oplocks
Boolescher Wert
Wenn yes, wird die lokale Zwischenspeicherung von Dateien auf dem Client für diese Freigabe aktiviert.
yes
Freigabe
kernel oplocks
Boolescher Wert
Wenn yes, wird signalisiert, dass der Kernel Oplocks unterstützt.
yes
global
level2 oplocks
Boolescher Wert
Wenn yes, ist es möglich, bei Oplocks auf einen Schreibschutz zurückzugehen.
yes
Freigabe
fake oplocks
Boolescher Wert
Wenn yes, wird dem Client mitgeteilt, dass eine Sperre ausgelöst wurde, die Datei wird aber nicht wirklich gesperrt.
no
Freigabe
blocking locks
Boolescher Wert
Erlaubt es demjenigen, der eine Sperre anfordert, zu warten, bis die Sperre gewährt wurde.
yes
Freigabe
veto oplock files
String (Liste mit Dateinamen)
Löst keinen Oplock auf den angegebenen Dateien aus.
keiner
Freigabe
lock directory
String (voll qualifizierter Pfadname)
Legt fest, wo verschiedene Samba-Dateien, einschließlich der Sperren, gespeichert werden.
wie im Samba-makefile angegeben
global

locking

Über die Option locking wird Samba angewiesen, die Server-seitige Sperrung von Dateibereichen für den Client zu (de)aktivieren. Samba implementiert Server-seitige Bereichssperren mit gewöhnlichen Advisory-Sperren von Unix und hindert damit andere Prozesse daran, die gesperrten Dateibereiche zu überschreiben (sofern sich die Unix-Prozesse korrekt verhalten).

Diese Option kann in einer Freigabe folgendermaßen festgelegt werden:

[accounting]
 
	locking = yes
 

Wenn der Wert der locking-Option auf yes gesetzt ist, werden Anfragen so lange verzögert, bis der Besitzer einer Sperre sie aufhebt (oder aber sie abstürzt). Wenn Sie den Wert dieser Option auf no setzen, benutzt Samba für die Dateien dieser Freigabe keine Bereichssperren, aber Sperrversuche und Aufhebungen scheinen für den Client zu gelingen. Der Wert dieser Option beträgt standardmäßig yes. Sie können die Option für schreibgeschützte Datenträger deaktivieren.

strict locking

Diese Option prüft bei jedem Dateizugriff, ob eine Bereichssperrung aktiv ist. Das ist normalerweise nicht notwendig, wenn ein Client sich an die verwendeten Sperrmechanismen hält, deshalb beträgt der Wert standardmäßig no; Sie können ihn aber für jede gewünschte Freigabe ändern:

[accounting]
 
	strict locking = yes
 

Wenn der Wert dieser Option yes ist, sperrt Samba Dateien mit Bereichssperren vollständig.

posix locking

Auf Systemen, die POSIX-Sperren unterstützen, bildet Samba automatisch Oplocks auf POSIX-Sperren ab. Dieses Verhalten kann mit posix locking = no deaktiviert werden. Es sollte aber niemals notwendig sein, das vorgegebene Verhalten, also posix locking = yes, zu ändern.

oplocks

Diese Option aktiviert oder deaktiviert die Unterstützung für Oplocks auf dem Client. Sie ist standardmäßig aktiviert. Sie können sie jedoch mit dem folgenden Befehl deaktivieren:

[data]
 
	oplocks = no
 

Wenn Ihr Netzwerk extrem instabil ist oder Sie viele Clients verwenden, die Oplocks nicht unterstützen, kann es sinnvoll sein, diese Samba-Funktion abzuschalten. Deaktivieren Sie Oplocks, wenn Benutzer sowohl von SMB-Clients als auch von Unix-Anwendungen (wie vi  ) auf die gleichen Dateien zugreifen, es sei denn, Sie haben das Glück, dass Ihr Host-Betriebssystem Kernel-Oplocks unterstützt (siehe weiter oben).

kernel oplocks

Wenn eine Unix-Anwendung auf dem Samba-Host-System (die nicht Teil der Samba-Suite ist) versucht, eine Datei zum Schreiben zu öffnen, die Samba für einen Windows-Client mit einem Oplock belegt hat, wird sie damit wahrscheinlich Erfolg haben (je nach verwendetem Betriebssystem), und sowohl Samba als auch der Client werden es nie merken.

Einige Versionen von Unix bieten Unterstützung für Oplocks im Kernel, wodurch sie mit Sambas Oplocks klarkommen. In diesem Fall wird der Unix-Prozess suspendiert, der versucht, die Datei zu öffnen, während Samba den Client anweist, seine Kopie zu speichern. Anschließend erlaubt das Betriebssystem das Öffnen, um den Vorgang abzuschließen. Zum Zeitpunkt der Drucklegung dieses Buches boten nur SGI Irix und Linux diese Funktion.

level2 oplocks

Windows NT/2000/XP-Clients können Ihre Lese/Schreib-Oplocks in Schreibschutz-Oplocks umwandeln, wenn ein anderer Client die gleiche Datei öffnet. Die Folge sind deutliche Verbesserungen der Leistung für Dateien, die selten oder gar nicht geschrieben werden - das gilt vor allem für ausführbare Dateien -, da alle Clients dann einen lesbaren Cache für die Datei haben. Standardmäßig ist level2 oplocks auf yes gesetzt. Vermutlich müssen Sie diesen Vorgabewert auch nicht ändern.

Momentan unterstützt Samba keine Level-2-Oplocks zusammen mit Kernel-Oplocks und deaktiviert Level-2-Oplocks automatisch, wenn Kernel-Oplocks verwendet werden. (In künftigen Ausgaben kann sich das ändern, da von den Samba-Entwicklern eine bessere Unterstützung für Oplocks geplant ist.) Wenn Sie Samba auf einem Host-System ausführen, das Kernel-Oplocks unterstützt, müssen Sie kernel oplocks = no einstellen, um die Unterstützung für Level-2-Oplocks zu aktivieren.

Das Deaktivieren von Oplocks mit oplocks = no deaktiviert auch Level-2-Oplocks.

Samba erkennt die Unterstützung seines Unix-Hosts für Kernel-Oplocks automatisch und setzt auch den Wert der Option kernel oplocks automatisch. Sie müssen diese Option in Ihrer Samba-Konfigurationsdatei niemals selbst einstellen.

fake oplocks

Wenn diese Option auf yes gesetzt ist, gibt Samba vor, Oplocks zuzulassen, unterstützt sie aber nicht wirklich. Ist diese Option auf einer schreibgeschützten Freigabe (wie etwa einem freigegebenen CD-ROM-Laufwerk) aktiv, wird allen Clients mitgeteilt, dass diese Dateien für opportunistische Sperren zur Verfügung stehen. Sie werden nie vor gleichzeitigem Zugriff gewarnt. Als Ergebnis speichern Windows-Clients größere Mengen der Daten der Datei in ihrem Cache und bieten dadurch eine bessere Leistung.

Diese Option wurde hinzugefügt, bevor es die Samba-Unterstützung für opportunistische Sperren gab. Inzwischen wird es im Allgemeinen als günstiger angesehen, echte Oplocks zu benutzen. Aktivieren Sie fake oplocks niemals auf einer Lese/Schreib-Freigabe.

blocking locks

Samba unterstützt außerdem Blocking Locks, eine kleine Variante der Bereichssperren. Falls der gesperrte Dateibereich nicht verfügbar ist, gibt der Client einen Zeitraum an, den er zu warten bereit ist. Der Server legt die Sperranforderung daraufhin in einem Cache-Speicher ab, prüft regelmäßig, ob die Datei verfügbar ist, und benachrichtigt bei einem positiven Ergebnis den Client. Falls die Wartezeit abläuft, teilt Samba dem Client mit, dass die Anforderung fehlgeschlagen ist. Diese Vorgehensweise verhindert, dass der Client ständig nachfragt, ob er eine Sperre einrichten kann.

Sie können die Option in einer Freigabe folgendermaßen deaktivieren:

[accounting]
 
	blocking locks = no
 

Ist die Option auf yes gesetzt, werden auf der Datei Blocking Locks erzwungen. Bei einem Optionswert von no verhält sich Samba so, als wären auf der Datei die normalen Sperrmechanismen in Gebrauch. Der Vorgabewert ist yes.

veto oplock files

Sie können mit der Option veto oplock files eine Liste mit Dateinamen angeben, für die Samba niemals Oplocks zulassen soll. Dies legen Sie global oder auf Freigabeebene fest, zum Beispiel:

veto oplock files = /*.bat/*.htm/
 

Der Wert dieser Option besteht aus einer Reihe von Mustern. Jedes Muster muss mit einem Schrägstrich ( / ) beginnen, enden oder von anderen Mustern getrennt sein, auch wenn nur ein Muster vorhanden ist. Sternchen repräsentieren null oder mehr Zeichen, Fragezeichen dienen als Platzhalter für genau ein Zeichen.

Wir empfehlen Ihnen, Oplocks für Dateien zu deaktivieren, die von Unix aktualisiert werden oder von mehreren Prozessen gleichzeitig verwendet werden sollen.

lock directory

Diese Option (manchmal auch lock dir geschrieben) gibt das Verzeichnis an, in dem Samba Vermerke für SMB-Deny-Mode-Sperren ablegen soll. Samba speichert dort auch andere Dateien wie Suchlisten und die Datei für gemeinsam genutzten Speicher. Wenn WINS aktiviert ist, werden Sie im angegebenen Verzeichnis auch die WINS-Datenbank vorfinden. Die Voreinstellung für diese Option wird in der make-Datei gesetzt und lautet üblicherweise /usr/local/samba/var/locks. Sie können diesen Wert folgendermaßen überschreiben:

[global]
 
	lock directory = /usr/local/samba/locks
 

Normalerweise müssen Sie diese Option nicht außer Kraft setzen, es sei denn, Sie wollen die Sperrdateien an eine Stelle verschieben, die eher dafür vorgesehen ist, wie etwa /var/spool/locks.

Verbindungsskripten

Samba unterstützt einen Mechanismus namens Verbindungsskripten (Connection Scripts), durch den Befehle auf dem Server ausgeführt werden können, sobald ein Client sich an einer Freigabe anmeldet oder die Verbindung später wieder beendet. Mit Hilfe der Variablen der Konfigurationsdatei sowie einiger eigener Programmierarbeiten können Sie Verbindungsskripten herstellen, die eine ganze Reihe von Funktionen übernehmen. Als einfaches Beispiel sehen Sie hier eine schnell »zusammengeschusterte« Methode zur Echtzeitüberwachung von Verbindungen zu Freigaben auf einem Samba-Server. Zuerst wird der Wert des Parameters preexec folgendermaßen gesetzt:

[global]
 
	preexec = /bin/echo %u at %m connected to //%L/%S on %T >>/tmp/smblog
 

Damit werden Informationen über den Benutzer und die Verbindung in die Datei /tmp/smblog geschrieben, sobald sich ein Client an einer Freigabe anmeldet. Um zu beobachten, wie die Clients die Verbindung herstellen, führen Sie folgenden Befehl aus:

$ tail -f /tmp/smblog
 
jay at maya connected to //toltec/data on 2002/11/21 21:21:15
 
david at apache connected to //toltec/techs on 2002/11/21 21:21:57
 
sally at seminole connected to //toltec/payroll on 2002/11/21 21:22:16
 
martha at dine connected to //toltec/profiles on 2002/11/21 21:23:38
 
martha at dine connected to //toltec/netlogon on 2002/11/21 21:23:39
 
martha at dine connected to //toltec/martha on 2002/11/21 21:23:40
 
aaron at huastec connected to //toltec/netlogon on 2002/11/21 21:24:19
 
aaron at huastec connected to //toltec/aaron on 2002/11/21 21:24:20
 

Mit der Option -f überwacht der Befehl tail die Datei /tmp/smblog und ergänzt die Ausgabe, wenn neue Daten an die Datei angehängt werden. Jedes Mal, wenn eine neue Verbindung hergestellt wird, wird eine weitere Zeile ausgegeben, die die Ausgabe des Befehls preexec zeigt. Schauen Sie sich die Zeilen an, die von den Verbindungen der Benutzer martha und aaron stammen. Die Benutzerin martha hat sich an der Domäne von einem Windows NT-Client aus angemeldet, der auf die Freigabe [profiles] zugegriffen hat, um ihr Profil herunterzuladen, anschließend auf die Freigabe [netlogon], um das Anmeldeskript zu lesen, und dann auf ihr Home-Verzeichnis (da das Anmeldeskript den Befehl net use H: /home enthält), um ihr Home-Verzeichnis mit dem Laufwerkbuchstaben H zu verbinden. Die Verbindungen von aaron sind ähnlich, nur dass er von einem Windows 98-System kommt, das die Freigabe [profiles] nicht benutzt. (In Kapitel 4 finden Sie weitere Informationen über Domänen-Anmeldungen.)

Ein komplexerer Anwendungsfall für Verbindungsskripten ist die Überwachung des Inhalts der Home-Verzeichnisse der Benutzer und/oder der freigegebenen Verzeichnisse und die Überprüfung, ob alle lokalen administrativen Regeln eingehalten werden. Zu den überprüften Elementen könnten gehören:

Für diese Art von Aufgabe würde ein Shell-Skript oder ein anderes Programm geschrieben werden, das die Überprüfungen durchführt und die entsprechenden Aktionen auslöst, beispielsweise das Löschen störender Dateien. Der Parameter root preexec würde eingesetzt werden, um den Befehl als root-Benutzer auszuführen, wobei die Argumente über Variablen aus der Konfigurationsdatei übergeben werden. Ein Beispiel:

[homes]
 
	root preexec = admin_checks %S
 
	root preexec close = yes
 

In diesem Beispiel wird ein speziell geschriebenes administratives Prüfprogramm (admin_checks) verwendet, um die Home-Verzeichnisse der Benutzer auf dem Samba-Server zu überwachen. Die Variable %S übergibt den Namen des Home-Verzeichnisses an das Skript. Der Parameter root preexec close wurde auf yes gesetzt. Wenn also admin_checks eine ernsthafte Verletzung der lokalen Regeln entdeckt, kann es sich mit einem Exit-Status ungleich null beenden, und der Client wird davon abgehalten, eine Verbindung aufzubauen.

Optionen für Verbindungsskripten

Tabelle 8-7 stellt einige der Konfigurationsoptionen für Verbindungsskripten vor.

Tabelle 8-7
Optionen für Verbindungsskripten 
Option
Parameter
Funktion
Vorgabewert
Geltungsbereich
root preexec
String (Unix-Befehl)
Legt einen Unix-Befehl fest, der als root ausgeführt wird, bevor eine Verbindung zur Freigabe hergestellt wird.
keiner
Freigabe
root preexec close
Boolescher Wert
Wenn yes, sorgt ein Exit-Status ungleich null des Befehls root preexec für einen Verbindungsabbau.
no
Freigabe
preexec (exec)
String (Unix-Befehl)
Legt einen Unix-Befehl fest, der als Benutzer ausgeführt wird, bevor eine Verbindung zur Freigabe hergestellt wird.
keiner
Freigabe
preexec close
Boolescher Wert
Wenn yes, sorgt ein Exit-Status ungleich null des Befehls preexec für einen Verbindungsabbau.
no
Freigabe
postexec
String (Unix-Befehl)
Legt einen Unix-Befehl fest, der als Benutzer ausgeführt wird, nachdem eine Verbindung zur Freigabe abgebrochen wurde.
keiner
Freigabe
root postexec
String (Unix-Befehl)
Legt einen Unix-Befehl fest, der als root ausgeführt wird, nachdem eine Verbindung zur Freigabe abgebrochen wurde.
keiner
Freigabe

root preexec

Diese Option gibt als ihren Wert einen Unix-Befehl an, der als root-Benutzer ausgeführt wird, bevor der Verbindungsaufbau zu einer Freigabe vollständig erfolgt ist. Sie sollten diese Option speziell für die Ausführung von Aktionen nutzen, die root-Rechte erfordern.

Um die Sicherheit zu gewährleisten, dürfen Benutzer niemals in der Lage sein, das Ziel des Befehls root preexec zu verändern. Darüber hinaus werden alle Informationen, die der Befehl an die Standardausgabe sendet, abgewiesen, es sei denn, Sie leiten sie ausdrücklich dorthin. Falls Sie vorhaben, ein preexec- oder postexec-Skript einzusetzen, müssen Sie sicherstellen, dass es richtig funktioniert, bevor Sie es durch Samba starten lassen.

root preexec close

Manchmal soll die Verbindung zur Freigabe abgebrochen werden, wenn das root preexec-Skript fehlschlägt. Der Client erhält also statt einer Verbindung eine Fehlermeldung. Falls Sie beispielsweise root preexec verwenden, um eine CD-ROM oder ein Dateisystem zu mounten, wäre es sinnlos, eine Verbindung zum Client herzustellen, wenn das Mounten nicht funktioniert hat. Wenn Sie root preexec close = yes angeben, gibt es keine Verbindung zur Freigabe, falls das root preexec-Skript einen Exit-Status ungleich null liefert.

preexec

Diese Option, manchmal auch nur als exec bezeichnet, definiert einen einfachen, nichtprivilegierten Befehl, der von Samba als der Benutzer ausgeführt wird, den die Variable %u bezeichnet. Mit dieser Option können Sie beispielsweise eine Protokollierung durchführen:

[homes]
 
	preexec = echo "%u connected from %m (%I)\" >>/tmp/.log 
 

Sie müssen die Standardausgabe des Befehls umleiten, wenn Sie ihn benutzen wollen; ansonsten wird er abgewiesen. Diese Warnung gilt auch für die Standardfehlerausgabe des Befehls. Falls Sie ein preexec-Skript benutzen wollen, müssen Sie sicherstellen, dass es richtig funktioniert, bevor Sie es durch Samba ausführen lassen.

preexec close

Diese Option ähnelt root preexec close, nur eben im Zusammenhang mit der Option preexec. Wenn Sie preexec close = yes setzen, verursacht ein preexec-Skript, das einen Exit-Status ungleich null zurückliefert, den sofortigen Abbau der Verbindung zur Freigabe.

postexec

Sobald der Benutzer sich von der Freigabe abmeldet, wird der mit postexec angegebene Befehl als der Benutzer auf dem Samba-Server ausgeführt, um notwendige Aufräumarbeiten zu erledigen. Diese Option ist im Prinzip identisch mit der Option preexec. Denken Sie auch hier daran, dass der Befehl unter der Benutzerkennung durchgeführt wird, die durch %u repräsentiert wird, und dass alle Informationen, die auf die Standardausgabe gehen, ignoriert werden.

root postexec

Nach der Option postexec wird der Befehl root postexec ausgeführt, falls einer festgelegt wurde. Auch diese Option legt als ihren Wert einen Unix-Befehl fest, der als root-Benutzer ausgeführt wird, bevor die Verbindung zu einer Freigabe beendet wird. Sie sollten diese Option speziell für die Ausführung von Aktionen nutzen, die root-Rechte erfordern.

Microsoft Distributed Filesystems

In einem großen Netzwerk, in dem viele freigegebene Ordner über viele Server verstreut sind, kann es für die Benutzer schwierig sein, die gewünschten Ressourcen zu finden. Das Durchsuchen der Netzwerkumgebung wird zu einer Qual anstatt zu einer Zeit sparenden Bequemlichkeit. Um dieses Problem zu entschärfen, hat Microsoft das Filesharing um das so genannte Distributed filesystem (Dfs; Verteiltes Dateisystem) erweitert. Mittels Dfs ist es möglich, Dateifreigaben im Netzwerk so zu organisieren, dass sie für die Benutzer wie ein einziger Verzeichnisbaum auf einem einzigen Server aussehen, unabhängig davon, auf welchen Servern im Netzwerk tatsächlich die Ressourcen enthalten sind. Benutzer müssen nicht das ganze Netzwerk durchsuchen, sondern können sich direkt zur Dfs-Freigabe begeben und ihre Daten dort viel leichter auffinden.

Dfs kann auch Administratoren helfen, weil es eine Art von Zwischenstation zwischen dem Namen eines freigegebenen Ordners und seinem tatsächlichen Standort bietet. Die Dfs-Freigabe enthält Verweise auf Ressourcen im Netzwerk. Wird auf eine Ressource zugegriffen, leitet der Dfs-Server den Client an den eigentlichen Server der Ressource weiter. Werden Ressourcen auf einen anderen Computer verschoben, kann der Verweis auf die Ressource in der Dfs-Freigabe in einem Schritt auf den neuen Ablageort umgeleitet werden. Die Änderung erfolgt für die Benutzer völlig transparent.

Bis zu einem bestimmten Maß kann Dfs auch die Leistung für schreibgeschützte Freigaben verbessern, weil es einen Lastausgleich bietet. Es ist möglich, eine Dfs-Referenz so einzustellen, dass sie auf identische Freigaben auf zwei oder mehr Servern verweist. Der Dfs-Server teilt die Anfragen - und entsprechend auch die Client-Last - dann zwischen den Servern auf. Dies funktioniert allerdings nur für statische, schreibgeschützte Daten einigermaßen gut, da es in Dfs keine Vorrichtung zur Synchronisierung zwischen den Servern gibt, wenn auf einem von ihnen Änderungen vorgenommen werden.

Windows Dfs-Clients

Moderne Versionen von Windows bieten Client-seitige Unterstützung für Dfs. Es ist keine weitere Konfiguration erforderlich. Für ältere Versionen ist die Unterstützung allerdings etwas eingeschränkt. Windows for Workgroups kann überhaupt nicht als Dfs-Client arbeiten. Windows NT 4.0 muss wenigstens auf Service Pack 3 aufgerüstet werden, um als Dfs-Client zu agieren, außerdem muss der Dfs Client installiert werden. Spätere Service Packs (wie etwa Service Pack 6) enthalten den Dfs Client. Bei Windows 95 muss ebenfalls die Dfs Client-Software installiert werden, damit es als Dfs-Client arbeiten kann. Ohne das Programm Dfs Client wird beim Doppelklicken auf einen entfernten Ordner in einer Dfs-Freigabe ein leerer Ordner angezeigt, und es gibt keine Fehlermeldung.


Um das Programm Dfs Client für Windows 95 oder Windows NT benutzen zu können, müssen Sie es zuerst herunterladen und installieren. Auf der Webseite http://microsoft.com/ntserver/nts/downloads/winfeatures/NTSDistrFile/default.asp finden Sie einen Link zum Herunterladen des Installationsprogramms sowie Anweisungen zur Installation von Dfs Client.

Samba für Dfs konfigurieren

Damit Samba 2.2 als Dfs-Server arbeiten kann, muss es mit der Konfigurationsoption --with-msdfs kompiliert werden. (In Kapitel 2 finden Sie Anweisungen zum Konfigurieren und Kompilieren von Samba.) Samba 3.0 enthält standardmäßig Dfs-Unterstützung und muss nicht mit --with-msdfs kompiliert werden.

Sobald ein Dfs-fähiger Samba-Server läuft, sind es nur noch zwei Schritte bis zum Anbieten einer Dfs-Freigabe. Zuerst richten Sie ein Dfs-root-Verzeichnis auf dem Server ein, und anschließend ändern Sie die Konfigurationsdatei smb.conf so, dass die Freigabe aktiviert wird.

Das Dfs-root-Verzeichnis einrichten

Legen Sie zunächst ein Verzeichnis an, das als Dfs-root fungiert:

# mkdir /usr/local/samba/dfs
 

Das kann jedes beliebige Verzeichnis sein, es ist nur wichtig, dass es root gehört und die richtigen Berechtigungen besitzt:

# chown root:root /usr/local/samba/dfs
 
# chmod 755 /usr/local/samba/dfs
 

Der Dfs-Verzeichnisbaum darf Unterverzeichnisse und Dateien haben, genau wie jedes andere freigegebene Verzeichnis. Diese Elemente funktionieren genau so, wie sie es in jeder anderen Freigabe tun würden, das heißt, sie erlauben Clients den Zugriff auf Verzeichnisse und Dateien auf dem Samba-Server. Der eigentliche Gedanke hinter Dfs besteht aber darin, die Freigaben auf anderen Servern zu sammeln, indem Referenzen darauf im Dfs-Baum angelegt werden. Die Art und Weise, wie dies in Samba implementiert ist, beruht auf dem cleveren Einsatz symbolischer Links, die sich im Dfs-root-Verzeichnis oder in einem Unterverzeichnis des Dfs-Baums befinden können.

Sie sind vermutlich mit dem Einsatz symbolischer Links zum Anlegen von Referenzen auf Dateien vertraut, die im gleichen System existieren und möglicherweise die Grenzen des lokalen Dateisystems überschreiten (was normale Unix-Links nicht können). Aber vermutlich haben Sie bisher nicht gewusst, dass symbolische Links eine viel allgemeinere Funktionalität aufweisen. Wir können zwar ihren Inhalt im Gegensatz zu einer Text- oder Binärdatei nicht direkt anzeigen, aber ein symbolischer Link »enthält« einen ASCII-Text-String, der angibt, worauf der Link verweist. Schauen Sie sich beispielsweise das Listing für diese symbolischen Links an:

$ ls -l wrdlnk alnk
 
lrwxrwxrwx    1 jay      jay            15 Mar 14 06:50 wrdlnk -> /usr/dict/words
 
lrwxrwxrwx    1 jay      jay             9 Mar 14 06:53 alnk -> dreamtime
 

Wie Sie aus der Größe des Links wrdlnk (15 Bytes) schließen können, ist der String /usr/dict/words darin kodiert. Der Link alnk (9 Bytes) ist noch kleiner und entspricht dem kürzeren Namen von dreamtime.

Jetzt wollen Sie für eine SMB-Freigabe einen Link in Ihrer Dfs-root anlegen:

# cd /usr/local/samba/dfs
 
# ln -s 'msdfs:maya\e' maya-e
 
# ls -l maya-e
 
lrwxrwxrwx    1 root     root           12 Mar 13 17:34 maya-e -> msdfs:maya\e
 

Dieser Link könnte in einem Verzeichnis-Listing als »broken« Link angezeigt werden, da er auf etwas verweist, das keine Datei im lokalen System ist. Der Befehl file würde zum Beispiel Folgendes ausgeben:

$ file maya-e
 
maya-e: broken symbolic link to msdfs:maya\e
 

maya-e ist jedoch eine gültige Referenz auf die Freigabe \\maya\e, wenn die Dfs-Unterstützung von Samba zum Einsatz kommt. Wenn Samba diese Datei entdeckt, sieht es das einleitende msdfs: und interpretiert den Rest als den Namen einer entfernten Freigabe. Der Client wird dann an die entfernte Freigabe weitergeleitet.

Beim Anlegen von Links im Dfs-root-Verzeichnis verwenden Sie einfach das gleiche Format, das im Allgemeinen msdfs:server\freigabe lautet. Beachten Sie, dass dies ähnlich einem UNC ist, der an den String msdfs: angehängt wird. Allerdings werden in diesem Fall die beiden Backslashes, die dem Namen des Servers vorangestellt sind, weggelassen.


Die Namen für die symbolischen Links in Dfs-Freigaben müssen in Kleinbuchstaben geschrieben werden.

Zusätzlich zu den normalen Netzwerkfreigaben können Sie symbolische Links dieser Art verwenden, um auf Dfs-Freigaben auf anderen Dfs-Servern zu verweisen. Das Referenzieren von Druckerfreigaben dagegen funktioniert nicht. Dfs eignet sich nur zum Freigeben von Dateien.

Lastausgleich

Um eine Dfs-Freigabe zum Lastausgleich einzurichten, legen Sie einen solchen symbolischen Link an:

# ln -s 'msdfs:toltec\data,msdfs:mixtec\data' lb-data
 

Das heißt, verwenden Sie als Referenz einfach eine Liste mit Freigaben, die durch Kommata getrennt sind. Denken Sie immer daran, dass es an Ihnen liegt, dafür zu sorgen, dass die freigegebenen Ordner identisch bleiben. Stellen Sie die Berechtigungen auf den Servern so ein, dass die Freigaben von den Benutzern nur gelesen werden können.

Zuletzt müssen Sie noch in der Datei smb.conf die Dfs-root-Freigabe definieren und Dfs-Unterstützung hinzufügen. Die Dfs-root wird in Form einer Freigabe-Definition angelegt:

[dfs]
 
	path = /usr/local/samba/dfs
 
	msdfs root = yes
 

Sie können für die Freigabe einen beliebigen Namen verwenden. Der Pfad verweist auf das gerade von Ihnen eingerichtete Dfs-root-Verzeichnis. Der Parameter msdfs root = yes teilt Samba mit, dass es sich bei dieser Freigabe um eine Dfs-root handelt.

Um die Unterstützung für Dfs im Server zu aktivieren, müssen Sie eine Zeile in den Abschnitt [global] einfügen:

[global]
 
	host msdfs = yes
 

Starten Sie die Samba-Daemons neu - oder warten Sie eine Minute, bis diese die Konfigurationsdatei neu eingelesen haben -, und Sie sehen die neue Freigabe von den Windows-Clients aus. Falls es Probleme bereitet, auf eine der entfernten Freigaben in der Dfs-Freigabe zuzugreifen, prüfen Sie noch einmal Ihre symbolischen Links, um sicherzugehen, dass diese richtig angelegt wurden.


Falls Sie zuvor bereits einmal eine Freigabe hatten, die den gleichen Namen wie Ihre Dfs-Freigabe trug, müssen Sie eventuell die Windows-Clients neu starten, bevor diese auf die Freigabe als Dfs-Freigabe zugreifen können.

Mit NIS arbeiten

In Netzwerken, in denen NIS und NFS verwendet werden, ist es üblich, dass die Home-Verzeichnisse der Benutzer durch NFS über das Netzwerk gemountet werden. Wenn ein Samba-Server, der zum Authentifizieren der Benutzeranmeldungen eingesetzt wird, auf einem System mit NFS-gemounteten Home-Verzeichnissen läuft, die mit einer [homes]-Freigabe freigegeben werden, kann der zusätzliche Overhead eine schlechte Leistung zur Folge haben - und zwar ungefähr 30 Prozent der normalen Samba-Geschwindigkeit.

Samba besitzt die Fähigkeit, mit NIS und NIS+ zu arbeiten, um den Server zu ermitteln, auf dem die Home-Verzeichnisse sich tatsächlich befinden, so dass sie direkt von diesem Server aus freigegeben werden können. Damit dies funktioniert, muss auf dem Server, auf dem sich die Home-Verzeichnisse befinden, ebenfalls Samba laufen und eine eigene [homes]-Freigabe vorhanden sein.

NIS-Konfigurationsoptionen

Tabelle 8-8 stellt die NIS-Konfigurationsoptionen zum Einrichten von Benutzern vor.

Tabelle 8-8
NIS-Optionen
Option
Parameter
Funktion
Vorgabewert
Geltungsbereich
nis homedir
Boolescher Wert
Wenn yes, wird NIS an Stelle von /etc/passwd verwendet, um den Pfad des Home-Verzeichnisses eines Benutzers zu suchen.
no
global
homedir map
String (NIS-Map-Name)
Legt die NIS-Map fest, in der nach dem Home-Verzeichnis eines Benutzers gesucht werden soll.
keiner
global

nis homedir, homedir map

Die Optionen nis homedir und homedir map sind für Samba-Server in Netzwerken gedacht, in denen die Unix-Home-Verzeichnisse über NFS, den Automounter und NIS bereitgestellt werden.

Die Option nis homedir zeigt an, dass der Home-Verzeichnis-Server für die Benutzer im NIS nachgesehen werden muss. Die Option homedir map teilt Samba mit, in welcher NIS-Map der Server gesucht werden soll, auf dem das Home-Verzeichnis des Benutzers liegt. Der Server muss ein Samba-Server sein, damit der Client eine SMB-Verbindung dorthin aufbauen kann, und auf den anderen Samba-Servern muss NIS installiert sein, damit sie einen Lookup ausführen können.

Falls beispielsweise der Benutzer joe nach einer Freigabe namens [joe] fragt und die Option nis homedir auf yes gesetzt ist, schaut Samba in die Datei, die durch homedir map für ein Home-Verzeichnis für joe angegeben ist. Findet es eines, liefert Samba den entsprechenden Systemnamen an den Client zurück. Der Client versucht dann, eine Verbindung zu dieser Maschine herzustellen und die Freigabe von dort zu beziehen. Das Aktivieren von NIS-Lookups sieht in etwa so aus:

[globals]
 
	nis homedir = yes
 
	homedir map = amd.map
 
1Das Optionsfeld für System ist vermutlich für Ihre Datei grau dargestellt. Keine Sorge, Sie sehen trotzdem, wenn dieses Bit aktiviert ist und wenn nicht.

TOC PREV NEXT INDEX

Copyright © 2003 by O'Reilly Verlag GmbH & Co.KG