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 12

Fehlersuche und Problembehandlung

Samba ist außergewöhnlich robust. Wenn Sie erst einmal alles nach Wunsch eingerichtet haben, werden Sie vermutlich sogar vergessen, dass es überhaupt läuft. Probleme treten normalerweise während der Installation auf oder wenn Sie versuchen, den Server neu zu konfigurieren. Glücklicherweise stehen eine Vielzahl von Ressourcen zur Verfügung, um diese Probleme zu diagnostizieren. Wir können zwar an dieser Stelle nicht in allen Einzelheiten die Lösung für jedes Problem schildern, das bei Ihnen auftreten könnte, Sie sollten aber mit Hilfe der  Ratschläge in diesem Kapitel eine gute Starthilfe erhalten.

Der erste Abschnitt dieses Kapitels führt den Inhalt Ihres Werkzeugkastens auf: Er enthält die Arbeitsmittel, mit denen Sie Fehlern auf die Schliche kommen können. Der zweite Abschnitt erklärt ausführlich, wie Sie diese Werkzeuge einsetzen können, und im letzten Abschnitt machen wir Sie mit zusätzlichen Ressourcen zum Aufspüren besonders hartnäckiger Probleme bekannt.

Der Werkzeugkasten

Unix erscheint manchmal als Sammlung von Anwendungen und Werkzeugen. Es gibt Werkzeuge, um Fehler in Werkzeugen zu suchen. Und selbstverständlich gibt es immer mehrere Möglichkeiten, eine Aufgabe zu erledigen. Wenn Sie versuchen, ein Problem mit Samba zu beheben, sollte eine wohlüberlegte Vorgehensweise folgende Punkte und Werkzeuge berücksichtigen:

In den folgenden Abschnitten wollen wir die einzelnen Punkte genauer betrachten.

Samba-Protokolle

Ihr erster Anknüpfungspunkt sollten grundsätzlich die Protokolldateien sein. Die Samba-Protokolle helfen bei der Lösung der meisten Probleme, auf die Samba-Administratoren (sowohl im Anfänger- als auch im Fortgeschrittenen-Stadium) wahrscheinlich treffen. Samba ist in Bezug auf die Protokollierung sehr flexibel. Sie können den Protokollierungsgrad exakt an Ihre Bedürfnisse anpassen. Mit Hilfe von Variablen in der Samba-Konfigurationsdatei können Sie Protokolle für bestimmte Clients, Freigaben, Benutzer oder Kombinationen daraus erstellen.

Standardmäßig legt Samba Protokolle in den Dateien /usr/local/samba/var/smbd.log und /usr/local/samba/var/nmbd.log an. Sie können beim Start der Samba-Daemons mit der Option -l auf der Kommandozeile ein Protokollverzeichnis festlegen, zum Beispiel: 

# smbd -l /var/log/samba
 
# nmbd -l /var/log/samba

Alternativ dazu haben Sie die Möglichkeit, den Ort und den Namen mit der Konfigurationsoption log file in smb.conf einzustellen. Diese Option akzeptiert alle Variablen, so dass Sie den Server leicht dazu veranlassen können, ein eigenes Protokoll für jedes Client-System anzulegen, das sich anmeldet. Dazu geben Sie Folgendes an: 

[global]
 
	log file = %m.log

Sie können aber auch dafür sorgen, dass der Server für jeden angebotenen Dienst (also jede Freigabe) ein Protokoll aufzeichnet. Das ist vor allem dann sinnvoll, wenn Sie den Verdacht hegen, dass eine bestimmte Freigabe Ärger verursacht. Dazu setzen Sie die Variable %S ein: 

[global]
 
	log file = %S.log
Protokollierungsstufen

Sie können den Protokollierungsgrad, den Samba verwendet, in der Datei smb.conf festlegen. Benutzen Sie dazu eine der beiden gleichbedeutenden Optionen log level oder debug level. Die Protokollierungsstufe ist ein ganzzahliger Wert zwischen 0 und 10. Bei Stufe 0 wird keine Protokollierung durchgeführt. Höhere Werte haben ausführlichere Protokolle zur Folge. Lassen Sie uns beispielsweise annehmen, dass wir einen Windows-Client benutzen, um ein Verzeichnis auf einem Samba-Server zu durchsuchen. Um nur wenige Informationen zu erhalten, benutzen Sie log level = 1. Damit wird Samba angewiesen, nur oberflächliche Informationen zu zeigen, in diesem Fall lediglich den Verbindungsaufbau: 

05/25/02 22:02:11 server (192.168.236.86) connect to service public as user pcguest (uid=503,gid=100) (pid 
3377)

Höhere Protokollierungsstufen ergeben ausführlichere Angaben. Normalerweise werden Sie nicht über Stufe 3 hinausgehen, die für die meisten Samba-Administratoren mehr als ausreichende Informationen produziert. Höhere Stufen sind für Entwickler gedacht und geben eine Unmenge an Informationen aus, die für Normalsterbliche kryptisch sind.

Hier sind Beispielausgaben der Stufen 2 und 3 desselben Vorgangs. Stören Sie sich nicht daran, wenn Sie die Komplexität einer SMB-Verbindung nicht verstehen. Es geht uns an dieser Stelle ausschließlich darum, die Unterschiede der beiden Protokollierungsgrade zu verdeutlichen: 

 /* Level 2 */
 
Got SIGHUP
 
Processing section "[homes]"
 
Processing section "[public]"
 
Processing section "[temp]"
 
Allowed connection from 192.168.236.86 (192.168.236.86) to IPC$
 
Allowed connection from 192.168.236.86 (192.168.236.86) to IPC/
 

 

 
/* Level 3 */
 
05/25/02 22:15:09 Transaction 63 of length 67
 
switch message SMBtconX (pid 3377)
 
Allowed connection from 192.168.236.86 (192.168.236.86) to IPC$
 
ACCEPTED: guest account and guest ok
 
found free connection number 105
 
Connect path is /tmp
 
chdir to /tmp
 
chdir to /
 
05/25/02 22:15:09 server (192.168.236.86) connect to service IPC$ as user pcguest (uid=503,gid=100) (pid 
3377)
 
05/25/02 22:15:09 tconX service=ipc$ user=pcguest cnum=105
 
05/25/02 22:15:09 Transaction 64 of length 99
 
switch message SMBtrans (pid 3377)
 
chdir to /tmp
 
trans <\PIPE\LANMAN> data=0 params=19 setup=0
 
Got API command 0 of form <WrLeh> <B13BWz> (tdscnt=0,tpscnt=19,mdrcnt=4096,mprcnt=8)
 
Doing RNetShareEnum
 
RNetShareEnum gave 4 entries of 4 (1 4096 126 4096)
 
05/25/02 22:15:11 Transaction 65 of length 99
 
switch message SMBtrans (pid 3377)
 
chdir to /
 
chdir to /tmp
 
trans <\PIPE\LANMAN> data=0 params=19 setup=0
 
Got API command 0 of form <WrLeh> <B13BWz> (tdscnt=0,tpscnt=19,mdrcnt=4096,mprcnt=8)
 
Doing RNetShareEnum
 
RNetShareEnum gave 4 entries of 4 (1 4096 126 4096)
 
05/25/02 22:15:11 Transaction 66 of length 95
 
switch message SMBtrans2 (pid 3377)
 
chdir to /
 
chdir to /pcdisk/public
 
call_trans2findfirst: dirtype = 0, maxentries = 6, close_after_first=0, close_if_end = 0 requires_resume_key = 
0 level = 260, max_data_bytes = 2432
 
unix_clean_name [./DESKTOP.INI]
 
unix_clean_name [desktop.ini]
 
unix_clean_name [./]
 
creating new dirptr 1 for path ./, expect_close = 1
 
05/25/02 22:15:11 Transaction 67 of length 53
 
switch message SMBgetatr (pid 3377)
 
chdir to /
 

 
[... gelöscht ...]

Wir haben uns den Rest der Ausgabe nach dem ersten Paket gespart, weil sie mehrere Seiten in Anspruch genommen hätte. Seien Sie sich im Klaren, dass Protokollierungsstufen oberhalb von 3 schnell Ihre Festplatten mit Einzelheiten über interne Samba-Aktionen füllen. Die Stufe 3 ist äußerst nützlich, um die Vorgänge des Servers genau zu verfolgen, und in der Regel können Sie Fehler finden, wenn Sie die Protokolldateien genau durchgehen.

Eine hohe Protokollierungsstufe (ab 3) verlangsamt den Samba-Server deutlich. Denken Sie daran, dass Einträge in die Protokolldatei bewirken, dass Daten auf die Festplatte geschrieben werden (ein von Natur aus langsamer Vorgang) und Protokollierungsstufen höher als 2 eine große Datenmenge produzieren. Schalten Sie Stufe 3 nur dann ein, wenn Sie wirklich ein Problem mit dem Samba-Server beheben wollen.

Die Protokollierung aktivieren und deaktivieren

Um die Protokollierung ein- oder auszuschalten, legen Sie die gewünschte Stufe im Abschnitt [global] der Datei smb.conf fest. Dann können Sie entweder Samba neu starten oder den aktuellen Daemon dazu bringen, die Konfigurationsdatei erneut zu verarbeiten, indem Sie ihm ein Hangup-(HUP-)Signal schicken. Oder Sie senden dem smbd-Prozess ein SIGUSR1-Signal, um seine Protokollierungsstufe während des Betriebs zu erhöhen: 

# kill -SIGUSR1 1234

bzw. ein SIGUSR2-Signal, um sie zu verringern: 

# kill -SIGUSR2 1234
Aktionen einzelner Client-Systeme oder Benutzer aufzeichnen

Ein wirkungsvoller Weg, Probleme einzelner Clients oder Benutzer zu diagnostizieren, ohne andere Clients und Benutzer zu stören, besteht darin, für einzelne Systeme unterschiedliche Protokollierungsstufen im Abschnitt [global] der smb.conf-Datei zu verwenden. Dies erreichen Sie über eine Strategie, die wir Ihnen bereits vorgestellt haben: 

[global]
 
	log level = 0
 
	log file = /usr/local/samba/var/log.%m
 
	include = /usr/local/samba/lib/smb.conf.%m

Diese Optionen weisen Samba an, für jeden Client jeweils eine eigene Konfigurations- und Protokolldatei zu verwenden. Nun müssen Sie nur für die betreffenden Clients eigene smb.conf-Dateien anlegen, die den Eintrag log level = 3 enthalten (die anderen Clients arbeiten mit der Protokollierungsstufe 0), und die Protokolldatei auswerten, um das Problem zu orten.

Wenn ein Problem nur bei einem bestimmten Benutzer auftritt - und diesen von System zu System begleitet -, können Sie die Protokollierung auf diesen Benutzer beschränken, indem Sie Folgendes in die smb.conf-Datei aufnehmen: 

[global]
 
	log level = 0
 
	log file = /usr/local/samba/var/log.%u
 
	include = /usr/local/samba/lib/smb.conf.%u

Anschließend können Sie eine eigene smb.conf-Datei für jeden Benutzer anlegen, den Sie überwachen wollen (z.B. /usr/local/samba/lib/smb.conf.tim). Die Dateien enthalten die Konfigurationsoption log level = 3 und zeichnen nur für die angegebenen Benutzer ein ausführlicheres Protokoll auf.

Samba-Testprogramme

Das Verzeichnis /docs/textdocs der Samba-Distribution (beginnend mit der Datei DIAGNOSIS.txt) beschreibt rigorose Prüfungen für die wichtigen Teile von Samba. Der Fehlerbaum in diesem Kapitel ist eine ausführlichere Variante der grundlegenden Tests, die das Samba-Team empfiehlt, behandelt aber - wie DIAGNOSIS.txt - nur die Installation und die Neukonfiguration. Die anderen Dateien im Unterverzeichnis /docs behandeln spezielle Probleme und erklären, wie Sie Probleme beheben, auf die wir in unserem Buch nicht eingehen. Wenn der Fehlerbaum Ihnen keine ausreichenden Informationen bietet, sehen Sie sich die Datei DIAGNOSIS.txt und verwandte Dateien an.

Unix-Werkzeuge

Manchmal ist es sinnvoll, ein von Samba unabhängiges Werkzeug zu verwenden, um Vorgänge auf dem Server zu beobachten. Drei Diagnosewerkzeuge können besonders nützlich sein, um Schwierigkeiten mit Samba zu beheben: trace, tcpdump und Ethereal.

trace verwenden

Den Befehl trace gibt es mit diversen Namen, abhängig vom Betriebssystem, das Sie verwenden. Unter Linux heißt er strace, bei Solaris truss, SGI besitzt padc und par und HP-UX hat trace oder tusc. Alle diese Programme besitzen im Wesentlichen die gleiche Funktion, nämlich das Aufzeigen von Betriebssystem-Funktionsaufrufen. Damit können Sie die Ausführung eines beliebigen Programms verfolgen, beispielsweise den Samba-Server, und genau bestimmen, welcher Aufruf das Problem verursacht.

Ein Problem, das Sie mit trace finden können, sind falsche Versionen dynamisch verbundener Bibliotheken. Dieser Fehler kann auftauchen, wenn Sie Samba als ausführbare, binäre Dateien heruntergeladen haben. Normalerweise sehen Sie bei einem Problem den fehlerverursachenden Aufruf am Ende der Ausgabe von trace, bevor der Samba-Server abstürzt.

Im Folgenden finden Sie eine Beispielausgabe des Befehls strace unter dem Betriebssystem Linux. Dabei handelt es sich um einen kleinen Ausschnitt einer größeren Ausgabe während des Öffnens eines Verzeichnisses auf dem Samba-Server. Jede Zeile entspricht einem Systemaufruf, beginnend mit dem Namen des Aufrufs, gefolgt von seinen Parametern und dem Rückgabewert. Wenn dabei ein Fehler auftritt, enthält die Ausgabe den Fehlerwert (z.B. ENOENT) und seine Erklärung. Sie können die Parametertypen und die möglichen Fehler in der entsprechenden trace-Manpage für das von Ihnen verwendete Betriebssystem nachsehen. 

chdir("/pcdisk/public")                 = 0
 
stat("mini/desktop.ini", 0xbffff7ec)    = -1 ENOENT (No such file or directory)
 
stat("mini", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
 
stat("mini/desktop.ini", 0xbffff7ec)    = -1 ENOENT (No such file or directory)
 
open("mini", O_RDONLY)                  = 5
 
fcntl(5, F_SETFD, FD_CLOEXEC)           = 0
 
fstat(5, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
 
lseek(5, 0, SEEK_CUR)                   = 0
 
SYS_141(0x5, 0xbfffdbbc, 0xedc, 0xbfffdbbc, 0x80ba708) = 196
 
lseek(5, 0, SEEK_CUR)                   = 1024
 
SYS_141(0x5, 0xbfffdbbc, 0xedc, 0xbfffdbbc, 0x80ba708) = 0
 
close(5)                                = 0
 
stat("mini/desktop.ini", 0xbffff86c)    = -1 ENOENT (No such file or directory)
 
write(3, "\0\0\0#\377SMB\10\1\0\2\0\200\1\0"..., 39) = 39
 
SYS_142(0xff, 0xbffffc3c, 0, 0, 0xbffffc08) = 1
 
read(3, "\0\0\0?", 4)                   = 4
 
read(3, "\377SMBu\0\0\0\0\0\0\0\0\0\0\0\0"..., 63) = 63
 
time(NULL)                              = 896143871

Dieses Beispiel zeigt mehrere erfolglose stat()-Aufrufe auf Grund fehlender Dateien, die erwartet wurden. Sie müssen kein Experte sein, um zu sehen, dass die Datei desktop.ini im angegebenen Verzeichnis nicht vorhanden ist. Sie können mit trace viele offensichtliche, wiederholt auftretende Probleme identifizieren. Häufig müssen Sie sich lediglich die letzte Nachricht vor einem Samba-Absturz ansehen.

tcpdump verwenden

Mit dem Programm tcpdump, das von Andrew Tridgell erweitert wurde, können Sie SMB-Netzwerkverkehr in Echtzeit überwachen. Das Programm beherrscht mehrere Ausgabeformate, und Sie können die Ausgabe filtern, um nur einen bestimmten Teil des Netzwerkverkehrs zu sehen. Das Programm zeigt Ihnen die gesamte Kommunikation zwischen Clients und dem Server, einschließlich der SMB- und NMB-Broadcast-Nachrichten. Die Möglichkeiten zur Fehlersuche beschränken sich auf die OSI-Netzwerkschicht, aber Sie können die Ausgabe der Software verwenden, um eine allgemeine Vorstellung davon zu bekommen, was Server und Clients wollen.

Im Folgenden finden Sie eine Beispielausgabe von tcpdump. Dabei hat ein Client den Inhalt eines Verzeichnisses angefordert, woraufhin der Server die Verzeichnisnamen homes, public, IPC$ und temp zurückgeliefert hat (wir haben am rechten Rand einige Erklärungen hinzugefügt): 

$ tcpdump -v -s 255 -i eth0 port not telnet
 
SMB PACKET: SMBtrans (REQUEST)	                 Anforderungspaket
 
SMB Command   =  0x25                         Die Anforderung war ls oder dir
 

 
[000] 01 00 00 10                             ....
 

 

 
>>> NBT Packet                                Äußerer Rahmen eines SMB-Pakets
 
NBT Session Packet
 
Flags=0x0
 
Length=226
 
[lines skipped]
 
                         
 
SMB PACKET: SMBtrans (REPLY)                  Anfang einer Antwort auf die Anforderung 
 
SMB Command   =  0x25			                         Der Befehl war ls oder dir
 
Error class   =  0x0			 
 
Error code    =  0                            Keine Fehler
 
Flags1        =  0x80
 
Flags2        =  0x1
 
Tree ID       =  105
 
Proc ID       =  6075
 
UID           =  100
 
MID           =  30337
 
Word Count    =  10
 
TotParamCnt=8 
 
TotDataCnt=163 
 
Res1=0
 
ParamCnt=8 
 
ParamOff=55 
 
Res2=0 
 
DataCnt=163 
 
DataOff=63 
 
Res3=0
 
Lsetup=0
 
Param Data: (8 bytes)
 
[000] 00 00 00 00 05 00 05 00                           ........ 
 

 
Data Data: (135 bytes)                        Eigentlicher Verzeichnisinhalt:
 
[000] 68 6F 6D 65 73 00 00 00  00 00 00 00 00 00 00 00  homes... ........
 
[010] 64 00 00 00 70 75 62 6C  69 63 00 00 00 00 00 00  d...publ ic......
 
[020] 00 00 00 00 75 00 00 00  74 65 6D 70 00 00 00 00  ....u... temp....
 
[030] 00 00 00 00 00 00 00 00  76 00 00 00 49 50 43 24  ........ v...IPC$
 
[040] 00 00 00 00 00 00 00 00  00 00 03 00 77 00 00 00  ........ ....w...
 
[050] 64 6F 6E 68 61 6D 00 00  00 00 00 00 00 00 00 00  donham.. ........
 
[060] 92 00 00 00 48 6F 6D 65  20 44 69 72 65 63 74 6F  ....Home  Directo
 
[070] 72 69 65 73 00 00 00 49  50 43 20 53 65 72 76 69  ries...I PC Servi
 
[080] 63 65 20 28 53 61 6D                              ce (Sam

Die Ausgabe stammt aus derselben Sitzung wie der Befehl trace: das Listing eines Verzeichnisses. Die verwendeten Optionen waren -v (ausführliche Ausgabe), -i eth0 (die Netzwerkschnittstelle, an der tcpdump lauschen sollte - ein Ethernet-Port) und -s 255 (um die ersten 255 Bytes jedes Pakets anzeigen zu lassen anstatt wie vorgegeben die ersten 68). Mit der Option port not telnet haben wir die Anzeige von Telnet-Sitzungen deaktiviert, weil wir über das Netzwerk auf dem Server angemeldet waren. Das Programm tcpdump kennt eine Menge Optionen, mit denen Sie unerwünschten Netzwerkverkehr herausfiltern können. Mit snoop oder etherdump erhalten Sie eine ähnliche Ausgabe.

Sie können die veränderte Variante von tcpdump vom Samba-FTP-Server herunterladen; Sie finden sie unter ftp://samba.anu.edu.au/pub/samba/tcpdump-smb. Andere Varianten enthalten keine Unterstützung für das SMB-Protokoll; wenn Sie keine Ausgabe wie im obigen Beispiel sehen, müssen Sie die Version mit SMB-Unterstützung verwenden.

Ethereal verwenden

Ethereal (http://www.ethereal.com) ist ein grafisch orientiertes Programm, das die gleichen Grundfunktionen ausführt wie tcpdump. Möglicherweise bevorzugen Sie die Benutzung von Ethereal, weil es leichter zu bedienen ist. Wenn Ethereal läuft, gehen Sie folgendermaßen vor:

1. Wählen Sie Start aus dem Capture-Menü.
2. Klicken Sie in dem sich öffnenden Dialog auf ok. Dadurch öffnet sich ein Dialogfeld, in dem gezeigt wird, wie viele Pakete Ethereal gesehen hat. Führen Sie auf dem System (oder den Systemen) in Ihrem Netzwerk die Aktion aus, mit der Sie das Problem, das Sie gerade untersuchen, reproduzieren können.
3. Klicken Sie auf den Stop-Button im Ethereal-Dialog, um die Sammlung der Daten zu beenden.
4. Klicken Sie im Hauptfenster von Ethereal auf einen Eintrag im oberen Fenster, um ihn im unteren Fenster näher zu betrachten. Im unteren Fenster klicken Sie auf eines der Kästchen mit dem Pluszeichen (+), um die Darstellung zu erweitern.

Ethereal ist ziemlich gut darin, den Inhalt der Pakete, die es aufzeichnet, in ein lesbares Format zu übersetzen. Es sollte Ihnen nur wenige Schwierigkeiten bereiten festzustellen, was während der Aufzeichnungsperiode in Ihrem Netzwerk geschehen ist.

Der Fehlerbaum

Der in diesem Abschnitt präsentierte Fehlerbaum hilft Ihnen bei der Diagnose und beim Beheben von Problemen, die bei der Installation und Umkonfiguration von Samba auftreten können. Dabei handelt es sich um eine erweiterte Form des Dokuments DIAGNOSIS.txt zur Fehlersuche, das in der Samba-Distribution enthalten ist.

Bevor Sie mit der Fehlersuche beginnen, sollten Sie folgende Informationen ermitteln:

Aus Gründen der Klarheit haben wir in den folgenden Beispielen den Server in server. example.com und das Client-System in client.example.com umbenannt.

Wie Sie den Fehlerbaum benutzen

Beginnen Sie die Tests hier und überspringen Sie diesen Schritt nicht. Er dauert nicht lange (etwa fünf Minuten) und kann später Zeit bei der Eingrenzung des Fehlers sparen. Wir sagen Ihnen immer, zu welchem Abschnitt Sie springen können, wenn ein Test erfolgreich verläuft.

Fehlersuche beim IP-Protokoll auf niedriger Ebene

Die erste Serie von Tests findet auf den IP-Diensten der niedrigen Ebene statt, die Samba zur Ausführung benötigt. Die Tests in diesem Abschnitt stellen sicher, dass folgende Punkte zutreffen:

In den folgenden Abschnitten richten wir die TCP-Software ein, die Samba-Daemons smbd und nmbd, die hostbasierte Zugriffskontrolle, die Authentifizierung, die benutzerbasierte Zugriffskontrolle, Dateidienste und das Durchsuchen. Wir haben die Tests ausführlich beschrieben, so dass sowohl technisch orientierte Endanwender als auch erfahrene System- und Netzwerkadministratoren diese verstehen.

Testen der Netzwerk-Software mit ping

Der erste Befehl, den Sie sowohl am Samba-Server als auch am Client eingeben sollten, lautet ping 127.0.0.1. Dabei handelt es sich um die Loopback-Adresse, über die Sie herausfinden können, ob die Netzwerkunterstützung überhaupt funktioniert. Verwenden Sie auf Unix-Computern ping 127.0.0.1 mit der Statistik-Option und brechen Sie den Befehl nach einigen Zeilen ab. Auf Sun-Workstations heißt der Befehl üblicherweise /usr/etc/ping -s 127.0.0.1, bei Linux einfach ping 127.0.0.1. Geben Sie auf Windows-Clients an der MS-DOS-Eingabeaufforderung ping 127.0.0.1 ein, der Befehl beendet sich nach vier Zeilen selbst.

Hier ein Beispiel auf einem Linux-Server: 

$ ping 127.0.0.1 
 
PING localhost: 56 data bytes 64 bytes from localhost (127.0.0.1): 
 
icmp-seq=0. time=1. ms 64 bytes from localhost (127.0.0.1): 
 
icmp-seq=1. time=0. ms 64 bytes from localhost (127.0.0.1): 
 
icmp-seq=2. time=1. ms ^C 
 
----127.0.0.1 PING Statistics---- 
 
3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms)  
 
min/avg/max = 0/0/1

Wenn der Befehl ping: no answer from ... oder 100% packet loss ausgibt, ist IP nicht auf dem Computer installiert. Bei 127.0.0.1 handelt es sich um die interne Loopback-Adresse, die Sie auch ansprechen können, wenn der Computer nicht mit dem Netzwerk verbunden ist. Wenn dieser Test fehlschlägt, haben Sie ein ernstes Problem. TCP/IP ist entweder nicht installiert oder falsch konfiguriert. Lesen Sie die Dokumentation Ihres Betriebssystems, wenn es ein Unix-Server ist. Bei einem Windows-Client folgen Sie den Anweisungen in Kapitel 3, um Netzwerkunterstützung zu installieren.


Sind Sie der Netzwerkverwalter, empfehlen wir Ihnen TCP/IP-Netzwerk-Administration, Kapitel 11, von Craig Hunt sowie Windows NT TCP/IP Netzwerk-Administration von Craig Hunt und Robert Bruce Thompson. Beide Bücher sind bei O'Reilly erschienen.
Lokale Namensdienste mit ping testen

Versuchen Sie nun, mit dem Befehl ping localhost auf dem Samba-Server zu erreichen. Der Hostname localhost bezieht sich auf den lokalen Host, also auf die Loopback-Schnittstelle 127.0.0.1, und sollte zu dieser Adresse aufgelöst werden. Nach dem Eingeben von ping localhost sollte die Ausgabe etwa so aussehen: 

$  ping localhost  
 
PING localhost: 56 data bytes  64 bytes from localhost (127.0.0.1):
 
icmp-seq=0. time=0. ms  64 bytes from localhost (127.0.0.1): 
 
icmp-seq=1. time=0. ms  64 bytes from localhost (127.0.0.1): 
 
icmp-seq=2. time=0. ms  ^C

Ist dies erfolgreich, versuchen Sie das Gleiche auf dem Client. Anderenfalls:

Testen der Netzwerk-Hardware mit ping

Versuchen Sie nun, die IP-Adresse des Servers selbst mit ping zu erreichen. Sie sollten genau das gleiche Ergebnis erhalten wie beim ping auf die Adresse 127.0.0.1: 

$ ping 192.168.236.86 
 
PING 192.168.236.86: 56 data bytes 64 bytes from 192.168.236.86 (192.168.236.86): 
 
icmp-seq=0. time=1. ms 64 bytes from 192.168.236.86 (192.168.236.86): 
 
icmp-seq=1. time=0. ms 64 bytes from 192.168.236.86 (192.168.236.86): 
 
icmp-seq=2. time=1. ms ^C 
 
----192.168.236.86 PING Statistics---- 
 
3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms)  
 
min/avg/max = 0/0/1

Wenn dies auf dem Server funktioniert, wiederholen Sie es auf dem Client. Ansonsten:

Testen der Verbindungen mit ping

Versuchen Sie als Nächstes, den Server mit seinem Namen anzusprechen (nicht mit seiner IP-Adresse), und zwar sowohl lokal vom Server als auch vom Client aus. Dabei handelt es sich um einen allgemeinen Test für die Netzwerk-Hardware. 

$ ping server 
 
PING server.example.com: 56 data bytes 64 bytes from server.example.com (192.168.236.86): 
 
icmp-seq=0. time=1. ms 64 bytes from server.example.com (192.168.236.86): 
 
icmp-seq=1. time=0. ms 64 bytes from server.example.com (192.168.236.86): 
 
icmp-seq=2. time=1. ms ^C 
 
----server.example.com PING Statistics---- 
 
3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms)  
 
min/avg/max = 0/0/1

Im Erfolgsfall erfahren Sie fünf Dinge:

Ist dieser Test nicht erfolgreich verlaufen, sind im Netzwerk vermutlich ein oder mehrere Dinge nicht in Ordnung:

Falls nicht, gibt es wenigstens eine falsch zugeordnete Adresse zwischen den beiden Systemen. Geben Sie einmal den Befehl arp -a ein und schauen Sie nach, ob es einen Eintrag für das andere System gibt. (Der Befehl arp steht für das Address Resolution Protocol. arp -a listet alle Adressen auf, die auf dem lokalen System bekannt sind.) Hier sind einige Dinge, die Sie ausprobieren können:
- Wenn Sie eine Nachricht wie 192.168.236.86 at (incomplete) empfangen, ist die Ethernet-Adresse von 192.168.236.86 unbekannt. Das ist ein Zeichen für eine fehlende Netzwerkverbindung. Wahrscheinlich haben Sie ein Problem mit dem TCP/IP-Protokoll-Stack, und zwar mit der Ebene der Ethernet-Schnittstelle. Näheres dazu finden Sie in den Kapiteln 5 und 6 des Buches TCP/IP Netzwerk-Administration (O'Reilly).
- Wenn Sie eine Antwort wie server (192.168.236.86) at 8:0:20:12:7c:94 erhalten, wurde der Server irgendwann einmal erreicht, oder ein anderes System antwortet in seinem Namen. Das bedeutet jedoch, dass ping funktioniert haben sollte: Sie haben ein Netzwerk- oder ARP-Problem.
- Wenn die IP-Adresse des ARP nicht den erwarteten Adressen entspricht, untersuchen und korrigieren Sie die Adressen manuell.
Im Prinzip sollten Sie nicht versuchen, Fehler bei SMB-Clients und -Server in unterschiedlichen Netzwerken zu beheben. Versuchen Sie, einen Server und einen Client zu testen, die sich im gleichen Netzwerk befinden:
1. Führen Sie zuerst die Tests für ping: no answer aus, die weiter vorn in diesem Abschnitt beschrieben worden sind. Kann das Problem damit nicht ermittelt werden, bleiben noch folgende Möglichkeiten: Eine Adresse ist falsch, Ihre Netzmaske ist falsch, ein Netzwerk ist nicht in Betrieb, oder die Pakete sind durch eine Firewall gestoppt worden.
2. Überprüfen Sie sowohl die Adresse als auch die Netzmasken an den Quell- und Zielsystemen, um festzustellen, ob etwas offensichtlich verkehrt ist. Angenommen, beide Systeme befinden sich wirklich im gleichen Netzwerk, dann sollten beide die gleiche Netzmaske besitzen, und ping sollte die richtigen Adressen zurückliefern. Wenn die Adressen falsch sind, müssen Sie diese korrigieren. Wenn sie richtig sind, wurden die Programme vielleicht durch eine falsche Netzmaske verwirrt. Siehe den Abschnitt »Netzmasken« weiter unten in diesem Kapitel.
3. Wenn die Befehle weiterhin berichten, dass das Netzwerk unerreichbar ist und keine der genannten Bedingungen eingetroffen ist, besteht vermutlich wirklich keine Verbindung zwischen den beiden Netzwerken. Auch dieses Problem muss vom Netzwerkverwalter gelöst werden.
Server sind häufig multihomed  - d.h. mit mehr als einem Netzwerk verbunden. Sie besitzen in jedem Netzwerk einen eigenen Namen. Wenn Sie eine Antwort mit einem nicht erwarteten Namen von einem Multihomed-Server bekommen, prüfen Sie, ob die Adresse in Ihrem Netzwerk liegt (sehen Sie sich den Abschnitt »Netzmasken« weiter unten in diesem Kapitel an). In diesem Fall sollten Sie aus Gründen der Zuverlässigkeit und der Leistung diese Adresse und nicht diejenige eines anderen Netzwerks benutzen.
Server können außerdem für eine einzige Ethernet-Adresse mehrere Namen besitzen; das trifft besonders auf Webserver zu. Das ist unproblematisch, wenn auch möglicherweise überraschend. Sie sollten den offiziellen (permanent gültigen) Namen benutzen anstatt einen Alias-Namen, der sich ändern oder ungültig werden kann.

Wenn dies vom Server aus funktioniert hat, wiederholen Sie die Tests vom Client aus.

TCP-Fehlersuche

Nachdem Sie nun IP, UDP und einen Namensdienst mit ping getestet haben, wird es Zeit, TCP zu testen. Das Durchsuchen und ping verwenden ICMP und UDP, die Datei- und Druckdienste (Freigaben) benutzen TCP. Beide hängen von IP als darunter liegender Schicht ab, und alle vier benötigen Namensdienste. Das Testen von TCP geschieht am bequemsten mit dem FTP-Programm.

Testen von TCP mit FTP

Versuchen Sie eine FTP-Verbindung herzustellen, und zwar einmal lokal vom Server zu sich selbst und einmal vom Client zum Server: 

$ ftp server
 
Connected to server.example.com. 
 
220 server.example.com FTP server (Version 6.2/OpenBSD/Linux-0.10) ready.
 
 Name (server:davecb): 
 
331 Password required for davecb. 
 
Password: 
 
230 User davecb logged in.
 
 ftp> quit 
 
221 Goodbye.

Hat dies funktioniert, gehen Sie zum nächsten Abschnitt »Fehlersuche bei den Server-Daemons« über, ansonsten:

Fehlersuche bei den Server-Daemons

Wenn die TCP-Kommunikation einwandfrei funktioniert, müssen Sie sicherstellen, dass der Server die Daemons ausführt. Dazu sind drei separate Tests notwendig, weil kein einzelner der drei Tests entscheidend beweist, dass sie richtig funktionieren.

Um sicher zu sein, dass sie laufen, müssen Sie feststellen, ob die Daemons:

1. gestartet wurden
2. durch das Betriebssystem registriert oder an einen TCP/IP-Port gebunden wurden
3. tatsächlich arbeitsbereit sind
Den Start der Daemons überwachen

Prüfen Sie zunächst die Protokolldateien. Wenn Sie die Daemons gestartet haben, sollte darin die Meldung smbd version Versionsnummer started erscheinen. Wenn dies nicht der Fall ist, müssen Sie die Samba-Daemons erneut starten.

Wenn die Daemons der Protokolldatei zufolge gestartet sind, suchen Sie nach der Meldung bind failed on port 139 socket_addr=0 (Address already in use). Sie besagt, dass bereits ein anderer Daemon den Port 139 (smbd ) belegt. nmbd liefert eine ähnliche Meldung, wenn er Port 137 nicht belegen kann. Entweder haben Sie die Daemons zweimal gestartet, oder der inetd-Server hat versucht, einen Daemon für Sie aufzurufen. Diesen Fall behandeln wir in Kürze.

Die Daemon-Prozesse mit ps suchen

Eine andere Möglichkeit, um sicherzustellen, dass die Daemons ausgeführt werden, besteht darin, ihre Prozesse im System zu prüfen. Benutzen Sie den Befehl ps auf dem Server mit der Option »lang« für Ihren Systemtyp (üblicherweise ps ax oder ps -ef) und schauen Sie nach, ob smbd und nmbd bereits laufen. Oft sieht dies so aus: 

$ ps ax
 
 PID TTY STAT TIME   COMMAND
 
 1   ?   S    0:03   init [2] 
 
 2   ?   SW   0:00   (kflushd)
 
(...viele Zeilen mit Prozessen...) 
 
 234 ?   S    0:14   nmbd -D3
 
 237 ?   S    0:11   smbd -D3
 
(...weitere Zeilen, möglicherweise mit weiteren smbd-Zeilen...)

Dieses Beispiel zeigt, dass smbd und nmbd ausgeführt werden und als allein stehende Daemons (die Option -D) mit der Protokollierungsstufe 3 gestartet wurden.

Prüfen, ob die Daemons an Ports gebunden sind

Als Nächstes müssen die Daemons am Betriebssystem registriert werden, damit sie auf die TCP/IP-Ports zugreifen dürfen. Der Befehl netstat teilt Ihnen mit, ob dies geschehen ist. Geben Sie auf dem Server netstat -a ein und suchen Sie in der Ausgabe nach Zeilen, die netbios, 137 oder 139 enthalten: 

$ netstat -a 
 
Active Internet connections (including servers) 
 
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state) 
 
udp   0      0       *.137                  *.* 
 
tcp   0      0       *.139                  *.*                    LISTEN 
 
tcp   8370   8760    server.139             client.1439            ESTABLISHED

Inmitten vieler ähnlich aussehender Zeilen sollte zumindest eine UDP-Zeile für *.netbios- oder *.137 sein. Sie sagt Ihnen, dass der nmbd-Server registriert ist und (das hoffen wir) Anfragen beantworten kann. Außerdem sollte die Ausgabe wenigstens eine TCP-Zeile mit *.netbios- oder *.139 enthalten, wahrscheinlich mit dem Zustand LISTEN. Das bedeutet, dass smbd aktiv ist und auf Verbindungen wartet.

Möglicherweise sehen Sie weitere TCP-Zeilen, die Verbindungen von smbd zu Clients beschreiben (für jede Verbindung eine Zeile). Ihr Zustand ist gewöhnlich ESTABLISHED. Wenn Sie smbd-Zeilen mit dem Zustand ESTABLISHED sehen, führt Ihr Server smbd definitiv aus. Wenn Sie nur eine Zeile mit dem Zustand LISTEN sehen, können wir keine sichere Aussage darüber machen. Fehlen beide Zeilen, wurde einer der Daemons nicht gestartet. Sie müssen die Protokolle prüfen und sollten Kapitel 2 lesen.

Wenn es für jeden Client eine Zeile gibt, kann diese entweder vom Samba-Daemon oder vom Haupt-IP-Daemon, inetd, kommen. Es ist durchaus möglich, dass Ihre inetd-Startdatei Zeilen für den Start der Samba-Daemons enthält, ohne dass Sie es wissen (möglicherweise hat ein Setup-Programm die Zeilen dort eingetragen, wenn Sie Samba als Teil einer Linux-Distribution installiert haben). Die von inetd gestarteten Daemons verhindern, dass unsere Daemons ausgeführt werden. Dieses Problem generiert üblicherweise Protokollmeldungen wie bind failed on port 139 socket addr=0 (Address already in use).

Prüfen Sie Ihre Datei /etc/inetd.conf ; solange Sie die Daemons absichtlich und bewusst von hier aus starten, dürfen dort keine netbios-ns-Einträge (UDP-Port 137) oder netbios-ssn-Einträge (TCP-Port 139) vorhanden sein. Wenn Ihr System einen SMB-Daemon über inetd zur Verfügung stellt, finden Sie in der inetd.conf-Datei Zeilen wie die folgenden: 

netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd smbd
 
netbios-ns dgram udp wait root /usr/local/samba/bin/nmbd nmbd

Verwendet Ihr System xinetd an Stelle von inetd, erfahren Sie in Kapitel 2 mehr über seine Konfiguration.

smbd mit telnet prüfen

Witzigerweise besteht die einfachste Methode zum Testen der tatsächlichen Betriebsbereitschaft des smbd-Servers darin, ihm eine sinnlose Nachricht zu schicken und abzuwarten, ob er sie abweist. Versuchen Sie einmal so etwas: 

$ echo "hello" | telnet localhost 139 
 
Trying
 
Trying 192.168.236.86 ... 
 
Connected to localhost. Escape character is '^]'. 
 
Connection closed by foreign host.

Dieser Befehl sendet eine falsche, aber harmlose Nachricht an smbd. Erhalten Sie die Meldung Connected, gefolgt von der Meldung Connection closed, verlief der Test erfolgreich. Ein smbd-Daemon wartet an dem Port und weist unpassende Verbindungsmeldungen ab. Bekommen Sie dagegen die Meldung telnet:connect:Connection refused, ist der Daemon wahrscheinlich nicht vorhanden.

Leider gibt es für nmbd keinen so einfachen Test. Wenn sowohl der telnet- als auch der netstat-Test erfolgreich sind, ist die Wahrscheinlichkeit hoch, dass netstat auch eine richtige Aussage über den Prozess nmbd macht.

Die Daemons mit testparm testen

Sobald Sie wissen, dass es einen Daemon gibt, sollten Sie in der Hoffnung auf die folgende Ausgabe den Befehl testparm ausführen: 

$ testparm 
 
Load smb config files from /opt/samba/lib/smb.conf
 
Processing section "[homes]" 
 
Processing section "[printers]" ... 
 
Processing section "[tmp]" 
 
Loaded services file OK. ...

Das Programm testparm berichtet normalerweise die Verarbeitung in einer Reihe von Abschnitten und gibt im Erfolgsfall die Meldung Loaded services file OK aus. Wenn es ein Problem gibt, sehen Sie eine oder mehrere der folgenden Ausgaben, die zusätzlich in dieser Form in der Protokolldatei auftauchen:

Allow/Deny connection from account (n) to service
Eine nur von testparm ausgegebene Nachricht, die erzeugt wird, wenn Sie die Option valid user oder invalid user in der Datei smb.conf gesetzt haben. Stellen Sie sicher, dass Sie in der Liste der gültigen Benutzer aufgeführt sind und dass root, bin usw. in der Liste der ungültigen Benutzer stehen. Wenn Sie dies nicht tun, können Sie sich nicht mit dem Samba-Server verbinden, oder andere Personen können sich verbinden, ohne es zu dürfen.
Warning: You have some share names that are longer than eight chars
Diese Meldung ist nur von Bedeutung, wenn Sie Windows for Workgroups- oder ältere Clients besitzen. Diese können sich nicht mit Freigaben verbinden, deren Namen mehr als acht Zeichen lang sind. Die Clients geben eine verwirrende Meldung aus, die auf Speicherprobleme hindeutet.
Warning: [name] service MUST be printable!
Bei einer Druckerfreigabe fehlt die Option printable = yes.
No path in service name using [name]
Einer Verzeichnisfreigabe ist nicht bekannt, welches Verzeichnis sie dem Benutzer anbieten soll, oder einer Druckerfreigabe fehlt die Angabe des Spool-Verzeichnisses. Wenn Sie keinen Pfad angeben, verwendet der Dienst /tmp, was Sie wahrscheinlich nicht wollen.
Note: Servicename is flagged unavailable
Nur ein Hinweis darüber, dass Sie die Option available = no in einer Freigabe verwendet haben.
Can't find include file [name]
Eine Konfigurationsdatei, auf die mit der Option include verwiesen wird, existiert nicht. Falls Sie diese Datei bedingungslos eingeschlossen haben, handelt es sich um einen Fehler, und zwar wahrscheinlich um einen ernsten: Die Freigabe weist nicht die von Ihnen beabsichtigte Konfiguration auf. Haben Sie die Datei auf der Grundlage einer der %-Variablen eingeschlossen, etwa %a (für die Client-Architektur), müssen Sie selbst entscheiden, ob eine fehlende Konfigurationsdatei beispielsweise für Windows for Workgroups ein Problem darstellt. Oft ist das nicht der Fall.
Can't copy service name, unable to copy to itself
Sie haben versucht, einen Abschnitt der smb.conf in sich selbst zu kopieren.
Unable to copy service - source not found: [name]
Kennzeichnet einen fehlenden oder falsch geschriebenen Abschnitt in einer copy = Option.
Ignoring unknown parameter name
Kennzeichnet typischerweise eine veraltete, falsch geschriebene oder nicht unterstützte Option.
Global parameter name found in service section
Gibt an, dass ein globaler Parameter in einer bestimmten Freigabe verwendet wurde. Samba ignoriert den Parameter.

Wiederholen Sie den testparm-Test anschließend mit (genau) drei Parametern: dem Namen Ihrer smb.conf-Datei sowie dem Namen Ihres Clients und seiner IP-Adresse: 

# testparm /usr/local/samba/lib/smb.conf client 192.168.236.10

Mit diesem Test werden der Hostname und die Adresse mit den Optionen hosts allow und hosts deny verglichen. Es könnten die Meldungen Allow connection from hostname to service und/oder Deny connection from hostname to service für das Client-System erzeugt werden. Diese Meldungen zeigen an, dass Sie die Optionen hosts allow und/oder hosts deny in Ihrer smb.conf haben, die den Zugriff vom Client-System erlauben oder verbieten.

Fehlersuche bei SMB-Verbindungen

Sie wissen jetzt, dass die Server in Betrieb sind, und müssen nun sicherstellen, dass sie richtig ausgeführt werden. Wir beginnen damit, dass wir eine einfache smb.conf-Datei in das Verzeichnis /usr/local/samba/lib legen.

Eine minimale smb.conf-Datei

In den folgenden Tests nehmen wir an, dass Sie eine [temp]-Freigabe haben, die sich für die Tests eignet, und dass noch ein weiterer Zugang vorliegt. Im Folgenden sehen Sie eine smb.conf-Datei, die genau diese Anforderungen erfüllt: 

[global] 
 
    workgroup = EXAMPLE 
 
    security = user
 
    browsable = yes 
 
    local master = yes 
 
[homes] 
 
    guest ok = no 
 
    browsable = no
 
[temp] 
 
    path = /tmp 
 
    public = yes

Die Option public = yes in der [temp]-Freigabe dient lediglich Testzwecken. Sie wollen wahrscheinlich nicht, dass jemand, der keinen Zugang auf Ihrem Samba-Server hat, Dinge darauf ablegen kann. Deshalb sollten Sie diese Option auskommentieren, wenn Sie mit den Tests fertig sind.
Lokale Tests mit smbclient

Der erste Test soll sicherstellen, dass der Server seine eigenen Dienste (Freigaben) auflisten kann. Führen Sie den Befehl smbclient -L localhost -U% aus, um eine Verbindung zum Server von sich selbst aus herzustellen und den Gastbenutzer anzugeben. Sie sollten Folgendes sehen: 

$ smbclient -L localhost -U% 
 
Server time is Wed May 27 17:57:40 2002 Timezone is UTC-4.0
 
Server=[localhost] 
 
User=[davecb] 
 
Workgroup=[EXAMPLE] 
 
Domain=[EXAMPLE]
 
	Sharename      Type      Comment 
 
	---------      -----     ----------
 
	temp           Disk
 
	IPC$           IPC       IPC Service (Samba 1.9.18) 
 
	homes          Disk      Home directories
 
This machine does not have a browse list

Wenn Sie diese Ausgabe erhalten haben, können Sie mit dem nächsten Abschnitt, »Testen der Verbindungen mit smbclient«, fortfahren. Bei einem Fehler überprüfen Sie diese Punkte:

- Ungültige Kommandozeilen-Parameter für smbd ; siehe die smbd-Manpage.
- Ein ernsthaftes Problem mit der Datei smb.conf, die den Start von smbd verhindert. Prüfen Sie Ihre Änderungen immer mit testparm, wie im Abschnitt »Die Daemons mit testparm testen« demonstriert.
- Fehlende Verzeichnisse, in denen Samba eigentlich seine Protokoll- und Sperrdateien ablegen soll.
- Das Vorhandensein eines Servers am Port (139 für smbd, 137 für nmbd  ), das verhindert, dass der Daemon startet.
Testen der Verbindungen mit smbclient

Führen Sie den Befehl smbclient \\server\temp aus, um eine Verbindung zur [temp]-Freigabe des Servers aufzubauen und festzustellen, ob Sie eine Verzeichnisfreigabe erreichen. Sie sollten folgende Antwort erhalten: 

$ smbclient '\\server\temp' 
 
Server time is Tue May  5 09:49:32 2002 Timezone is UTC-4.0 Password:
smb: \> quit

Diese Fehler könnten auftreten: 

smbclient \\\\server\\temp
oder: 
smbclient //server/temp

Geben Sie nun Ihr Unix-Kennwort am Password:-Prompt ein. Wenn Sie dann den Prompt smb: \> sehen, hat der Verbindungsaufbau funktioniert. Geben Sie quit ein und fahren Sie mit dem Abschnitt »Testen der Verbindungen mit net use« fort. Wenn Sie als Fehlermeldung SMBtconX failed. ERRSRV-ERRinvnetname bekommen, handelt es sich wahrscheinlich um eines der folgenden Probleme:

Ein fehlerhafter Gastzugang verhindert auch das Drucken oder Durchsuchen, solange Sie sich noch nicht an Ihrem Home-Verzeichnis angemeldet haben.

Es gibt einen weiteren möglichen Grund für diesen Fehlschlag, der nichts mit Kennwörtern zu tun hat: Der Parameter path in Ihrer Datei smb.conf zeigt möglicherweise auf ein nicht existierendes Verzeichnis. testparm erkennt diesen Fehler nicht, und die meisten SMB-Clients können ihn nicht von falschen Benutzerzugängen unterscheiden. Sie müssen es selbst überprüfen.

Wenn Sie sich erfolgreich an der Freigabe [temp] angemeldet haben, wiederholen Sie den Test und melden sich dieses Mal an Ihrem Home-Verzeichnis an (z.B. weisen Sie das Netzlaufwerk server\davecb zu). Wenn Sie irgendetwas ändern müssen, damit dies funktioniert, probieren Sie es anschließend noch einmal mit [temp].

Testen der Verbindungen mit net use

Führen Sie den Befehl net use * \\server\temp auf dem Windows-Client aus, um festzustellen, ob dieser eine Verbindung zum Server herstellen kann. Sie müssten nach einem Kennwort gefragt werden und anschließend die Meldung Der Befehl wurde ausgeführt erhalten.

Wenn das funktioniert hat, fahren Sie mit den Schritten im nächsten Abschnitt, »Testen der Verbindungen mit dem Windows-Explorer«, fort. Ansonsten:

- Wenn Sie den Namen des Servers und der Freigabe richtig geschrieben haben, müssen Sie zum Abschnitt »Testen der Verbindungen mit smbclient« zurückkehren, um festzustellen, weshalb es nicht funktioniert.
- Wenn smbclient funktioniert, gibt es ein Namensdienst-Problem mit dem Client-Namensdienst, und Sie müssen sich zum Abschnitt »Testen des Servers mit nmblookup« begeben und versuchen, sowohl den Client als auch den Server mit nmblookup nachzusehen.

Windows 95/98/Me-Clients speichern das Kennwort lokal in einer Datei, es handelt sich dabei aber nur um eine zwischengespeicherte Kopie des Kennworts, das zur Authentifizierung an Samba und an NT/2000/XP-Server geschickt wird. Danach werden Sie hier auch gefragt. An einem Windows-System können Sie sich weiterhin ohne Kennwort anmelden (allerdings nicht an NT/2000/XP).
Falls Sie Ihr Kennwort eingeben und die Verbindung dennoch nicht erfolgreich herstellen können, gibt es mehrere Möglichkeiten: Sie haben eine valid users- oder invalid users-Liste, durch die Ihnen der Zugriff verweigert wird, NetBEUI macht Probleme, oder Sie haben das Problem mit den verschlüsselten Kennwörtern, das wir im nächsten Abschnitt beschreiben.

Da der Internet Explorer bei URLs wie file://irgendeinHost/irgendeineDatei eine SMB-Verbindung herstellt, senden Clients bis einschließlich Windows 95 Patch Level 2 freimütig Ihr Kennwort im Klartext an SMB-Server irgendwo im Internet. Das wurde schließlich als ziemlich schlechte Idee erkannt. Microsoft ging daraufhin dazu über, im SMB-Protokoll nur noch verschlüsselte Kennwörter einzusetzen. Alle nachfolgenden Ausgaben der Microsoft-Produkte enthalten diese Korrektur.

Der Begriff »binden« bedeutet an dieser Stelle eine logische Verbindung zwischen zwei Software-Bestandteilen. Wenn der Microsoft-SMB-Client korrekt konfiguriert wurde, ist er im Register Bindungen des Eigenschaften-Fensters von TCP/IP (im Bereich Netzwerk der Systemsteuerung von Windows 95/98/Me) an TCP/IP »gebunden«. TCP/IP wiederum ist an eine Ethernet-Karte gebunden. Das bedeutet nicht das Gleiche wie das Binden eines SMB-Daemons an einen TCP/IP-Port.
Testen der Verbindungen mit dem Windows-Explorer

Starten Sie den Windows-Explorer (nicht den Internet Explorer), wählen Sie Netzlaufwerk verbinden aus dem Extras-Menü und geben Sie eine UNC für eine Ihrer Freigaben auf dem Samba-Server an, um festzustellen, ob der Explorer eine Verbindung dorthin aufbauen kann. Gelingt dies, können Sie zum nächsten Abschnitt, »Fehlersuche beim Durchsuchen«, übergehen.

Der Windows-Explorer ist kein gutes Werkzeug zur Diagnose: Er sagt Ihnen, dass etwas nicht stimmt, gibt aber nicht bekannt, worum es sich handelt. Wenn Sie einen Fehler erhalten, müssen Sie dessen Ursache mit dem Windows-Befehl net use ermitteln, der eine aussagekräftigere Fehlermeldung ausgibt:

- Ihre lokal zwischengespeicherte Kopie auf dem Client stimmt nicht mit der auf dem Server überein.
- Sie haben bei der Anmeldung auf dem Client keinen Benutzernamen und kein Kennwort angegeben. Einige Versionen des Explorers senden weiterhin einen leeren Benutzernamen und ein leeres Kennwort, selbst wenn Sie ein Kennwort angegeben haben.
- Sie haben das Kennwort falsch geschrieben.
- Sie haben eine invalid users- oder valid users-Liste, die den Zugriff verweigert.
- Ihr Client benutzt standardmäßig verschlüsselte Kennwörter, Samba ist jedoch mit dem Parameter encrypt passwords = no in der Konfigurationsdatei konfiguriert worden.
- Sie haben ein Kennwort in gemischter Schreibweise, das der Client jedoch nur in einer Schreibweise übermittelt.
- falsch geschriebener Name
- Fehlfunktion des Diensts
- eine fehlgeschlagene Freigabe
- Netzwerkproblem
- falscher path-Parameter in smb.conf
- hosts deny-Zeile, die Sie ausschließt

Wenn Sie die Freigabe zuverlässig benutzen können, versuchen Sie, auf Ihr Home-Verzeichnis zuzugreifen. Falls Sie etwas ändern müssen, damit Sie das Home-Verzeichnis »sehen« können, probieren Sie es erneut mit der ersten Freigabe und umgekehrt, wie wir im Abschnitt »Testen von Verbindungen mit net use« gezeigt haben. Gibt es Probleme mit dem Windows-Explorer, suchen Sie den Fehler mit den Methoden, die dieser Abschnitt beschreibt.

Fehlersuche beim Durchsuchen

Lassen Sie uns nun zum Durchsuchen kommen. Wir haben uns dieses Thema bis hierhin aufgespart, weil es optional ist und teilweise von einem Protokoll abhängt, das die Auslieferung von Paketen nicht garantiert. Das Durchsuchen ist schwer zu untersuchen, wenn Sie nicht sicher sind, dass alle anderen Dienste ausgeführt werden.

Die Funktion Durchsuchen ist optional, sie ist einfach nur ein Weg, um Server im Netzwerk und ihre Freigaben zu finden. Unix kennt keine solche Funktion und existiert glücklich ohne eine solche. Das Durchsuchen geht außerdem davon aus, dass sich all Ihre Systeme in einem lokalen Netzwerk (LAN) befinden, in dem Broadcasts erlaubt sind.

Zunächst identifiziert der Suchmechanismus einen Computer mit dem nicht zuverlässigen UDP-Protokoll, um dann über eine gewöhnliche (zuverlässige) TCP-Verbindung die bereitgestellten Freigaben aufzulisten.

Testen des Durchsuchens mit smbclient

Wir beginnen mit dem Test einer zuverlässigen Verbindung. Versuchen Sie vom Server aus, die lokalen Freigaben mit dem Befehl smbclient und der Option -L sowie dem Namen Ihres Servers aufzulisten. Die Ausgabe sollte etwa folgendermaßen aussehen: 

$ smbclient -L server 
 
Added interface ip=192.168.236.86 bcast=192.168.236.255 nmask=255.255.255.0 Server time is Tue Apr 28 
09:57:28 2002 Timezone is UTC-4.0 
 
Password: 
 
Domain=[EXAMPLE] OS=[Unix] Server=[Samba 2.2.5]
 

 
   Sharename      Type      Comment    
 
   ---------      ----      -------    
 
    cdrom          Disk      CD-ROM    
 
    cl             Printer   Color Printer 1    
 
    davecb         Disk      Home Directories
 

 
   Server         Comment    
 
   ---------      -------    
 
   SERVER         Samba 2.2.5
 

 
   Workgroup      Master    
 
   ---------      -------    
 
   EXAMPLE        SERVER

Wenn Sie immer noch nichts sehen, dürften Sie eigentlich gar nicht bis hierhin gekommen sein. Gehen Sie zu einem der Abschnitte »Testen von TCP mit FTP« oder »Testen der Verbindungen mit ping« zurück. Sehen Sie sich auch folgende Punkte an:

- eine falsche hosts allow- oder hosts deny-Zeile
- eine falsche invalid users- oder valid users-Zeile
- ein Kennwort in Kleinbuchstaben und OS/2- oder Windows for Workgroups-Clients
- einen fehlenden oder ungültigen Gastzugang
Prüfen Sie, wie Ihr Gastzugang lautet (siehe den Abschnitt »Lokale Tests mit smbclient«), ändern Sie alle hosts allow-, hosts deny-, valid users- oder invalid users-Zeilen oder kommentieren Sie sie aus und überprüfen Sie Ihre smb.conf-Datei mit testparm smb.conf ihr_hostname ihre_ip_adresse (siehe »Die Daemons mit testparm testen«).
Testen des Servers mit nmblookup

Diese Tests prüfen das Ankündigungssystem, das für Windows-Namensdienste und das Durchsuchen verwendet wird. Ankündigungen geben die Anwesenheit eines Systems und dessen Fähigkeit, Dienste bereitzustellen, bekannt. Dieser Teil des Durchsuchens verwendet ein nicht zuverlässiges Protokoll (UDP) und funktioniert nur in Broadcast-Netzwerken wie Ethernet-Netzwerken. Das Programm nmblookup fragt per Broadcast nach dem Hostnamen, den Sie angeben, und liefert seine IP-Adresse und den Namen des Systems, ähnlich wie nslookup für das Domain Name System (DNS). Hier verwenden wir die Optionen -d (Protokollierungsstufe) und -B (Broadcast-Adresse), um die Anfragen an bestimmte Systeme zu richten.

Zunächst wollen Sie feststellen, ob Sie den lokalen Server erreichen können. Führen Sie nmblookup mit der Option -B und dem Namen Ihres Servers aus (damit die Software die Anfrage an den Samba-Server sendet). Geben Sie außerdem den Parameter _ _SAMBA_ _ als symbolischen Namen an, der nachgefragt werden soll. Sie sollten Folgendes erhalten: 

$ nmblookup -B server _ _SAMBA_ _
 
Added interface ip=192.168.236.86 bcast=192.168.236.255 nmask=255.255.255.0 
 
Sending queries to 192.168.236.86 192.168.236.86 _ _SAMBA_ _

Hiermit haben Sie die IP-Adresse des Servers erhalten, gefolgt von _ _SAMBA_ _ , was bedeutet, dass der Server erfolgreich einen Dienst mit diesem Namen angekündigt hat. Sie wissen nun, dass der NetBIOS-Namensdienst zumindest teilweise funktioniert.

Testen des Clients mit nmblookup

Prüfen Sie nun die IP-Adresse des Clients vom Server aus, indem Sie nmblookup mit der Option -B für den Namen des Clients und dem Parameter '*' für »alle« ausführen, wie hier gezeigt wird: 

$ nmblookup -B client '*' 
 
Sending queries to 192.168.236.10 192.168.236.10 *
 
Got a positive name query response from 192.168.236.10 (192.168.236.10)

Sie könnten folgenden Fehler erhalten:

Wiederholen Sie den Befehl mit den folgenden Optionen, falls Fehler aufgetreten sind:

Testen des Netzwerks mit nmblookup

Führen Sie erneut den Befehl nmblookup mit der Option -d2 (Protokollierungsstufe 2) und dem Parameter '*' aus. Diesmal testen Sie, ob Programme (wie nmbd ) Broadcast-Pakete schicken können. Dabei handelt es sich im Wesentlichen um einen Test der Verbindung über Broadcast an die Standard-Broadcast-Adresse.

In Ihrem Netzwerk sollten mehrere NBT-Hosts (NetBIOS over TCP/IP) antworten; sie erkennen die Antworten an den Meldungen got a positive name query response. Samba empfängt möglicherweise nicht alle Antworten in der kurzen Zeit, in der es wartet, daher sehen Sie wahrscheinlich nicht alle SMB-Clients in Ihrem Netzwerk. Die meisten sollten aber erscheinen. 

$ nmblookup -d 2 '*' 
 
Added interface ip=192.168.236.86 bcast=192.168.236.255 nmask=255.255.255.0 Sending queries to 
192.168.236.255 
 
Got a positive name query response from 192.168.236.191 (192.168.236.191) 
 
Got a positive name query response from 192.168.236.228 (192.168.236.228) 
 
Got a positive name query response from 192.168.236.75 (192.168.236.75) 
 
Got a positive name query response from 192.168.236.79 (192.168.236.79) 
 
Got a positive name query response from 192.168.236.206 (192.168.236.206) 
 
Got a positive name query response from 192.168.236.207 (192.168.236.207) 
 
Got a positive name query response from 192.168.236.217 (192.168.236.217) 
 
Got a positive name query response from 192.168.236.72 (192.168.236.72) 192.168.236.86 *

Aber:

Außerdem können Sie natürlich die Samba-Protokolldateien auf Verdächtiges prüfen.

Das Durchsuchen von Clients mit dem Befehl net view testen

Geben Sie auf einem Windows-Client an der MS-DOS-Eingabeaufforderung den Befehl net view \\server ein, um festzustellen, ob Sie eine Verbindung zum Server herstellen und nach den angebotenen Freigaben fragen können. Sie sollten eine Liste der verfügbaren Freigaben auf dem Server erhalten.

Wenn dies funktioniert, fahren Sie mit dem Abschnitt »Dokumentation und FAQs« fort. Ansonsten:

Durchsuchen des Servers vom Client aus

Versuchen Sie, den Server von der Windows-Netzwerkumgebung aus zu durchsuchen. Ihr Samba-Server sollte in der Suchliste Ihrer lokalen Arbeitsgruppe auftauchen. Sie müssten in der Lage sein, auf den Namen des Servers doppelt zu klicken, um eine Liste der Freigaben zu erhalten.

- Sie haben zu früh nachgesehen, die Broadcasts und Aktualisierungen waren noch nicht beendet. Warten Sie 30 Sekunden und versuchen Sie es erneut.
- Es gibt ein Netzwerkproblem, das Sie noch nicht erkannt haben.
- Es gibt keinen Hauptsuchdienst. Fügen Sie die Konfigurationsoption local master = yes in Ihre smb.conf-Datei ein.
- In der Datei smb.conf wurden keine Freigaben als durchsuchbar gekennzeichnet.
- Sie haben das Problem mit den verschlüsselten Kennwörtern.
- Das System ist wirklich nicht erreichbar.
- Das System unterstützt das Durchsuchen nicht.

Wenn Sie bis hierhin gekommen sind und es immer noch Probleme gibt, sind Sie entweder auf ein Problem gestoßen, das auch uns unbekannt ist, oder es handelt sich um ein Problem aus einem Bereich, den wir bereits behandelt haben und der eine weitere Untersuchung verlangt. Oft hängen die Schwierigkeiten mit Samba mit der Namensauflösung zusammen, deshalb gehen wir in den nächsten Abschnitten näher darauf ein. Wenn Sie wissen, dass Ihr Problem nicht in der Namensauflösung liegt, gehen Sie zum Abschnitt »Weitere Ressourcen« am Ende dieses Kapitels über.

Fehlersuche bei Namensdiensten

Dieser Abschnitt befasst sich mit der einfachen Fehlersuche bei allen Namensdiensten, auf die Sie treffen, allerdings beschränkt auf die Aspekte, die für Samba relevant sind.

Es gibt verschiedene gute Referenzen, die auf bestimmte Namensdienste eingehen: Paul Albitz' und Cricket Lius' Buch DNS und Bind (O'Reilly) behandelt das DNS, Hal Sterns NFS und NIS (O'Reilly) geht auf NIS (»Yellow Pages«) ein, während der Windows Internet Name Service (WINS), hosts/LMHOSTS-Dateien und NIS+ am besten in den Handbüchern der jeweiligen Hersteller betrachtet werden.

In diesem Abschnitt werden folgende Probleme untersucht:

Den verwendeten Namensdienst identifizieren

Prüfen Sie zunächst, ob sowohl Server als auch Client DNS, WINS, NIS oder die hosts-Datei verwenden, um IP-Adressen herauszufinden, wenn Sie einen Namen vorgeben. Jede Art von System geht anders vor:

Wir empfehlen Ihnen, die Client-Systeme für die Verwendung von WINS und DNS zu konfigurieren, die Samba-Daemons für WINS und DNS und den Unix-Server für DNS, die hosts-Dateien und vielleicht NIS+. Sehen Sie sich Ihre Aufzeichnungen und die gegenwärtige Konfiguration an, um festzustellen, welche Namensdienste Ihre Computer verwenden.

Auf den Clients werden die Namensdienste im Fenster Eigenschaften von TCP/IP der Netzwerk-Systemsteuerung eingestellt, wie in Kapitel 3 besprochen. Prüfen Sie, welche Dienste Sie hier aktiviert haben. Schauen Sie auf dem Server nach, ob die Datei /etc/resolv.conf existiert. Wenn dies der Fall ist, verwendet er DNS. Unabhängig davon kann er auf andere Namensdienste zugreifen. Schauen Sie nach, ob der Server NIS oder eine Kombination anderer Namensdienste benutzt.

Suchen Sie unter Solaris und anderen System V Unix-Betriebssystemen nach einer /etc/nsswitch.conf-Datei. Wenn Sie sie gefunden haben, suchen Sie dort nach einer Zeile, die mit host: beginnt, gefolgt von einem oder mehreren der Einträge files, bind, nis oder nis+. Dies sind die zu verwendenden Namensdienste in der Reihenfolge ihrer Benutzung; zusätzliche Optionen stehen in eckigen Klammern. Das Schlüsselwort files deutet auf HOSTS-Dateien hin, während bind (der Berkeley Internet Name Daemon) sich auf das DNS bezieht.

Wenn Client und Server unterschiedliche Dienste verwenden, müssen Sie die Systeme in Einklang bringen. Clients können ausschließlich DNS, WINS, die Dateien HOSTS und LMHOSTS, aber nicht NIS oder NIS+ verwenden. Servers können die Dateien HOSTS und LMHOSTS, DNS, NIS oder NIS+ sowie winbind einsetzen, aber nicht WINS - selbst wenn Ihr Samba-Server WINS-Dienste bereitstellt. Wenn Sie nicht von allen Systemen auf dieselben Dienste zugreifen können, müssen Sie sorgsam überprüfen, dass Server und Clients dieselben Daten erhalten.

Außerdem können Sie die Option -R (Resolve Order; Auswertungsreihenfolge) für smbclient benutzen. Wollen Sie beispielsweise Probleme mit WINS beheben, müssen Sie angeben: 

$ smbclient -L server -R wins

Die möglichen Einstellungen sind hosts (womit gemeint ist, was das Unix-System verwendet, nicht nur /etc/hosts), lmhosts, wins und bcast (Broadcast).

In den folgenden Abschnitten verwenden wir den Begriff langer Name als Synonym für einen voll qualifizierten Domainnamen (Fully-Qualified Domain Name, FQDN) wie server.example.com . Der Begriff kurzer Name steht für den Host-Teil des FQDN, beispielsweise server.

Hostnamen können nicht ausgewertet werden

Versuchen Sie Folgendes:

Bei DNS
Führen Sie nslookup name aus. Schlägt dies fehl, suchen Sie nach einem resolv.conf-Fehler, einem ausgefallenen DNS-Server oder einem Problem mit langen/kurzen Namen (siehe nächster Abschnitt). Versuchen Sie es damit:
- Ihre /etc/resolv.conf-Datei sollte eine oder mehrere nameserver-Zeilen enthalten, jeweils mit einer IP-Adresse. Dies sind die Adressen Ihrer DNS-Server.
- Sprechen Sie alle Server-Adressen, die Sie finden können, mit ping an. Schlägt dies für eine Adresse fehl, ist dieses System möglicherweise das Problem. Schlägt es für alle Adressen fehl, untersuchen Sie das Netzwerk.
- Versuchen Sie erneut die Auswertung mit dem vollständigen Domainnamen (zum Beispiel server.example.com), wenn Sie zuerst nur den kurzen Namen benutzt hatten, oder verwenden Sie umgekehrt den kurzen Namen, wenn Sie zuerst den langen Namen hatten. Erhalten Sie unterschiedliche Ergebnisse, gehen Sie zum nächsten Abschnitt über.
Bei Broadcast/ WINS
Broadcast/ WINS verwenden nur kurze Namen, wie zum Beispiel server, und keine langen Namen, wie server.example.com. Geben Sie nmblookup -S server ein. Die Ausgabe meldet alle Objekte, die durch Broadcast für diesen Namen registriert wurden. In unserem Fall sieht die Ausgabe so aus:
$ nmblookup -S server
 
Looking up status of 192.168.236.86
 
received 10 names
 
        SERVER           <00> -         M <ACTIVE> 
 
        SERVER           <03> -         M <ACTIVE> 
 
        SERVER           <1f> -         M <ACTIVE> 
 
        SERVER           <20> -         M <ACTIVE> 
 
        .._ _MSBROWSE_ _.     <01> - <GROUP> M <ACTIVE> 
 
        MYGROUP          <00> - <GROUP> M <ACTIVE> 
 
        MYGROUP          <1b> -         M <ACTIVE> 
 
        MYGROUP          <1c> - <GROUP> M <ACTIVE> 
 
        MYGROUP          <1d> -         M <ACTIVE> 
 
        MYGROUP          <1e> - <GROUP> M <ACTIVE>
Der gesuchte Eintrag ist SERVER <00>, der server als NetBIOS-Name des Computers kennzeichnet. Sie sollten außerdem den Namen Ihrer Arbeitsgruppe wenigstens einmal sehen. Wenn diese Zeilen fehlen, können Broadcast/WINS nicht zur Namensauswertung verwendet werden, Sie müssen diesen Punkt näher untersuchen.

Die Zahlen in spitzen Klammern der soeben beschriebenen Ausgabe identifizieren NetBIOS-Namen als Namen von Arbeitsgruppen, Workstations und Benutzern des Nachrichtendiensts, Hauptsuchdiensten, Domänen-Hauptsuchdiensten, Domänen-Controllern und diverser anderer Elemente. Wir interessieren uns hauptsächlich für <00> als Computer- und Arbeitsgruppenname sowie für <20> als Server-Name. Die vollständige Liste der Typen finden Sie unter http://support.microsoft.com/support/kb/ articles/q163/4/09.asp.
Bei NIS
Geben Sie ypmatch name hosts ein. Wenn dies nicht klappt, ist NIS nicht aktiv. Finden Sie den Namen des NIS-Servers heraus, indem Sie ypwhich ausführen; versuchen Sie den Server mittels ping zu erreichen.
Bei NIS+
Wenn Sie NIS+ einsetzen, geben Sie nismatch name hosts ein. Erhalten Sie kein Ergebnis, ist NIS+ nicht aktiv. Finden Sie den Namen des NIS+-Servers heraus, indem Sie niswhich ausführen; versuchen Sie den Server mittels ping zu erreichen.
Bei den Dateien hosts und HOSTS
Sehen Sie sich die Datei HOSTS auf dem Client (C:\Windows\ Hosts unter Windows 95/98/Me und C:\WINNT \system32\drivers\etc\hosts unter Windows NT/2000/XP) an. Jede Zeile sollte eine IP-Adresse und einen oder mehrere Namen enthalten (als Erstes den primären Namen, danach optionale Alias-Namen). Hier ein Beispiel:
127.0.0.1         localhost
 
192.168.236.1     dns.svc.example.com 
 
192.168.236.10    client.example.com client 
 
192.168.236.11    backup.example.com loghost 
 
192.168.236.86    server.example.com server 
 
192.168.236.254   router.svc.example.com
Unter Unix sollte localhost immer 127.0.0.1 sein, obwohl dies auch nur ein Alias für einen Hostnamen auf dem PC sein könnte. Prüfen Sie auf dem Client, dass es keine #XXX-Anweisungen an den Zeilenenden gibt; dies sind LAN Manager/NetBIOS-Anweisungen, die nur in LMHOSTS-Dateien auftauchen dürfen.
Bei LMHOSTS-Dateien
Diese Datei ist eine lokale Quelle für LAN Manager-(NetBIOS-)Namen. Ihr Format ist ähnlich den hosts-Dateien, allerdings unterstützt sie keine langen Domainnamen (z.B. server.example.com) und kann eine Reihe optionaler #XXX-Anweisungen nach den NetBIOS-Namen aufweisen. Üblicherweise gibt es eine lmhosts.sam (für Beispiel) in C:\Windows unter Windows 95/98/Me und in C:\WINNT\system32\drivers\etc unter Windows NT/2000/XP, allerdings wird diese Datei erst benutzt, wenn sie im gleichen Verzeichnis in Lmhosts umbenannt wird.
Lange und kurze Hostnamen

Wenn die lange (FQDN) Form eines Hostnamens funktioniert, die kurze jedoch nicht (beispielsweise client.example.com funktioniert, client nicht), betrachten Sie Folgendes:

Bei DNS
Dieser Fehler weist normalerweise auf das Fehlen einer Standard-Domain hin, in der die kurzen Namen nachgesehen werden. Suchen Sie in der Datei /etc/resolv.conf auf dem Samba-Server nach der Zeile default mit Ihrem Domainnamen. Alternativ kann dort auch die Zeile search mit mehreren Domainnamen stehen. Eine dieser Zeilen muss existieren, damit Sie kurze Namen verwenden können. Welche dies ist, hängt vom Anbieter und der Version Ihres DNS-Resolvers ab. Fügen Sie versuchsweise die Zeile domain ihre_domain in der Datei resolv.conf ein und fragen Sie Ihren Netzwerk- oder DNS-Administrator, welcher Eintrag sich in der Datei befinden sollte.
Bei Broadcast/WINS
Broadcast/WINS unterstützt keine langen Namen; dieses Problem tritt hier nicht auf.
Bei NIS
Geben Sie ypmatch hostname hosts ein. Wenn Sie keine Übereinstimmung sehen, unterstützen Ihre Tabellen keine kurzen Namen. Sprechen Sie mit Ihrem Netzwerkverwalter; es kann ein Versehen sein, dass Sie keine kurze Namen verwenden können - oder es ist Teil der Richtlinien Ihres Unternehmens. Einige Netzwerke verwenden niemals kurze Namen, da sie nicht eindeutig sind.
Bei NIS+
Versuchen Sie nismatch hostname hosts. Behandeln Sie einen Fehler genau wie bei NIS.
hosts
Wenn sich der kurze Name nicht in der Datei /etc/hosts befindet, können Sie ihn als Alias-Namen hinzufügen. Vermeiden Sie nach Möglichkeit kurze Namen als primäre Namen (der erste Name in einer Zeile). Geben Sie kurze Namen als Alias-Namen an, wenn Ihr System dies unterstützt.
LMHOSTS
LAN Manager unterstützt keine langen Namen; dieses Problem tritt hier nicht auf.

Wenn andererseits die kurze Form des Namens funktioniert, die lange jedoch nicht, untersuchen Sie Folgendes:

Bei DNS
Das ist eigenartig; sprechen Sie mit Ihrem Netzwerk- oder DNS-Administrator, da es sich vermutlich um einen Fehler bei der Einrichtung des DNS handelt.
Bei Broadcast/WINS
Dies ist normal; Broadcast/WINS kann die lange Form nicht verwenden. Probieren Sie alternativ DNS. (Microsoft hat mitgeteilt, dass man irgendwann ganz auf DNS umsteigt, obwohl DNS Namenstypen wie <00> nicht unterstützt.)
Bei NIS
Wenn Sie mit ypmatch nur die kurze Form eines Namens auswerten können, sollten Sie der Tabelle die lange Form zumindest als Alias hinzufügen.
Bei NIS+
Wie bei NIS, allerdings verwenden Sie hier nismatch an Stelle von ypmatch.
hosts und HOSTS
Tragen Sie den langen Namen ein, vorzugsweise als primären Namen oder wenigstens als Alias-Namen. Sie können auch DNS verwenden, wenn dies für Sie in Betracht kommt.
LMHOSTS
Dies ist normal. LAN Manager kann die lange Form nicht benutzen; steigen Sie eventuell auf DNS oder hosts um.
Ungewöhnliche Verzögerungen

Wenn es eine lange Verzögerung gibt, bevor das erwartete Ergebnis eintrifft:

Bei DNS
Geben Sie den gleichen Namen mit dem Befehl nslookup auf dem langsamen Computer (Client oder Server) ein. Wenn nslookup ebenfalls langsam ist, handelt es sich um ein DNS-Problem. Wenn es nur auf dem Client langsam ist, haben Sie möglicherweise zu viele Transportprotokolle installiert und an die Ethernet-Karte gebunden. Entfernen Sie das langsame Protokoll NetBEUI und optional Novell - sofern Sie diese Protokolle nicht benötigen. Dies ist besonders bei Windows 95 wichtig, da dieses Betriebssystem sehr empfindlich reagiert, wenn Sie nicht benötigte Protokolle installieren.
Bei Broadcast/ WINS
Testen Sie den Client mit nmblookup; ist dies schneller, haben Sie möglicherweise das gerade erwähnte Protokollproblem.
Bei NIS
Versuchen Sie ypmatch; ist dies langsam, teilen Sie das Ihrem Netzwerkverwalter mit.
Bei NIS+
Versuchen Sie nismatch, ansonsten siehe NIS.
hosts und HOSTS
Die hosts-Dateien sind immer schnell - wenn sie eine vernünftige Größe haben. Sie haben vermutlich das beim Punkt DNS erwähnte Protokollproblem.
lmhosts und LMHOSTS
Dies ist kein Problem der Namensauswertung; LMHOSTS-Dateien sind so schnell wie die Dateien hosts und HOSTS.
Probleme mit Localhost

Wenn ein Localhost nicht 127.0.0.1 ist, versuchen Sie Folgendes:

Bei DNS
Es gibt möglicherweise keinen Eintrag für localhost. A 127.0.0.1. Sorgen Sie dafür, dass einer angelegt wird, ebenso der Reverse-Record, 1.0.0.127.IN-ADDR.ARPA PTR 127.0.0.1.
Bei Broadcast/WINS
Entfällt.
NIS
Wenn localhost nicht in der Tabelle steht, fügen sie es hinzu.
NIS+
Wenn localhost nicht in der Tabelle steht, fügen sie es hinzu.
hosts und HOSTS
Fügen Sie die Zeile 127.0.0.1 localhost hinzu.
LMHOSTS
Entfällt.

Fehlersuche bei Netzwerkadressen

Zahlreiche verbreitete Probleme sind auf inkorrektes Routing von Internet-Adressen oder auf falsche Adresszuweisungen zurückzuführen. Dieser Abschnitt hilft Ihnen herauszufinden, wie Ihre Adressen lauten.

Netzmasken

Die Netzmasken sagen jedem Host, welche Adressen er direkt erreichen kann (diese Adressen befinden sich im selben lokalen Netzwerk oder Subnetz) und für welche Adressen er einen Router ansprechen muss. Wenn die Netzmasken falsch sind, machen Ihre Computer einen von zwei möglichen Fehlern. Sie versuchen, Pakete mit lokalem Ziel über einen Router auszuliefern, was normalerweise Zeitverschwendung ist - abhängig von diversen Faktoren kann dieses Verfahren einigermaßen schnell arbeiten, ziemlich langsam oder gar nicht. Der andere Fehler besteht in dem Versuch, Pakete für einen Host in einem anderen Netzwerk lokal auszuliefern, was nicht funktionieren kann; die Pakete werden ihr Ziel nie erreichen.

Die Netzmaske ist wie eine IP-Adresse aufgebaut. Sie besteht aus eingeschalteten Bits für den Netzwerkteil der Adresse und aus ausgeschalteten Bits für den Host-Teil. Sie wird als Bit-Maske verwendet, um Teile der Adresse im TCP/IP-Code zu maskieren, also zu verbergen. Eine Maske von 255.255.0.0 bedeutet, dass die ersten 2 Bytes (16 Bits) den Netzwerkanteil und die restlichen 2 Bytes (16 Bits) den Host-Anteil repräsentieren. Sie werden häufig auf die Maske 255.255.255.0 treffen, bei der der Netzwerkanteil aus 3 Bytes (24 Bits) und der Host-Anteil aus einem Byte (8 Bits) besteht.

Lassen Sie uns für unser Beispiel annehmen, dass Ihre IP-Adresse 192.168.0.10 lautet, während der Samba-Server die Adresse 192.168.236.86 besitzt. Bei einer Netzmaske von 255.255.255.0 besteht der Netzwerkanteil der IP-Adresse aus den ersten drei Bytes (24 Bits) und der Host-Anteil aus dem verbleibenden Byte (8 Bits). In diesem Fall befinden sich die beiden Systeme in unterschiedlichen Netzwerken:

Netzwerkanteil
Host-Anteil
192 168 000
10
192 168 235
86

Bei einer Netzwerkmaske von 255.255.0.0 besteht der Netzwerkanteil der IP-Adressen aus den ersten beiden Bytes. Da diese bei den beiden von uns verwendeten IP-Adressen übereinstimmen, befinden sich die Computer im selben Netzwerk:

Netzwerkanteil
Host-Anteil
192 168
000 10
192 168
236 86

Achten Sie darauf, dass die verwendeten Netzmasken bei den einzelnen Systemen der Struktur Ihres Netzwerks entsprechen. In einem Subnetz müssen die Netzmasken auf allen Systemen identisch sein.

Broadcast-Adressen

Die Broadcast-Adresse ist eine gewöhnliche Adresse, bei der der Host-Anteil ausschließlich aus eingeschalteten Bits besteht. Sie bedeutet »alle Hosts in Ihrem Netzwerk«. Sie können sie leicht ausrechnen, wenn Sie die Netzmaske und die IP-Adresse kennen: Nehmen Sie die Adresse und aktivieren Sie alle Bits, wenn die entsprechenden Bits in der Netzmaske auf null stehen (der Host-Anteil). Die folgende Tabelle veranschaulicht dies:

 
Netzwerkanteil
Host-Anteil
IP-Adresse
192 168 236
86
Netzmaske
255 255 255
000
Broadcast
192 168 236
255

In diesem Beispiel ist 192.168.236.255 die Broadcast-Adresse des Netzwerks 192.168.236. Es gibt außerdem eine alte, »universelle« Broadcast-Adresse, nämlich 255.255.255.255. Router dürfen diese Adresse nicht weiterleiten, aber die meisten Hosts in Ihrem Netzwerk werden auf Broadcast-Nachrichten mit dieser Zieladresse antworten.

Netzwerkadressbereiche

Mehrere Adressbereiche des Internets wurden für Testzwecke und für nicht mit dem Internet verbundene Netzwerke reserviert. Wir verwenden einen davon in unserem Buch. Wenn Sie noch keinen eigenen IP-Adressraum besitzen, können Sie den gleichen wie wir verwenden. Die Adressbereiche enthalten ein großes Netzwerk, 10.*.*.*, als Klasse-A-Netzwerk, einen Bereich mit Klasse-B-Netzwerkadressen, 172.16.*.* bis 172.31.*.*, und 254 Klasse-C-Netzwerke, 192.168.1.* bis 192.168.254.*. Die Domain example.com ist ebenfalls für nicht verbundene Netzwerke, Beispiele und Bücher reserviert.

Wenn Ihr Netzwerk mit dem Internet verbunden ist, benötigen Sie eine entsprechende IP-Adresse und einen Domainnamen. Wenden Sie sich dazu am besten an Ihren Internet-Provider.

Ihre Netzwerkadresse ermitteln

Falls Sie Ihre IP-Adresse nicht kennen, können Sie sie mit dem Befehl ifconfig unter Unix bzw. ipconfig unter Windows ermitteln. (Schauen Sie in den Manpages nach, ob Ihre spezielle Unix-Variante besondere Optionen erfordert. Beispielsweise will Solaris ifconfig -a sehen.) Die Ausgabe sieht in etwa so aus: 

$ ifconfig -a 
 
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING > 
 
      inet 192.168.236.11 netmask ffffff00 broadcast 192.168.236.255 
 
lo0: flags=49<&lt>UP,LOOPBACK,RUNNING<&gt> 		
 
      inet 127.0.0.1 netmask ff000000

Eine der Schnittstellen ist die Loopback-Schnittstelle (in unseren Beispielen lo0), und die andere ist die normale IP-Schnittstelle. Die Flags sollten signalisieren, dass die Schnittstelle in Betrieb ist, Ethernet-Schnittstellen müssten außerdem bekannt geben, dass sie Broadcasts unterstützen (was PPP-Schnittstellen nicht tun). Sie können auch an anderen Stellen nach IP-Adressen suchen: in /etc/hosts-Dateien, Windows-HOSTS-Dateien, Windows-LMHOSTS-Dateien, NIS, NIS+ und DNS.

Fehlersuche bei NetBIOS-Namen

Die SMB-Protokolle haben von Anfang an das NetBIOS-Namenssystem genutzt. Es ist auch unter der Bezeichnung LAN Manager-Namenssystem bekannt. Dabei handelt es sich um ein einfaches Verfahren, bei dem jeder Knoten einen Namen mit 20 Zeichen Länge besitzt, der per Broadcast im Netzwerk herumgeschickt wird, so dass jeder andere Knoten davon weiß. Bei TCP/IP tendieren wir dazu, Namen wie client.example.com über DNS oder WINS zu verwenden, die in der Datei /etc/hosts gespeichert sind.

Die übliche Zuordnung von Domainnamen wie server.example.com zu NetBIOS-Namen benutzt einfach server als NetBIOS-Namen und konvertiert ihn in Großbuchstaben. Leider funktioniert dieses Verfahren nicht immer, besonders wenn Ihr Computer einen Host-Namen mit mehr als 20 Zeichen besitzt. Nicht bei jedem Rechner sind NetBIOS- und DNS-Namen identisch. So ist es nicht ungewöhnlich, für einen Computer den NetBIOS-Namen corpvm1 zu verwenden, wenn er den Hostnamen vm1.corp.com besitzt.

Computer, bei denen sich NetBIOS- und Hostnamen unterscheiden, können bei der Fehlersuche für Verwirrung sorgen. Wir empfehlen Ihnen daher, diese Konstellation zu vermeiden, wo immer Sie können. Sie können NetBIOS-Namen mit smbclient   herausfinden:

Weitere Ressourcen

Irgendwann im Laufe Ihrer Arbeit mit Samba werden Sie zu dem Punkt kommen, an dem Sie weitere Informationen über die Software haben wollen, und zwar sowohl in gedruckter als auch in elektronischer Form, um Neuigkeiten zu lesen, um etwas über Aktualisierungen zu erfahren oder um Hilfe zu bekommen.

Dokumentation und FAQs

Es ist völlig in Ordnung, die Dokumentation zu lesen. Wirklich. Niemand kann Sie dabei sehen, und wir erzählen auch niemandem davon. Samba wird mit zahlreichen Dateien zur Dokumentation geliefert, und sie sind es wert, zumindest überflogen zu werden. Sie finden sie im Distributionsverzeichnis Ihres Computers unter /docs oder im Internet auf der Samba-Website: http://www.samba.org. Dort befindet sich die neueste Version der FAQ (Frequently Asked Questions; häufig gestellte Fragen), Fehlerinformationen und Hinweise zu den Distributionen, außerdem Links auf alle Samba-Manpages und HOWTO-Anleitungen.

Samba-Newsgroups

Usenet-Newsgroups waren schon immer ein guter Ort, um Ratschläge zu bekommen, über welches Thema auch immer. In den letzten Jahren hat sich dieser große Informationspool zu einer Ressource von unschätzbarem Wert gewandelt, zu einem Wissensspeicher. Archiv- und Such-Sites wie Google (http://www.google.de/advanced_group_ search) haben die Artikel der Newsgroups gespeichert und stellen nach einigen Mausklicks wertvolle Lösungen für Probleme bereit.

Die wichtigste Newsgroup für Samba ist comp.protocols.smb. Sie sollte Ihre erste Adresse werden, wenn Sie ein Problem haben. Meist können Ihnen fünf Minuten der Suche hier stundenlange Frustration ersparen, die Ihre Fehlersuche auf eigene Faust begleiten kann.

Wenn Sie eine Newsgroup durchsuchen, machen Sie so genaue Angaben wie möglich, aber fomulieren Sie knapp. Das Suchen nach einer bestimmten Fehlermeldung ist das Beste, wenn Sie die Antwort nicht sofort finden. Widerstehen Sie der Versuchung, nach Hilfe zu fragen, solange Sie nicht eine gewisse Zeit lang selbst gesucht haben. Vielleicht finden Sie die Antwort auf Ihre Frage in einer FAQ oder in einer der vielen Dokumentationsdateien, die mit Samba geliefert werden. Oder Sie kommen auf die Lösung, indem Sie eines der Diagnosewerkzeuge von Samba benutzen. Wenn dies nicht funktioniert, stellen Sie Ihre Frage in comp.protocols.smb und beschreiben dabei genau, was Sie versucht haben und wie Ihr Ergebnis aussieht. Schreiben Sie die Fehlermeldungen in die Frage. Es kann einige Tage dauern, bevor Sie Hilfe bekommen, seien Sie also bitte geduldig und versuchen Sie bis zur Antwort weiter, das Problem selbst zu lösen.


Suchen Sie selbst weiter nach einer Lösung, nachdem Sie die Frage gestellt haben. Die meisten von uns haben die Erfahrung gemacht, dass sie eine Frage mit hunderten von Zeilen mit Einzelheiten über mehrere Kontinente geschickt haben, nur um nach einer Stunde das Problem selbst zu lösen. Die Faustregel lautet etwa so: Je mehr Menschen Ihre Frage lesen, umso einfacher ist die Lösung. Das bedeutet, wenn jeder in der Unix-Gemeinschaft Ihren Artikel einmal gelesen hat, ist die Lösung so einfach wie: »Stecken Sie den Stecker in die Steckdose!«

Samba-Mailinglisten

Die folgenden Mailinglisten bieten Unterstützung für Samba. Auf der Samba-Homepage unter http://www.samba.org/ erfahren Sie, wie Sie sich an diesen Mailinglisten an- und abmelden:

samba@samba.org
Dies ist die wichtigste Mailingliste für allgemeine Fragen und Diskussionen über Samba.
samba-announce@samba.org
Diese Liste ist für Neuigkeiten Samba betreffend zuständig, wie etwa die Ankündigung neuer Versionen.
samba-cvs@samba.org
Wenn Sie sich an dieser Liste anmelden, erhalten Sie jedes Mal eine Nachricht, wenn einer der Samba-Entwickler den Samba-Quellcode im CVS-Repository aktualisiert. Sie könnten diese Möglichkeit nutzen, wenn Sie auf einen bestimmten Bugfix oder die Umsetzung einer bestimmten Funktion warten. Um zu vermeiden, dass Ihre Mailbox von Nachrichten überschwemmt wird, empfehlen wir Ihnen, die Digest-Funktion zu nutzen, die Nachrichten in einer geringeren Anzahl von E-Mails zusammenfasst.
samba-docs@samba.org
Diese Liste dient den Diskussionen der Samba-Dokumentation.
samba-vms@samba.org
Diese Mailingliste ist für alle, die Samba auf dem Betriebssystem VMS betreiben.
samba-binaries@samba.org
Dies ist eine Liste für Entwickler, die über vorkompilierte Samba-Distributionen diskutieren wollen.
samba-technical@samba.org
Diese Mailingliste ist für Diskussionen der Entwickler über den Samba-Code.

Durchsuchbare Versionen der Samba-Mailinglisten-Archive finden Sie unter http://marc. theaimsgroup.com.

Wenn Sie eine Nachricht an die Samba-Mailinglisten schicken, sollten Sie immer daran denken, dass Sie diese Nachricht an ein großes Publikum richten. Die Hinweise aus dem vorherigen Abschnitt bezüglich der Usenet-Postings gelten auch hier. Eine gut formulierte Frage oder ein entsprechender Kommentar wird höchstwahrscheinlich beantwortet - eine unausgereifte Nachricht dagegen wird wohl mit Nichtbeachtung bestraft werden!

Weitere Informationsquellen

Hunt, Craig. TCP/IP-Netzwerk-Administration, 3. Auflage. Köln, O'Reilly Verlag, 2003.
Hunt, Craig und Robert Bruce Thompson. Windows NT TCP/IP Netzwerk-Administration. Köln, O'Reilly Verlag, 1999.
Albitz, Paul und Cricket Liu. DNS und BIND, 3. Auflage. Köln, O'Reilly Verlag, 2001.
Stern, Hal. Managing NFS and NIS, 2nd Edition. Sebastopol, CA, O'Reilly & Associates, 2001.
TOC PREV NEXT INDEX
Copyright © 2003 by O'Reilly Verlag GmbH & Co.KG