[Kapitel 9] 9.2 Der Fehlerbaum

9.2 Der Fehlerbaum

Der Fehlerbaum gehört für die Diagnose und Reparaturprobleme, die auftreten, wenn du Samba installierst und umkonfigurierst. Er ist eine erweiterte Form eines Dokuments für Schwierigkeiten und Diagnose, das Teil der Samba-Distribution ist.

Bevor du aufbrichst, um Schwierigkeiten in irgendeinem Teil der Samba-Suite zu bekämpfen, solltest du die folgenden Informationen wissen:

Deine Client-IP-Adresse (wir nehmen 192.168.236.10)
Deine Server-IP-Adresse (wir nehmen 192.168.236.86)
Die Netzmaske für dein Netzwerk (typischerweise 255.255.255.0)
Ob alle Maschinen im selben Subnetz sind (unsere sind es)

Wegen der Klarheit haben wir unseren Server in den folgenden Beispielen in server.example.com und die Client-Maschine in client.example.com umbenannt.

9.2.1 Wie man den Fehlerbaum verwendet

Beginne die Tests hier, ohne vorwärts zu hüpfen, es wird nicht lange dauern (ungefähr fünf Minuten) und könnte dir eigentlich Zeit sichern, denselben Weg zurückzugehen. Wann immer ein Test gelingt, erhältst du den Namen eines Abschnitts und eine Seitennummer, wohin du ungefährdet springen kannst.

9.2.2 Troubleshooting der Low-Level IP

Die erste Serie Tests ist die der Low-Level-Dienste, die Samba braucht, um zu arbeiten. Die Tests in diesem Abschnitt werden das überprüfen:

Die IP-Software arbeitet
Die Ethernet-Hardware arbeitet
Der grundlegende Name-Service ist an der richtigen Stelle

Spätere Abschnitte werden TCP-Software, die Samba-Dämonen smbd und nmbd, Host-basierte Zugriffskontrolle, Authentifikation und Zugriffskontrolle durch User, Dateidienste und Browsing beitragen. Die Tests werden in beachtlicher Genauigkeit beschrieben, damit sie von technisch orientierten Endusern und von erfahrenen System- und Netzwerk-Administratoren verstanden werden.

9.2.2.1 Testen der Netzwerk-Software mit ping

Das erste Kommando, das an Server und Client eingegeben wird, ist ping 127.0.0.1. Das ist die loopback address, und sie auszutesten zeigt an, ob Netzwerkunterstützung überhaupt funktioniert. Unter Unix kannst du ping 127.0.0.1 mit der Statistik-Option verwenden und es nach einigen Zeilen unterbrechen. Auf Sun-Arbeitsstationen ist der Befehl üblicherweise /usr/etc/ping -s 127.0.0.1; unter Linux nur ping 127.0.0.1. Auf Windows-Clients führst du ping 127.0.0.1 in einem MS-DOS-Fenster aus, und es stoppt von selbst nach vier Zeilen.

Hier ist ein Beispiel auf einem Linux-Server:

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 du "ping: no answer from..." oder "100% packet loss" bekommst, hast du überhaupt kein IP-Netzwerk auf der Maschine installiert. Die Adresse 127.0.0.1 ist die interne Loopback-Adresse und hängt nicht davon ab, ob der Computer physikalisch mit einem Netzwerk verbunden ist. Wenn dieser Test fehlschlägt, hast du ein ernstes lokales Problem. TCP/IP ist entweder nicht installiert oder erheblich schlecht konfiguriert. Schau in deine Betriebssystem-Dokumentation, wenn es ein Unixserver ist. Ist es ein Windows-Client, dann folge den Anweisungen in Kapitel 3, Windows-Clients konfigurieren, zur Installation der Netzwerkunterstützung.

Wenn du der Netzwerk-Manager bist, sind gute Referenzen Craig Hunt's TCP/IP Network Administration, Kapitel 11, und Craig Hunt & Robert Bruce Thompson's neues Buch, Windows NT TCP/IP Network Administration, beide von O'Reilly herausgegeben.

9.2.2.2 Testen der lokalen Name-Services mit ping

Als Nächstes versuche localhost auf dem Sambaserver zu pingen. localhost ist der konventionelle Hostname für das 127.0.0.1 Loopback, und es sollte nach dieser Adresse aufgelöst werden. Nach der Eingabe von ping localhost solltest du eine Ausgabe ähnlich der folgenden sehen:

server% 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

Sollte das Erfolg zeitigen, versuche denselben Test auf dem Client. Andernfalls:

Wenn du "unknown host: localhost" bekommst, gibt es ein Problem mit der Auflösung des Hostnamens "localhost" in eine gültige IP-Adresse. (Das mag einfach ein fehlender Eintrag in einer lokalen hosts-Datei sein.) Spring von hier hinunter zum Abschnitt 9.2.8, Troubleshooting bei Name-Services.
Wenn du "ping: no answer" oder "100% packet loss" bekommst, aber das Pingen von 127.0.0.1 funktioniert, dann löst der Name-Service in eine Adresse auf, aber es ist nicht die richtige. Überprüfe die Datei oder die Datenbank (üblicherweise /etc/hosts auf einem Unixsystem), die der Name-Service zum Auflösen der Adressen verwendet, um die Korrektur des Eintrages sicherzustellen.

9.2.2.3 Testen der Netzwerk-Hardware mit ping

Pinge als Nächstes die Netzwerk-IP-Adresse des Servers von ihm selbst aus. Davon solltest du dieselben Resultate bekommen wie bei ping 127.0.0.1:

server% 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 das auf dem Server funktioniert, wiederhole es für den Client. Andernfalls:

Falls ping network_ip auf dem Server oder auf dem Client fehlschlägt, jedoch ping 127.0.0.1 auf dieser Maschine funktioniert, hast du ein TCP/IP-Problem, das spezifisch an der Ethernet-Netzwerkkarte im Computer liegt. Überprüfe mit der Dokumentation zur Netzwerkkarte oder für das Betriebssystem des Hosts, wie die Konfiguration korrekt erfolgt. Nun, du sollst wissen, dass auf einigen Betriebssystemen das ping-Kommando zu funktionieren scheint, selbst wenn das Netzwerk getrennt ist, also dieser Test nicht immer alle Hardwareprobleme diagnostiziert.

9.2.2.4 Testen der Verbindungen mit ping

Nun pinge den Server per Namen (statt unter seiner IP-Adresse), einmal vom Server und einmal vom Client. Das ist der allgemeine Test für das Funktionieren der Netzwerk-Hardware:

server% 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

Unter Microsoft Windows würde ein Anpingen des Servers aussehen wie in Figur 9.1.

Figur 9.1: Den Sambaserver von einem Windows-Client aus pingen

Wenn dieser Test erfolgreich verläuft, informiert er uns über fünf Dinge:

Der Hostname (z.B. "server") wird von deinem lokalen Nameserver gefunden.
Der Hostname wurde zum vollen Namen erweitert (z.B. server.example.com).
Seine Adresse wird zurückgemeldet (192.168.236.86).
Der Client hat dem Sambaserver vier 56-Byte-UDP/IP-Pakete gesendet.
Der Sambaserver hat auf alle vier Pakete geantwortet.

Wenn dieser Test nicht erfolgreich ist, kann eines von mehreren Dingen beim Netzwerk nicht stimmen:

Erstens, wenn du "ping: no answer" oder "100% packet loss" bekommst, bist du nicht mit dem Netzwerk verbunden, die andere Maschine hat keine Verbindung oder eine der Adressen ist falsch. Prüfe die Adressen, die der ping-Befehl auf jeder Maschine meldet und stell sicher, dass sie mit denen übereinstimmen, die du anfänglich eingerichtet hast.
Wenn nicht, gibt es mindestens eine nicht passende Adresse zwischen den beiden Maschinen. Versuch die Eingabe des Befehls arp -a und schau, ob es einen Eintrag für die andere Maschine gibt. Der arp-Befehl steht für das Address Resolution Protocol. Der Befehl arp -a listet die ganzen Adressen auf, die bei der lokalen Maschine bekannt sind. Hier sind einige Dinge, die du versuchen kannst:
Wenn du eine Meldung wie "192.168.236.86 at (incomplete)" bekommst, ist die Ethernet-Adresse 192.168.236.86 unbekannt. Das deutet auf einen kompletten Mangel in der Verbindung hin, und du hast wahrscheinlich ein Problem, das dem TCP/IP-Netzwerk Administrations-Protokollstack beim Ethernet-Interface-Layer zu Grunde liegt. Das wird in den Kapiteln 5 und 6 des Buches TCP/IP Network Administration (O'Reilly) diskutiert.
Wenn du eine Antwort ähnlich wie "server (192.168.236.86) at 8:0:20:12:7c:94" bekommst, dann wurde der Server nach einiger Zeit erreicht oder eine andere Maschine antwortet in seinem Namen. Nun, das bedeutet, dass ping funktioniert haben sollte: du könntest ein periodisches Netzwerk- oder ARP-Problem haben.
Wenn die IP-Adresse vom ARP nicht mit der Adresse übereinstimmt, die du erwartest, forsche nach und korrigiere die Adresse manuell.
Wenn jede Maschine sich selbst aber keine andere anpingen kann, ist etwas im Netzwerk zwischen ihnen falsch.
Wenn du "ping: network unreachable" oder "ICMP Host Unreachable" erhältst, dann bekommst du keine Antwort, und es ist wahrscheinlich mehr als ein Netzwerk beteiligt.
Im Prinzip solltest du nicht versuchen, SMB-Clients und -Server auf verschiedenen Netzwerken zu "troubleshooten". Versuche Server und Client auf demselben Netzwerk zu testen. Die folgenden drei Tests setzen voraus, dass du zwischen zwei Netzwerken testen könntest:
Führ als Erstes die Tests für keine Antwort durch, die weiter oben in diesem Abschnitt beschrieben werden. Wenn dies das Problem nicht identifiziert, sind die verbleibenden Möglichkeiten folgende: eine Adresse ist falsch, deine Netzmaske ist falsch, ein Netzwerk ist niedergefahren oder du wurdest vielleicht nur von einer Firewall gestoppt.
Überprüfe die Adressen und die Netzmasken auf den Quell- und Ziel-Maschinen, um zu sehen, ob etwas offensichtlich falsch ist. Unter der Annahme, beide Maschinen seien wirklich im selben Netzwerk, sollten sie beide dieselben Netzmasken haben, und ping sollte die richtigen Adressen melden. Sind die Adressen falsch, dann musst du sie berichtigen. Wenn sie richtig sind, könnten die Programme durch eine unkorrekte Netzmaske verwirrt sein. Siehe Abschnitt 9.2.9.1, Netzmasken, später in diesem Kapitel.
Wenn die Befehle noch immer melden, dass das Netzwerk unerreichbar ist und keine der zwei vorherigen Bedingungen fehlerhaft ist, könnte wirklich ein Netzwerk vom anderen unerreichbar sein. Das ist auch eine Angelegenheit des Netzwerk-Managers.
Wenn du "ICMP Administratively Prohibited" bekommst, bist du auf eine Firewall irgendeiner Sorte oder auf einen schlecht konfigurierten Router gestoßen. Da musst du mit deinem Netzwerk-Sicherheitsverwalter sprechen.
Bekommst du "ICMP Host redirect" und ping meldet durchkommende Pakete, so ist das gewöhnlich harmlos: du wirst einfach über das Netzwerk zurückgeroutet.
Wenn du ein Host redirect bekommst und kein ping antwortet, wird dir nachgesendet, aber keiner antwortet. Behandle das wie die Antwort "Network unreachable" und überprüfe deine Adressen und Netzmasken.
Wenn du "ICMP Host Unreachable from gateway gateway_name" bekommst, werden die Ping-Pakete in ein anderes Netzwerk geroutet, aber die andere Maschine antwortet nicht, und der Router meldet das Problem in deren Auftrag. Behandle das ebenfalls wie die Antwort "Network unreachable" und beginne die Überprüfung der Adressen und Netzmasken.
Wenn du "ping: unknown host hostname" bekommst, ist dein Maschinennname nicht bekannt. Das deutet auf ein Name-Serviceproblem hin, das nicht localhost betraf. Wirf einen Blick auf Abschnitt 9.2.8 später in diesem Kapitel.
Wenn du einen Teilerfolg erreichst, bei dem manche Pings fehlschlagen, aber andere Erfolg haben, hast du entweder ein periodisches Problem zwischen den Maschinen oder ein überlastetes Netzwerk. Pinge längere Zeit und schau, ob mehr als 3 Prozent der Pakete fehlgehen. Ist das so, dann überprüfe es mit deinem Netzwerk-Manager: ein Problem könnte nur das Starten sein. Nun, wenn nur ein paar fehlschlagen oder wenn du weißt, dass eine Menge Netzwerkprogramme laufen, dann sorge dich nicht übermäßig. Ping's ICMP (und UDP) sind für das Verwerfen gelegentlicher Pakete vorgesehen.
Wenn du eine Antwort wie "smtsvr.antares.net is alive" bekommst, wenn du eigentlich client.example.com angepingt hast, verwendest du entweder die Adresse jemand anderes oder die Maschine hat mehrere Namen und Adressen. Wenn die Adresse falsch ist, ist der Name-Service offensichtlich der Übertäter; du wirst die Adresse in der Name-Service-Datenbank ändern müssen, damit sie auf die richtige Maschine verweist. Das wird in Abschnitt 9.2.8, später in diesem Kapitel, besprochen.
Server-Maschinen sind oft multihomed : mit mehr als einem Netzwerk verbunden, mit unterschiedlichen Namen auf jedem Netz. Wenn du auf einem multihomed Server eine Antwort von einem unerwarteten Namen bekommst, suche die Adresse und schau, ob sie auf deinem Netzwerk ist (siehe den Abschnitt 9.2.9.1 später in diesem Kapitel). Ist das der Fall, solltest du aus Gründen der Performance und der Zuverlässigkeit lieber diese Adresse verwenden als eine von einem anderen Netzwerk.
Server können ebenso mehrere Namen für eine einzelne Ethernet-Adresse besitzen, besonders wenn sie Webserver sind. Das ist ungefährlich, wenn auch überraschend. Du willst wahrscheinlich den offiziellen (und permanenten) Namen lieber verwenden als einen anderen, der sich ändern kann.
Wenn alles funktioniert, aber die gemeldete Adresse ist 127.0.0.1, dann hast du einen Name-Service-Fehler. Das tritt typischerweise dann auf, wenn ein Installationsprogramm eines Betriebssystems in der /etc/hosts eine Zeile ähnlich wie 127.0.0.1 localhost hostnamedomainname erzeugt. Die Localhost-Zeile sollte 127.0.0.1 localhost oder 127.0.0.1 localhost loghost heißen. Bessere sie aus, damit sie nicht Fehlschläge beim Aushandeln verursacht, wer der Inhaber der Master-Browseliste und wer der Master-Browser ist. Sie kann auch (zweideutige) Fehler in späteren Tests verursachen.

Wenn das vom Server aus funktioniert, wiederhole es vom Client aus.

9.2.3 Troubleshooting von TCP

Nachdem du nun IP, UDP und ein Name-Service mit ping getestet hast, ist es Zeit, TCP zu testen. Ping und Browsing verwenden ICMP und UDP; Datei- und Druckerdienste (Shares) verwenden TCP. Beide hängen von IP als eine untere Ebene ab und alle vier verlassen sich auf die Name-Services. TCP testen geschieht am zweckmäßigsten unter Verwendung des FTP- (File Transfer Protocol) Programms.

9.2.3.1 TCP mit FTP testen

Versuch eine Verbindung via FTP, einmal vom Server zu sich selbst und einmal vom Client zum Server:

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.

Wenn das funktioniert, spring zum Abschnitt 9.2.4, Troubleshooting der Server-Dämonen. Sonst:

Erhältst du die Meldung "server: unknown host", dann ist das Nameservice fehlgeschlagen. Geh zurück zum entsprechenden ping-Schritt, Abschnitt 9.2.2.2, Testen der lokalen Name-Services mit ping , und wiederhole diese Tests, um herauszufinden, warum die Namenssuche fehlschlägt.
Wenn du "ftp: connect: Connection refused" erhalten hast, läuft auf der Maschine kein FTP-Dämon. Das ist eher unüblich auf Unix-Servern. Du könntest diesen Test auf Wunsch versuchen, indem du bei der Maschine mit Telnet anstatt mit FTP einloggst; die Meldungen sind sehr ähnlich, und Telnet verwendet ebenfalls TCP.
Wenn es eine lange Pause gab, "ftp: connect: Connection timed out", dann ist die Maschine nicht erreichbar. Geh zurück zum Abschnitt 9.2.2.4, Testen der Verbindungen mit ping.
Wenn du "530 Logon Incorrect" erhieltst, war deine Verbindung erfolgreich, aber du hast ein anderes Problem herausgefunden. Du hast wahrscheinlich einen unkorrekten Usernamen oder ein ungeeignetes Passwort vorgesehen. Versuch es noch einmal und stell sicher, dass du deinen Usernamen vom Unix-Server verwendest und dein Passwort korrekt eingibst.

9.2.4 Troubleshooting der Server-Dämonen

Hast du einmal festgestellt, dass das Netzwerk mit TCP einwandfrei funktioniert, ist der nächste Schritt sicherzustellen, dass die Dämonen auf dem Server laufen. Das erfordert drei einzelne Tests, weil kein einziger der nachfolgenden entscheidend beweist, dass sie korrekt arbeiten.

Damit du die Gewissheit hast, dass sie laufen, musst du herausfinden, ob:

der Dämon gestartet ist
die Dämonen durch das Betriebssystem an einen TCP/IP-Port angemeldet oder gebunden sind
sie wirklich Aufmerksamkeit schenken

9.2.4.1 Bevor du beginnst

Prüfe zuerst die Logdateien. Wenn du die Dämonen gestartet hast, sollte die Meldung "smbd version some_number started" vorkommen. Wenn nicht, dann musst du die Samba-Dämonen erneut starten.

Wenn der Dämon meldet, dass er bereits gestartet ist, suche nach "bind failed on port 139 socket_addr=0 (Address already in use)". Dies bedeutet, ein anderer Dämon wurde auf dem Port 139 (smbd) gestartet. Auch nmbd meldet einen ähnlichen Fehler, wenn er nicht an den Port 137 gebunden werden kann. Entweder hast du sie doppelt gestartet, oder der inetd-Server hat versucht, einen Dämon für dich bereitzustellen. Ist es das Letztere, werden wir das in einem Moment diagnostizieren.

9.2.4.2 Dämonen-Prozesse suchen mit ps

Als Nächstes musst du nachschauen, ob die Dämonen gestartet wurden. Benütze den Befehl ps auf dem Server mit der Option long für deinen Maschinentyp (meistens ps ax oder ps -ef) und schau, ob du beide, smbd und nmbd, wirklich laufen hast. Das sieht oft wie das Folgende aus:

server% ps ax

 PID TTY STAT TIME   COMMAND
 1   ?   S    0:03   init [2] 
 2   ?   SW   0:00   (kflushd)

(...viele Prozess-Zeilen...) 
 234 ?   S    0:14   nmbd -D3
 237 ?   S    0:11   smbd -D3

(...mehr Zeilen, vielleicht mehr smbd-Zeilen enthaltend...)

Dieses Beispiel illustriert, dass smbd und nmbd bereits als stand-alone Dämonen (die Option -D) auf Log-Level 3 gestartet sind.

9.2.4.3 Suche nach an Ports gebundene Dämonen

Als Nächstes müssen die Dämonen beim Betriebssystem angemeldet werden, damit können sie auf TCP/IP-Ports Zugriff erlangen. Der Befehl netstat sagt dir, ob dies geschehen ist. Führe den Befehl netstat -a auf dem Server aus und suche Zeilen, die netbios, 137 oder 139 erwähnen:

server% netstat -a

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

oder:

server% 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

Unter vielen ähnlichen Zeilen sollte mindestens eine UDP-Zeile für *.netbios- oder *.137 vorkommen. Das zeigt an, dass der nmbd-Server angemeldet ist und (hoffentlich) wartet, um Anfragen zu beantworten. Es sollte auch wenigstens eine TCP-Zeile mit der Anmerkung *.netbios- oder *.139 geben, und sie wird wahrscheinlich im Status LISTENING sein. Das bedeutet, dass smbd bereit ist und auf Verbindungen horcht.

Es kann andere TCP-Zeilen geben, die Verbindungen von smbd zu Clients enthalten, eine für jeden Client. Diese sind gewöhnlich im Zustand ESTABLISHED. Wenn es smbd-Zeilen im Status ESTABLISHED gibt, läuft smbd definitiv. Wenn es nur eine Zeile im Status LISTENING gibt, sind wir noch nicht sicher. Wenn beide Zeilen fehlen, ist einem Dämon der Start nicht gelungen, also ist es Zeit, die Logdateien zu kontrollieren und dann zu Kapitel 2 zurückzukehren.

Gibt es eine Zeile für jeden Client, kann sie entweder von einem Samba-Dämon oder vom Master-IP-Dämon inetd kommen. Es ist durchaus möglich, dass deine inetd-Startdatei Zeilen enthält, die Samba-Dämonen starten, ohne dass du es bemerkst; die Zeilen können z.B. hier angelegt worden sein, wenn du Samba als Teil einer Linux-Distribution installiert hast. Die von inetd gestarteten Dämonen hindern unsere daran zu laufen. Dieses Problem erzeugt typischerweise Log-Messages wie "bind failed on port 139 socket_addr=0 (Address already in use)."

Überprüfe deine /etc/inetd.conf ; außer wenn du absichtlich die Dämonen von hier aus startest, es müssen nicht irgendwelche netbios-ns (UDP-Port 137) oder netbios-ssn (TCP-Port 139)-Server hier erwähnt werden. Inetd ist ein Dämon, der zahlreiche Dienste anbietet und von Einträgen in der /etc/inetd.conf kontrolliert wird. Wenn dein System einen SMB-Dämon via inetd zur Verfügung stellt, gibt es Zeilen wie die folgenden in der Datei:

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

9.2.4.4 Smbd mit telnet überprüfen

Der leichteste Weg zu testen, dass der smbd-Server wirklich arbeitet, ist paradoxerweise, ihm eine sinnlose Meldung zu schicken und zu sehen, ob er sie ablehnt. Versuche so etwas wie das Folgende:

echo hello | telnet localhost 139

Dies sendet eine unrichtige aber harmlose Meldung an smbd. Die Meldung hello ist wichtig. Versuch kein telnet zu dem Port und dabei irgendetwas zu schreiben, sonst wirst du wahrscheinlich deinen Prozess "aufhängen". hello jedoch ist im Allgemeinen eine harmlose Meldung.

server% echo "hello" | telnet localhost 139

Trying
Trying 192.168.236.86 ... 
Connected to localhost. Escape character is '^]'. 
Connection closed by foreign host.

Wenn du eine "Connected"-Meldung bekommst, gefolgt von einer "Connection closed"-Meldung, dann war der Test ein Erfolg. Du hast einen smbd-Dämon, der auf dem Port horcht und unpassende Verbindungs-Meldungen ablehnt. Wenn du andererseits "telnet: connect: Connection refused" bekommst, ist wahrscheinlich kein Dämon vorhanden. Überprüfe die Logdateien und kehre zum Kapitel 2 zurück.

Es gibt leider keinen einfachen Test für nmbd. Wenn der telnet-Test und der netstat-Test sagen, dass ein smbd läuft, dann gibt es eine gute Chance, dass netstat auch über das Funktionieren von nmbd korrekt berichtet.

9.2.4.5 Dämonen mit testparm testen

Wenn du einmal weißt, dass ein Dämon existiert, solltest du immer testparm durchführen, in der Hoffnung, Folgendes zu bekommen:

server% 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 über die Verarbeitung einer Reihe von Sektionen und antwortet mit "Loaded services file OK", wenn es gelingt. Wenn nicht, berichtet es mit einer oder mehreren der folgenden Meldungen, die auch in den Logdateien wie beschrieben aufscheinen:

"Allow/Deny connection from account (n) to service": Eine nur- testparm Meldung, erzeugt, wenn du gültige/ungültige User-Optionen in deiner smb.conf gesetzt hast. Du willst sicherstellen, dass du auf der gültigen Userliste stehst und dass Root, bin usw. auf der ungültigen Userliste sind. Wenn du das nicht tust, vermagst du dich nicht anzumelden, oder Leute, die nicht dazu fähig werden sollten.
"Warning: You have some share names that are longer than eight chars": Für jeden, der Windows für Workgroups und ältere Clients verwendet. Sie werden bei der Verbindung zu Shares mit langen Namen scheitern, dabei eine Überlauf-Meldung produzieren, die verwirrend wie ein Speicherüberlauf klingt.
"Warning: [name] service MUST be printable!": Einer Drucker-Share fehlt die Option printable = yes.
"No path in service name using [name]": Eine File-Share weiß nicht, welches Verzeichnis dem User bereitgestellt werden muss, oder eine Drucker-Share weiß nicht, welches Spool-Verzeichnis benützt werden soll. Wenn kein Pfad festgelegt ist, wird der Dienst versuchen, mit dem Pfad von /tmp zu arbeiten, der nicht das sein kann, was du willst.
"Note: Servicename is flagged unavailable": Bloß eine Gedächtnisstütze, dass du die Option available = no in einer Share verwendet hast.
"Can't find include file [name]": Eine Konfigurationsdatei, auf die durch eine include-Option verwiesen wird, existierte nicht. Wenn du die Datei bedingungslos inkludiert hast, ist das ein Fehler und wahrscheinlich ein ernster dazu: die Share hat nicht die von dir beabsichtigte Konfiguration. Wenn du sie auf Grund einer der % Variablen wie %a (Architekture) eingeschlossen hast, wirst du entscheiden müssen, ob z.B. eine fehlende Windows für Workgroups-Konfigurationsdatei ein Problem ist. Es ist es oft nicht.
"Can't copy service name, unable to copy to itself": Du hast versucht, eine smb.conf-Sektion auf sich selbst zu kopieren.
"Unable to copy service - source not found: [name]": Weist auf eine fehlende oder falsch geschriebene Sektion in einer copy = Option hin.
"Ignoring unknown parameter name": Deutet typischerweise auf eine veraltete, falsch geschriebene oder nicht unterstützte Option hin.
"Global parameter name found in service section": Bedeutet, dass ein nur globaler Parameter in einer Einzel-Share verwendet wurde. Samba ignoriert den Parameter.

Nach dem Test testparm wiederhole ihn mit (genau) drei Parametern: dem Namen deiner smb.conf-Datei, dem Namen deines Clients und seiner IP-Adresse:

testparm samba_directory/lib/smb.conf client 192.168.236.10

Dies führt noch einen Test durch, der den Hostnamen und die Adresse gegenüber host allow und host deny-Optionen überprüft, und kann "Allow/Deny connection from account account_name" zu einer Service-Meldung für die Client-Maschine produzieren. Diese Meldung zeigt, dass du gültige/ungültige Host-Optionen in deiner smb.conf hast und sie den Zugriff von der Client-Maschine verbieten. Die Eingabe von testparm /usr/local/lib/experimental.conf ist ebenfalls ein wirksamer Weg, eine experimentelle smb.conf-Datei zu testen, bevor man sie im Normalbetrieb einsetzt.

9.2.5 Troubleshooting von SMB-Verbindungen

Nachdem du jetzt weißt, dass die Server hochgefahren sind, musst du dich vergewissern, dass sie ordentlich laufen. Wir beginnen mit der Datei smb.conf im Verzeichnis samba_directory /lib.

9.2.5.1 Eine minimale smb.conf-Datei

In den folgenden Tests nehmen wir an, du hättest eine zum Testen geeignete Share [temp] plus mindestens einen Account. Eine smb.conf-Datei, die gerade das enthält, ist:

[global] 
    workgroup = 

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

Eine warnende Bemerkung: die Option public = yes in der Share [temp] gehört nur für den Test. Du wirst wahrscheinlich keine Leute ohne Accounts wollen, die Dinge auf deinem Sambaserver speichern dürfen, also solltest du sie auskommentieren, sobald du fertig bist.

9.2.5.2 Lokal testen mit smbclient

Der erste Test ist, sicherzustellen, dass der Server seine eigenen Dienste (Shares) auflisten kann. Führe den Befehl smbclient mit einer Option -L des localhost aus, um sich bei sich selbst anzumelden, und mit einer Option -U, gefolgt von %, um den Gast-User festzulegen. Du solltest Folgendes sehen:

server% smbclient -L localhost -U% 
Server time is Wed May 27 17:57:40 1998 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 du diese Ausgabe bekommen hast, geh weiter zum nächsten Test, Abschnitt 9.2.5.3, Verbindungen testen mit smbclient. Wenn du andererseits einen Fehler bekommst, überprüfe Folgendes:

Wenn du "Get_hostbyname: unknown host localhost" bekommst, hast du entweder seinen Namen falsch geschrieben oder es gibt wirklich ein Problem (welches im Abschnitt 9.2.2.2 nachgesehen werden sollte). Im letzteren Fall geh zu "Troubleshooting der Name Services."
Wenn du "Connect error: Connection refused" bekommst, wurde die Server-Maschine gefunden, aber es lief kein nmbd-Dämon. Spring zurück zum Abschnitt 9.2.4 und teste die Dämonen noch einmal.
Wenn du die Meldung "Your server software is being unfriendly" bekommst, erhielt das Initial-Anfrage-Paket der Sitzung eine "Müll"-Antwort vom Server. Der Sever kann gestört oder falsch gestartet sein. Die üblichen Gründe dafür können beim Durchsuchen der Logdateien entdeckt werden:
- Ungültige Kommandozeilen-Parameter bei smbd; lies die smbd-Manual-Page.
- Ein fatales Problem bei der Datei smb.conf, das den Start von smbd verhindert. Prüfe immer deine Änderungen, wie es im Abschnitt 9.2.4.5, Dämonen mit testparm testen, geschah.
- Die Verzeichnisse fehlen, wo Samba seine Log- und Lock-Dateien aufbewahrt.
- Es gibt schon einen Server auf dem Port (139 für smbd, 137 für nmbd ), der ihn beim Starten hindert.
Wenn du inetd anstatt Stand-alone-Dämonen verwendest, prüfe auch deine Einträge in /etc/inetd.conf und /etc/services gegenüber deren Manual-Pages auf Fehler.
Wenn du einen Password:-Prompt bekommst, ist dein Gast-Account nicht ordentlich eingerichtet. Die Option %U weist smbclient an, ein "null login" durchzuführen, was erfordert, dass der Gast-Account vorhanden ist, aber ihn nicht braucht, um irgendwelche Privilegien zu besitzen.
Wenn du die Meldung "SMBtconX failed. ERRSRV - ERRaccess" bekommst, darfst du auf den Server nicht zugreifen. Das bedeutet normalerweise, dass du eine Option valid hosts hast, die den Server nicht einschließt, oder eine Option invalid hosts, die das tut. Mach eine nochmalige Überprüfung mit dem Befehl testparm smb.conf your_hostname your_ip_address (siehe Abschnitt 9.2.4.5) und korrigiere alle unabsichtlichen Verbote.

9.2.5.3 Verbindungen testen mit smbclient

Führ das Kommando smbclient\\server\temp aus, das sich auf der /tmp-Share deines Servers anmeldet, um zu sehen, ob du dich mit einem Datei-Service verbinden kannst. Du solltest die folgende Antwort bekommen:

server% smbclient '\\server\temp'

Server time is Tue May  5 09:49:32 1998 Timezone is UTC-4.0 Password:

smb:\> quit

Wenn du "Get_Hostbyname: Unknown host name", "Connect error: Connection refused" oder "Your server software is being unfriendly" bekommst, dann schau im Abschnitt 9.2.5.2, Lokal testen mit smbclient, wegen der Diagnose nach.
Wenn du die Meldung "servertemp: Not enough `\' characters in service" bekommst, hast du vielleicht die Adresse nicht unter Anführungszeichen gesetzt, also entfernte Unix die Backslashes. Du kannst den Befehl auch so schreiben:

smbclient \\\\server\\temp

oder:

smbclient //server/temp

Gib nun dein Passwort für den Unix-Account beim Password-Prompt ein. Wenn du dann einen smb\>-Prompt erhältst, funktioniert es. Gib quit ein und setz fort in Abschnitt 9.2.5.4, Verbindungen testen mit NET USE. Wenn du dann "SMBtconX failed. ERRSRV - ERRinvnetname" bekommst, kann das Problem eines der folgenden sein:

Ein falscher Sharename: du kannst ihn falsch geschrieben haben, er mag zu lang sein, er kann mit Groß- und Kleinbuchstaben geschrieben worden sein oder er kann nicht verfügbar sein. Überprüfe, ob es das ist, was du vermutest, mit testparm (siehe Abschnitt 9.2.4.5.)
security = share, worin du -U your_account zum smbclient-Befehl ergänzen oder das Passwort eines Unix-Accounts namens temp wissen müsstest.
Ein unrichtiger Username.
Ein unrichtiges Passwort.
Eine Option invalid users oder valid users in deiner smb.conf-Datei, die deinem Account keine Verbindung gestattet. Überprüfe noch einmal mit testparm smb.conf your_hostname your_ip_address (siehe Abschnitt 9.2.4.5).
Eine Option valid hosts, die den Server nicht mit einschließt, oder eine Option invalid hosts, die das tut. Teste das ebenfalls mit testparm.
Ein Problem in der Authentifikation, so wie Shadow-Passwörter, oder das PAM (Password Authentication Module) wird auf dem Server verwendet, aber Samba ist nicht für seine Verwendung kompiliert. Das ist selten, passiert aber gelegentlich, wenn eine SunOS 4 Samba-Binary (keine Shadow-Passwörter) ohne Rekompilation auf einem Solaris-System läuft (mit Shadow-Passwörtern).
Die Option encrypted passwords = yes in der Konfigurationsdatei, aber kein Passwort für deinen Account in der Datei smbpasswd.
Du hast einen ungültigen Passwort-Eintrag, entweder im Unix /etc/passwd oder in der Datei smbpasswd.
Du hast dich bei [temp] angemeldet und hast keine Option guest ok = yes in der Sektion [temp] der Datei smb.conf.
Du hast dich bei [temp] angemeldet, bevor du mit deinem Home-Verzeichnis verbunden warst, und dein Gast-Account ist nicht korrekt eingerichtet. Ob du dich mit deinem Home-Verzeichnis verbinden kannst und dich dann mit [temp] verbindest, das ist das Problem. Siehe Kapitel 2 für mehr Information bezüglich Einrichtung einer grundlegenden Samba-Konfigurationsdatei.
Ein schlechter Gast-Account hindert dich ebenfalls am Drucken oder Browsen bis nach deinem Einloggen in dein Home-Verzeichnis.

Es gibt noch einen Grund für diesen Fehler, der überhaupt nichts mit Passwörtern zu tun hat: die path =-Zeile in deiner smb.conf-Datei kann auf irgendeinen Ort zeigen, der nicht existiert. Das wird von testparm nicht diagnostiziert, und die meisten SMB-Clients können es nicht von anderen Typen von gestörten User-Accounts unterscheiden. Du musst das manuell prüfen.

Hast du dich einmal erfolgreich bei [temp] angemeldet, wiederhole den Test, indem du diesmal in dein Home-Verzeichnis einloggst (z.B. Netzlaufwerk verbinden server\davecb) und währenddessen nach Fehlern suchst. Wenn du etwas verändern musst, damit das funktioniert, teste [temp] nachher noch einmal.

9.2.5.4 Verbindungen testen mit NET USE

Führe den Befehl net use * \server\temp auf dem DOS oder Windows-Client aus, um zu sehen, ob er sich mit dem Server verbinden kann. Du solltest aufgefordert werden, ein Passwort einzugeben, dann die Antwort "The command was completed successfully" erhalten, siehe Figur 9.2.

Figur 9.2: Ergebnisse des NET USE-Befehls

Wenn das gelingt, setz fort mit den Schritten im Abschnitt 9.2.5.5, Verbindungen testen mit dem Windows Explorer. Andernfalls:

Wenn du "The specified shared directory cannot be found" oder "Cannot locate specified share name" bekommst, ist der Verzeichnisname entweder falsch geschrieben oder nicht in der Datei smb.conf. Diese Meldung kann auch vor einem Namen warnen, der aus Groß- und Kleinbuchstaben besteht und Leerzeichen enthält oder länger als acht Zeichen ist.
Wenn du "The computer name specified in the network path cannot be located" oder "Cannot locate specified computer" bekommst, wurde der Verzeichnisname falsch geschrieben, der Name-Service ist mißlungen, es gibt ein Netzwerk-Problem oder die Option hosts deny = enthält deinen Host.
- Wenn es kein Schreibfehler ist, musst du mindestens zum Abschnitt 9.2.5.3 zurückgehen, um herauszufinden, warum keine Anmeldung möglich ist.
- Wenn smbclient funktioniert, ist es ein Name-Service-Problem mit dem Client-Name-Service, und du musst zum Abschnitt 9.2.6.2, Den Server mit nmblookup testen, weitergehen und schauen, ob du Client und Server mit nmblookup untersuchen kannst.
Wenn du "The password is invalid for \server\username" bekommst, stimmt die lokal aufbewahrte Kopie auf dem Client nicht mit der auf dem Server überein. Du wirst zu einem Austausch aufgefordert werden.

Windows 95 und 98-Clients bewahren eine lokale Datei password auf, aber es ist in Wirklichkeit nur eine gespeicherte Kopie des Passworts, das an Samba und NT-Server gesendet wird, dich zu authentifizieren. Das ist es, was hier verlangt wird. Du kannst bei einer Windows-Maschine noch ohne ein Passwort einloggen (aber nicht bei NT).

Wenn du dein Passwort lieferst und es schlägt trotzdem fehl, findet es keine Übereinstimmung auf dem Server, du hast eine valid users oder invalid users-Liste, die dir Rechte verbietet, NetBEUI stört oder es existiert das Problem eines verschlüsselten Passworts, das im nächsten Paragraphen beschrieben wird.
Wenn dein Client NT 4.0, NT 3.5 mit Patch 3, Windows 95 mit Patch 3, Windows 98 oder irgendetwas von diesen mit Internet Explorer 4.0 ist, so sind diese voreingestellt, die Microsoft-Verschlüsselung von Passwörtern zu benützen (besprochen in Kapitel 6, User, Security und Domains, Abschnitt 6.4, Passwörter, zusammen mit den Alternativen). Im Allgemeinen, wenn du kürzlich ein älteres Microsoft-Produkt installiert hast, könntest du ein Update angewandt und verschlüsselte Passwörter eingeschaltet haben.

Wegen der Bereitschaft des Internet Explorers, URLs wie file://somehost/somefile durch das Herstellen von SMB-Verbindungen anzuerkennen, würden Clients bis einschließlich Windows 95, Patch Level 2, glücklicherweise dein Passwort im Klartext an SMB-Server irgendwo im Internet senden. Das war alles in allem eine schlechte Idee, und Microsoft wechselte ganz schnell zur alleinigen Verwendung von verschlüsselten Passwörtern im SMB-Protokoll. Alle folgenden Neuerscheinungen ihrer Produkte enthalten diese Korrektur. Verschlüsselte Passwörter braucht man nicht wirklich, außer du verwendest den Internet Explorer 4.0 ohne Firewall, also ist es vernünftig, weiter Klartext-Passwörter auf deinen eigenen Netzwerken zu verwenden.

Wenn du ein mixed-case Passwort unter Unix hast, sendet der Client es wahrscheinlich in Zeichen einer Sorte. Ob die Umwandlung zu Zeichen einer Sorte funktioniert, das war das Problem. Bedauerlicherweise unterstützen alle außer die ältesten Clients groß geschriebene Passwörter, also versucht Samba es einmal damit in Großbuchstaben und einmal in Kleinbuchstaben. Wenn du mixed-case Passwörter verwenden willst, schau dir die Option password level in Kapitel 6 zur Wiederholung an.
Du könntest ein Problem mit valid users haben, wie mit smbclient getestet (siehe Abschnitt 9.2.5.3).
Du könntest das NetBEUI-Protokoll an den Microsoft-Client gebunden haben. Das produziert oft lange Timeouts und unberechenbare Fehler und ist bekannt, dass es in der Vergangenheit Fehler bei der Akzeptanz von Passwörtern verursacht hat.

Der Ausdruck "binden" bedeutet in diesem Fall die Verbindung eines Teils der Software zu einem anderen. Der Microsoft SMB-Client ist "gebunden an" TCP/IP in der Sektion Bindings des TCP/IP Eigenschaften-Rahmens unter der Windows 95/98 Netzwerkumgebung in der Systemsteuerung. TCP/IP in der Liste ist an eine Ethernetkarte gebunden. Das ist nicht derselbe Wortsinn wie die Bindung eines SMB-Dämons an einen TCP/IP-Port.

9.2.5.5 Verbindungen testen mit dem Windows Explorer

Starte den Windows Explorer oder den NT-Explorer (nicht den Internet Explorer), wähle Extras→Netzlaufwerk verbinden und nenne \\server\temp, um zu sehen, ob du den Explorer mit dem Verzeichnis /tmp verbinden kannst. Du solltest einen Schirm ähnlich dem in Figur 9.3 sehen. Ist das so, dann warst du erfolgreich und kannst zum Abschnitt 9.2.6, Troubleshooting Browsing , springen.

Figur 9.3: Zugriff auf das Verzeichnis /tmp mit dem Windows Explorer

Ein warnendes Wort: Windows Explorer und NT Explorer sind ziemlich arm als Diagnose-Tools: sie melden dir, dass etwas nicht in Ordnung ist, aber selten was es ist. Wenn du einen Fehler entdeckst, musst du ihn mit dem Befehl NET USE herausfinden, der einen weit besseren Fehlerreport hat:

Wenn du "The password for this connection that is in your password file is no longer correct", bekommst, könntest du etwas vom Folgenden haben:
- Deine lokal auf dem Client aufbewahrte Kopie stimmt nicht mit der auf dem Server überein.
- Du hast beim Einloggen keinen Usernamen und kein Passwort auf dem Client vorgesehen. Die meisten Explorer senden andauernd einen ungültigen Usernamen und ein ungültiges Passwort, sogar wenn du ein Passwort vorsiehst.
- Du hast das Passwort falsch geschrieben.
- Du hast eine invalid users oder valid users-Liste, welche die Rechte verweigert.
- Dein Client ist NT 4.0, NT 3.5 mit Patch 3, Windows 95 mit Patch 3, Windows 98 oder eines von denen mit Internet Explorer 4. Die wollen alle verschlüsselte Passwörter.
- Du hast ein mixed-case Passwort, das der Client in einer Schreibart unterstützt.
Wenn du "The network name is either incorrect, or a network to which you do not have full access" oder "Cannot locate specified computer" bekommst, könntest du etwas vom Folgenden haben:
- Falsch geschriebener Name
- Schlecht funktionierender Service
- Fehlerhafte Share
- Netzwerkproblem
- Fehlerhafte path-Zeile
- hosts deny-Zeile, die dich ausschließt
Wenn du "You must supply a password to make this connection" bekommst, ist das Passwort auf dem Client nicht mit dem Server synchronisiert, oder das ist der erste Versuch von dieser Maschine und der Client hat es noch nicht lokal gespeichert.
Wenn du "Cannot locate specified share name" bekommst, hast du einen falschen Sharenamen oder einen Syntax-Fehler bei seiner Bezeichnung, einen Sharenamen länger als acht Zeichen oder einen, der Leerzeichen oder Groß- und Kleinbuchstaben enthält.

Kannst du dich einmal zuverlässig beim Verzeichnis [temp] anmelden, versuch es wieder einmal, diesmal verwendest du dein Home-Verzeichnis. Wenn du etwas verändern musst, damit Home-Verzeichnisse funktionieren, dann teste wieder mit [temp] und umgekehrt, wie wir im Abschnitt 9.2.5.4 zeigten. Wie immer, wenn der Explorer versagt, kehr zu diesem Abschnitt zurück und such hier nach Fehlern.

9.2.6 Troubleshooting beim Browsing

Zuletzt kommen wir zum Browsing. Das hoben wir für zuletzt auf, nicht weil es das Schwierigste ist, sondern weil es optional und zum Teil von einem Protokoll abhängig ist, das die Zustellung eines Pakets nicht garantiert. Browsing ist schwierig zu diagnostizieren, wenn du nicht schon alle anderen Dienste kennst, die da laufen.

Browsing ist rein optional: es ist bloß ein Weg, um die Server auf deinem Netz zu finden und die Shares, die sie bereitstellen. Unix hat nichts von der Sorte und macht es glücklicherweise ohne das. Browsing nimmt also an, alle deine Maschinen befinden sich in einem lokalen Netzwerk-Bereich (LAN), wo Broadcasts zulässig sind.

Als Erstes identifiziert der Browsing-Mechanismus eine Maschine, indem er das unzuverlässige UDP-Protokoll verwendet; dann stellt er eine normale (zuverlässige) TCP/IP-Verbindung her, um die Shares aufzulisten, welche die Maschine bietet.

9.2.6.1 Browsing testen mit smbclient

Wir beginnen zuerst mit dem Testen der zuverlässigen Verbindung. Versuche vom Server aus seine eigenen Shares via smbclient aufzulisten, mit einer Option -L vom Namen deines Servers. Du solltest erhalten:

server% 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 1998 Timezone is UTC-4.0 
Password: 
Domain=[EXAMPLE] 
OS=[Unix] 
Server=[Samba 1.9.18]
Server=[server] 
User=[davecb] 
Workgroup=[EXAMPLE] 
Domain=[EXAMPLE]
   Sharename      Type      Comment    
   ---------      ----      -------    
    cdrom          Disk      CD-ROM    
    cl             Printer   Color Printer 1    
    davecb         Disk      Home Directories

 This machine has a browse list:
   Server         Comment    
   ---------      -------    
   SERVER          Samba 1.9.18

 This machine has a workgroup list:
   Workgroup      Master    
    ---------      -------    
    EXAMPLE        SERVER

Wenn du keine Liste der Sharenamen erhalten hast, erlaubt dir der Server nicht, Shares zu browsen. Dies sollte nicht der Fall sein, wenn du irgendwelche Shares mit dem Windows Explorer oder dem NET USE-Befehl getestet hast. Wenn du den Test smbclient -L localhost -U% noch nicht durchgeführt hast (siehe Abschnitt 9.2.5.2), mach es jetzt. Ein unrichtiger Gast-Account kann die Shares daran hindern, gesehen zu werden. Überprüfe außerdem die Datei smb.conf, um sicherzugehen, dass du darin nicht irgendwo die Option browsable = no hast: wir schlagen eine minimale smb.conf-Datei vor (siehe Abschnitt 9.2.5.1, Eine minimale smb.conf-Datei), die du von dort stehlen kannst. Du musst browseable eingeschaltet haben, um wenigstens die Share [temp] sehen zu können.
Wenn du keine Browseliste erhältst, stellt der Server keine Information über die Maschinen auf dem Netzwerk zur Verfügung. Mindestens eine Maschine im Netz muss Browselisten unterstützen. Vergewissere dich, dass local master = yes in der smb.conf-Datei steht, wenn du Samba als Local Master Browser haben willst.
Wenn du eine Browseliste, aber nicht /tmp bekommst, hast du wahrscheinlich ein smb.conf-Problem. Geh zurück zu Abschnitt 9.2.4.5.
Wenn du keine Arbeitsgruppen-Liste mit deinem Arbeitsgruppen-Namen darin bekommst, ist es möglich, dass deine Arbeitsgruppe in der smb.conf-Datei unkorrekt eingerichtet ist.
Wenn du überhaupt keine Arbeitsgruppen-Liste bekommst, dann vergewissere dich, dass workgroup =EXAMPLE in der smb.conf-Datei vorkommt.
Wenn du nichts bekommst, versuch es noch einmal mit den Optionen -I ip_address -n netbios_name -W workgroup -d3, mit dem NetBIOS- und dem Arbeitsgruppen-Namen in Großbuchstaben. (Die Option -d 3 setzt den Log/Debugging-Level auf 3.)

Wenn du noch immer nichts bekommst, solltest du das nicht weit suchen müssen. Geh zumindest bis Abschnitt 9.2.3.1, TCP mit FTP testen , oder vielleicht Abschnitt 9.2.2.4 zurück. Ansonsten:

Wenn du "SMBtconX failed. ERRSRV - ERRaccess" bekommst, ist dir ein Zugriff auf den Server nicht erlaubt. Das bedeutet normalerweise, dass du eine valid hosts-Option hast, die den Server nicht einschließt, oder eine invalid hosts-Option, die das tut.
Wenn du "Bad password" bekommst, dann hast du vermutlich etwas folgender Art:
- Eine unkorrekte hosts allow oder hosts deny-Zeile
- Eine unkorrekte invalid users oder valid users-Zeile
- Ein Passwort in Kleinbuchstaben und OS/2 oder Windows für Workgroups-Clients
- Ein fehlender oder ungültiger Gast-Account
Prüfe, was dein Gast-Account ist (siehe Abschnitt 9.2.5.2) und prüfe deine smb.conf-Datei mit testparm smb.conf your_hostname your_ip_address (siehe Abschnitt 9.2.4.5) und ändere alle hosts allow, hosts deny, valid users oder invalid users-Zeilen oder kommentiere sie aus.
Wenn du "Connection refused" bekommst, läuft der smbd-Server nicht oder ist gestört. Überprüfe, ob er hochfährt, läuft und im Netzwerk horcht mit netstat, siehe Abschnitt 9.2.4.5.
Wenn du "Get_Hostbyname: Unknown host name" bekommst, ist dir ein Schreibfehler passiert, hier stimmen Unix- und NetBIOS-Hostname nicht überein, oder es gibt ein Nameservice-Problem. Starte das Debugging von Nameservice mit Abschnitt 9.2.5.4. Wenn das funktioniert, vermute einen nicht übereinstimmenden Namen und geh zu Abschnitt 9.2.10, Troubleshooting bei NetBIOS-Namen.
Wenn du "Session request failed" bekommst, lehnt der Server die Verbindung ab. Das deutet gewöhnlich auf einen internen Fehler hin, wie nicht genügend Speicher für einen Prozess.
Wenn du "Your server software is being unfriendly" bekommst, dann erhält das Anfragepaket der Initial-Session eine "Müllantwort" vom Server. Der Server kann abgestürzt oder falsch gestartet sein. Geh zurück zum Abschnitt 9.2.5.2, wo das Problem zuerst analysiert wurde.
Wenn du den Verdacht hast, dass der Server nicht läuft, geh zurück zum Abschnitt 9.2.4.2, Dämonen-Prozesse suchen mit ps, um nachzuschauen, warum der Server-Dämon nicht antwortet.

9.2.6.2 Den Server testen mit nmblookup

Dies testet das "Werbe"-System, das für Windows-Nameservices und -Browsing verwendet wird. Werbung funktioniert durch Broadcasting jemandes Gegenwart oder Bereitschaft, Dienste anzubieten. Das ist der Teil des Browsing, welcher ein unzuverlässiges Protokoll (UDP) verwendet, und funktioniert nur auf Broadcast-Netzwerken wie Ethernets. Das Programm nmblookup broadcastet Namens-Anfragen nach dem Hostnamen, den du zur Verfügung stellst, und gibt seine IP-Adresse und den Namen der Maschine zurück, vieles wie nslookup macht es mit DNS. Hier fragen die Option -d (Debug- oder Log-Level) und die Option -B (Broadcast-Adresse) direkt nach bestimmten Maschinen.

Zuerst prüfen wir den Server von ihm selbst aus. Starte nmblookup mit einer -B -Option deines Servers Namen, um ihm mitzuteilen, dass er die Anfrage zum Sambaserver sendet, und einem Parameter __SAMBA__ als den symbolischen Namen zum Nachschauen. Du solltest bekommen:

server% 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__

Du solltest die IP-Adresse des Servers bekommen, gefolgt vom Namen __SAMBA__, was bedeutet, dass der Server erfolgreich geworben hat, dass er ein Service namens __SAMBA__ hat, und daher mindestens ein Teil des NetBIOS-Nameservice arbeitet.

Wenn du "Name_query failed to find name __SAMBA__" bekommst, könntest du die falsche Adresse bei der Option -B angegeben haben, oder nmbd läuft nicht. Die Option -B holt eigentlich eine Broadcast-Adresse: wir verwenden einen Maschinennamen, um eine Unicast-Adresse zu bekommen und den Server zu fragen, ob er __SAMBA__ beansprucht hat.
Versuch es noch einmal mit -Bip_address, und wenn dies wieder fehlschlägt, beansprucht nmbd den Namen nicht. Geh kurz zu "Dämonen testen mit testparm", um nachzuschauen, ob nmbd läuft. Ist das so, dürfte er keine Namen beanspruchen; das bedeutet, dass Samba das Browsing-Service nicht bereitstellt - ein Konfigurationsproblem. Wenn das der Fall ist, stell sicher, dass smb.conf nicht die Option browsing = no enthält.

9.2.6.3 Den Client testen mit nmblookup

Als Nächstes überprüfe vom Server aus die IP-Adresse des Clients mit nmblookup und verwende die Option -B für den Namen des Clients und einen Parameter '*', der "irgendwas" bedeutet, wie man hier sieht:

server% 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)

Wenn du "Name-query failed to find name *" bekommst, hast du einen Schreibfehler gemacht, oder die Client-Software ist auf dem PC nicht installiert, nicht gestartet oder nicht an TCP/IP gebunden. Geh zurück zu Kapitel 2 oder Kapitel 3 und vergewissere dich, ob du einen Client installiert hast, der auf dem Netzwerk horcht.

Wiederhole den Befehl mit den folgenden Optionen, wenn du irgendwelche Fehler hattest:

Wenn nmblookup -B client_IP_address erfolgreich ist, aber -B client_name fehlschlägt, gibt es ein Nameservice-Problem mit dem Namen des Clients; geh zum Abschnitt 9.2.8.
Wenn nmblookup -B 127.0.0.1'*' erfolgreich ist, aber -B client_IP_address fehlschlägt, gibt es ein Hardware-Problem und ping sollte fehlgeschlagen sein. Frage deinen Netzwerk-Manager.

9.2.6.4 Das Netzwerk testen mit nmblookup

Ruf den Befehl nmblookup wieder mit einer Option -d (Debug-Level) 2 und einem Parameter '*' auf. Diesmal testen wir die Fähigkeit von Programmen (wie nmbd ), Broadcast zu benützen. Es ist notwendigerweise ein Verbindungs-Test, via Broadcast zur voreingestellten Broadcast-Adresse durchgeführt.

Eine Anzahl NetBIOS/TCP-IP-Hosts auf dem Netzwerk sollte mit "got a positive name query response"-Meldungen antworten. Samba dürfte nicht alle Antworten in der kurzen Zeit des Horchens auffangen, also wirst du nicht immer alle SMB-Clients auf dem Netzwerk sehen. Nun, du solltest die meisten von ihnen sehen:

server% 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 *

Also:

Wenn das nicht wenigstens die Client-Adresse liefert, die du vorher getestet hast, dann ist die voreingestellte Broadcast-Adresse falsch. Versuche nmblookup -B 255.255.255.255 -d 2 '*', was eine Last-Ditch-Variante ist (eine Broadcast-Adresse von allen). Wenn dies Antworten ausgibt, dann ist die von dir vorher benützte Broadcast-Adresse falsch. Das Troubleshooting darüber wird im Abschnitt 9.2.9.2, Broadcast-Adressen, später in diesem Kapitel, diskutiert.
Wenn die Adresse 255.255.255.255 auch fehlschlägt, prüfe deine Notizen, um zu schauen, ob dein PC und der Server auf verschiedenen Subnetzen liegen, wie im Abschnitt 9.2.2.4 festgestellt. Du solltest das mit einem Server und einem Client auf demselben Subnetz zu diagnostizieren versuchen, wenn es dir aber nicht möglich ist, kannst du versuchen, die Broadcast-Adresse des Remote-Subnetzes mit -B anzugeben. Das Auffinden dieser Adresse wird an derselben Stelle wie das Troubleshooting von Broadcast-Adressen diskutiert, im Abschnitt 9.2.9.2, später in diesem Kapitel. Die Option -B funktioniert, wenn dein Router direkte Broadcasts unterstützt; wenn er das nicht tut, könntest du gezwungen sein, mit einem Client auf demselben Netzwerk zu testen.

9.2.6.5 Client-Browsing testen mit net view

Rufe auf dem Client den Befehl net view \\server in einem DOS-Fenster auf, um zu sehen, ob du eine Verbindung zum Client bekommst und fragen kannst, welche Shares er bereitstellt. Du solltest eine Liste verfügbarer Shares auf dem Server zurückbekommen, siehe Figur 9.4.

Figur 9.4: Verwendung des Befehls net view

Wenn du das erhältst, setz fort mit dem Abschnitt 9.2.7, Andere Dinge, die fehlschlagen.

Wenn du für den Namen, den du gerade im Abschnitt 9.2.6.3, Den Client testen mit nmblookup, getestet hast, "Network name not found" bekommst, gibt es ein Problem mit der Client-Software selbst. Prüf das noch einmal mit dem Aufruf von nmblookup auf dem Client; wenn das funktioniert und NET VIEW nicht, dann trägt der Client die Schuld.
Wenn natürlich nmblookup fehlschlägt, gibt es ein NetBIOS-Nameservice-Problem, wie im Abschnitt 9.2.10 besprochen.
Wenn du "You do not have the necessary access rights" oder "This server is not configured to list shared resources" bekommst, ist entweder dein Gast-Account falsch konfiguriert (siehe Abschnitt 9.2.5.2), oder du hast eine hosts allow oder hosts deny-Zeile, die Verbindungen von deiner Maschine aus verbietet. Diese Probleme sollten von den smbclient-Tests entdeckt worden sein. Diese Tests beginnen im Abschnitt 9.2.6.1, Browsing testen mit smbclient.
Wenn du "The specified computer is not receiving requests" bekommst, hast du den Namen falsch geschrieben, die Maschine ist durch Broadcast nicht erreichbar (getestet in "Das Netzwerk testen mit nmblookup") oder es läuft kein nmbd.
Wenn du "Bad password error" bekommst, hast du wahrscheinlich mit dem Microsoft-Problem des verschlüsselten Passworts zu tun, wie in Kapitel 6 mit seinen Korrekturen besprochen.

9.2.6.6 Den Server vom Client aus browsen

Versuche von der Netzwerkumgebung aus (Datei-Manager in älteren Ausgaben) den Server zu browsen. Dein Sambaserver sollte in der Browse-Liste deiner lokalen Arbeitsgruppe erscheinen. Du solltest auf dem Namen des Servers doppelklicken können und eine Liste von Shares erhalten, wie in Figur 9.5 gezeigt.

Figur 9.5: Liste von Shares auf einem Server

Wenn du einen "Invalid password"-Fehler bei NT 4.0, NT 3.5 mit Patch 3, Windows 95 mit Patch 3, Windows 98 oder irgendetwas davon mit Internet Explorer 4.0 bekommst, ist es wahrscheinlich meistens wieder das Verschlüsselungsproblem. Alle diese Clients sind auf die Verwendung der Microsoft-Verschlüsselung von Passwörtern voreingestellt (siehe Kapitel 6).
Wenn du einen "Unable to browse the network"-Fehler erhältst, ist eine von folgenden Möglichkeiten geschehen:
- Du hast zu früh nachgeschaut, bevor die Broadcasts und die Updates fertig waren; warte 30 Sekunden, ehe du es wieder versuchst.
- Es gibt ein Netzwerkproblem, das du noch nicht diagnostiziert hast.
- Es gibt keinen Master-Browser. Ergänze die Konfigurations-Option local master = yes in deiner smb.conf-Datei.
- Keine Shares sind browsable markiert in der Datei smb.conf.
Wenn du die Meldung "\\server is not accessible" erhältst, dann:
- Hast du das Problem mit dem verschlüsselten Passwort
- Ist die Maschine wirklich nicht erreichbar
- Unterstützt die Maschine Browsing nicht

9.2.7 Andere Dinge, die fehlschlagen

Wenn du es bis hier geschafft hast, ist entweder das Problem gelöst oder es ist keines, das wir bisher betrachtet haben. Die nächsten Abschnitte umfassen Troubleshooting-Aufgaben, von denen verlangt wird, die Infrastruktur zum Betrieb von Samba zu besitzen, nicht Samba selbst.

9.2.7.1 Kein Einloggen

Ein gelegentliches Problem ist, sich beim Client vergessen einzuloggen oder als falsche Person (ohne Account) einzuloggen. Das Erstere wird gar nicht erkannt: Windows versucht freundlich zu sein und lässt dich einsteigen. Lokal! Die einzige Warnung des Letzteren ist, dass dich Windows begrüßt und dich nach deinem neuen Acccount fragt. Jedes von beiden führt zu wiederholten Ablehnungen der Verbindung und endlosen Fragen nach den Passwörtern. Wenn nichts zu funktionieren scheint, versuch auszuloggen oder niederzufahren und wieder einzuloggen.

9.2.8 Troubleshooting von Nameservices

Dieser Abschnitt betrachtet einfaches Troubleshooting aller Nameservices, die du antriffst, jedoch nur für die üblichen Probleme, die Samba betreffen.

Es gibt einige gute Referenzen zum Troubleshooting bestimmter Nameservices: Paul Albitz und Cricket Liu's DNS and Bind behandelt den Domain Name Service (DNS), Hal Stern's NFS and NIS (beide von O'Reilly) berichtet über NIS ("Yellow pages"), während WINS (Windows Internet Name Service), hosts/LMHOSTS-Dateien und NIS+ am besten in den Handbüchern ihrer jeweiligen Vertreiber erklärt werden.

Die in diesem Abschnitt angesprochenen Probleme sind:

Nameservices identifizieren
Ein Hostname kann nicht aufgesucht werden
Die lange Form (FQDN) eines Hostnamens funktioniert, aber die kurze Form nicht
Die kurze Form des Namens funktioniert, aber die lange Form nicht
Eine lange Wartepause vergeht, bevor das Erwartete sich ergibt

9.2.8.1 Identifizieren, was verwendet wird

Schau zuerst nach, ob der Server und der Client DNS, WINS, NIS oder hosts-Dateien verwenden, um die IP-Adressen herauszufinden, wenn du ihnen einen Namen gibst. Jede Art von Maschine hat eine andere Preferenz:

Windows 95 und 98-Maschinen schauen zuerst in WINS und LMHOSTS-Dateien, dann in Broadcast nach und versuchen schließlich DNS und hosts-Dateien.
NT schaut nach in WINS, dann Broadcast, LMHOSTS-Dateien und schließlich hosts und DNS.
Windows-Programme, die den WINSOCK-Standard verwenden (wie PC-NFSs), benützen Hosts-Dateien, DNS, WINS und dann Broadcast. Geh nicht davon aus, dass, wenn das Nameservice eines anderen Programms funktioniert, das Nameservice des SMB Client-Programms das macht!
Samba-Dämonen verwenden LMHOSTS, WINS, die Preferenz des Unix-Hosts und dann Broadcast.
Unix-Hosts können konfiguriert werden, damit sie irgendeine Kombination von DNS, hosts-Dateien sowie NIS und NIS+ verwenden, im Allgemeinen in irgendeiner Reihenfolge.

Wir empfehlen, dass die Client-Maschinen konfiguriert werden, WINS und DNS zu benützen, die Samba-Dämonen, dass sie WINS und DNS verwenden, und der Unix-Server, dass er DNS verwendet. Du musst in deine Notizen und auf die aktuellen Maschinen schauen, um zu erkennen, was verwendet wird.

Auf den Clients werden die Nameservices alle im Rahmen TCP/IP-Eigenschaften der Netzwerkumgebung gesetzt, wie in Kapitel 3 besprochen. Du müsstest hier nachschauen, was du wirklich eingerichtet hast. Schau, ob auf dem Server eine /etc/resolv.conf-Datei existiert. Wenn ja, dann verwendest du DNS. Du könntest allerdings die anderen auch verwenden. Du musst eine Überprüfung bezüglich NIS und Kombinationen von Services durchführen.

Suche nach einer /etc/nsswitch.conf-Datei auf Solaris und anderen System V Unix-Betriebssystemen. Wenn du eine hast, suche eine Zeile die mit host: beginnt, gefolgt von einem oder mehreren files, bind, nis oder nis+. Das sind die verwendbaren Nameservices in der Reihenfolge, mit optionalem Extra-Material in eckigen Klammern. files steht für die Verwendung von hosts-Dateien, während bind (der Berkeley Internet Name Daemon) für die Verwendung von DNS steht.

Wenn der Client und der Server differieren, ist die erste Arbeit, sie zu synchronisieren. Clients können nur DNS, WINS, hosts-Dateien und lmhosts-Dateien verwenden, nicht NIS oder NIS+. Server können hosts-Dateien, DNS, NIS oder NIS+ aber nicht WINS verwenden - außer wenn dein Sambaserver WINS-Dienste bereitstellt. Wenn du nicht alle Systeme für die Verwendung derselben Services einstellen kannst, musst du den Server und den Client sorgfältig bezüglich derselben Daten überprüfen.

Samba 2.0 (und späte 1.9 Versionen) ergänzten eine -R (resolve order)-Option zu smbclient. Wenn du z.B. WINS troubleshooten willst, musst du sagen:

 smbclient -L server -R wins

Die möglichen Einstellungen sind hosts (bedeutet hier, was immer auch die Unix-Maschine verwendet, nicht nur /etc/hosts-Dateien), lmhosts, wins und bcast (Broadcast).

In den folgenden Abschnitten verwenden wir den Ausdruck long name für einen fully-qualified Domänennamen (FQDN), wie server.example.com, und den Ausdruck short name für den Hostteil eines FQDN, wie server.

9.2.8.2 Hostnamen können nicht aufgesucht werden

Versuch Folgendes:

In DNS:
Rufe nslookup name auf. Wenn das fehlschlägt, such einen resolv.conf-Fehler, einen niedergefahrenen DNS-Server oder ein short/long name-Problem (siehe den nächsten Abschnitt). Versuch Folgendes:
Deine /etc/resolv.conf sollte eine oder mehr Nameserver-Zeilen enthalten, jede mit einer IP-Adresse. Das sind die Adressen deiner DNS-Server.
Pinge jede gefundene Serveradresse an. Wenn das bei einer fehlschlägt, verdächtige die Maschine. Wenn es bei jeder fehlschlägt, verdächtige dein Netzwerk.
Probier die Suche noch einmal unter Verwendung des vollen Domänennamens (z.B server.example.com), wenn du zuerst den kurzen Namen versucht hast, oder den kurzen Namen, wenn du zuerst den langen Namen probiert hast. Wenn die Ergebnisse differieren, spring zum nächsten Abschnitt.

In Broadcast/ WINS:
Broadcast/ WINS verarbeitet nur kurze Namen wie server, (keine langen wie server.example.com). Rufe nmblookup -S server auf.Das berichtet alles, was Broadcast für den Namen registriert hat. In unserem Beispiel schaut das folgendermaßen aus:

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 den NetBIOS-Namen dieser Maschine identifiziert. Du solltest auch deine Arbeitsgruppe ein- oder mehrmals erwähnt sehen. Wenn diese Zeilen fehlen, kann Broadcast/WINS die Namen nicht aufsuchen und braucht Aufmerksamkeit.

Die Zahlen in den Spitzklammern in der vorstehenden Ausgabe identifizieren NetBIOS-Namen als Arbeitsgruppen, Arbeitsstationen und Datei-User des Messenger-Service, Master-Browser, Domain-Masterbrowser, Domain-Controller und eine Fülle anderer. Wir verwenden in erster Linie <00> zur Erkennung von Maschinen und Arbeitsgruppen-Namen und <20>, um Maschinen als Server zu identifizieren. Die komplette Liste findest du bei http://support.microsoft.com/support/kb/articles/q163/4/09.asp.

In NIS:
Versuche ypmatch name hosts. Wenn das fehlschlägt, ist NIS heruntergefahren. Finde den Namen des NIS-Servers durch den Aufruf von ypwhich heraus und pinge die Maschine an, um nachzuschauen, ob darauf zugegriffen werden kann.
In NIS+:
Wenn du NIS+ laufen hast, versuche nismatch name hosts. Wenn das fehlschlägt, ist NIS heruntergefahren. Finde den Namen des NIS-Servers durch den Aufruf von niswhich heraus und pinge die Maschine an, um nachzuschauen, ob darauf zugegriffen werden kann.
In hosts-Dateien:
Kontrolliere /etc/hosts auf dem Client (C:\WINDOWS\HOSTS). Jede Zeile sollte eine IP-Nummer haben und einen oder mehr Namen, den Primary Name zuerst, dann irgendwelche optionale Alias-Namen. Ein Beispiel folgt:

        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

Auf Unix sollte localhost immer 127.0.0.1 sein, obwohl es nur ein Alias-Name für einen Hostnamen auf dem PC sein könnte. Überprüfe auf dem Client, dass es keine #XXX-Direktiven an den Enden der Zeilen gibt; das sind LAN Manager/NetBIOS-Direktiven und sollten nur in LMHOSTS-Dateien aufscheinen (C:\WINDOWS\LMHOSTS).
In LMHOSTS-Dateien:
Diese Datei ist eine lokale Quelle für LAN Manager (NetBIOS)-Namen. Ihr Format ähnelt den /etc/hosts-Dateien sehr, unterstützt aber keine Langform der Domänennamen (z.B. server.example.com) und könnte eine Anzahl von optionalen #XXX-Direktiven unmittelbar nach den Namen haben. Beachte, es gibt gewöhnlich eine lmhosts.sam (für sample)-Datei in C:\WINDOWS, aber sie wird nicht verwendet, außer wenn sie in C:\WINDOWS\LMHOSTS umbenannt wird.

9.2.8.3 Lange und kurze Hostnamen

Wo die lange Form (FQDN) eines Hostnamens funktioniert, aber der kurze Name nicht (z.B. client.example.com funktioniert, aber client nicht), überlege Folgendes:

DNS:
Das deutet für gewöhnlich darauf hin, dass es keine voreingestellte Domäne gibt, in welcher die kurzen Namen gefunden werden. Such auf dem Sambaserver eine default-Zeile in /etc/resolv.conf mit deiner Domäne darin oder eine search-Zeile mit einer oder mehreren Domänen darin. Eine oder die andere sollte vorhanden sein, damit kurze Namen verwendbar sind; manch eine hängt vom Vertreiber und von der Version des DNS-Resolvers ab. Versuche domain your domain in der resolv.conf hinzuzufügen und frage deinen Netzwerk- oder DNS-Administrator, was in der Datei gewesen sein sollte.
Broadcast/WINS:
Broadcast/WINS unterstützt keine langen Namen; es wird nicht unter diesem Problem leiden.
NIS:
Versuch das Kommando ypmatch hostname hosts. Wenn das nicht funktioniert, enthalten deine Tabellen keine kurzen Namen. Sprich mit deinem Netzwerk-Manager, kurze Namen könnten aus Versehen fehlen oder könnten aus Gründen der Policy nicht unterstützt werden. Einige Sites verwenden niemals (zweideutige) Kurznamen.
NIS+ :
Versuch nismatch hostname hosts und behandle Fehler exakt wie bei NIS vorher.
hosts:
Wenn der kurze Name nicht in /etc/hosts steht, überlege, ihn als Alias hinzuzufügen. Vermeide, wenn du kannst, kurze Namen als Primary-Namen (der erste in einer Zeile). Nimm sie als Alias-Namen, wenn es dein System erlaubt.
LMHOSTS:
Der LAN Manager unterstützt keine langen Namen, also wird er nicht unter diesem Problem leiden.

Andererseits, wenn die kurze Form des Namens funktioniert und die lange nicht, erwäge das Folgende:

DNS:
Das ist bizarr; triff dich mit deinem Netzwerk- oder DNS-Administrator, weil das wahrscheinlich ein DNS-Setupfehler ist.
Broadcast/WINS:
Das ist ein normaler Fehler; Broadcast/WINS kann die lange Form nicht verwenden. Überlege optional DNS. Microsoft hat angegeben, dass sie auf DNS umsteigen werden, obwohl es keine Namenstypen wie <00> bereitstellt.
NIS:
Wenn du ypmatch verwenden kannst, um die kurze Form zu suchen, aber nicht die lange, dann überlege, die lange Form als zumindest ein Alias hinzuzufügen.
NIS+:
Dasselbe wie NIS, ausgenommen, dass du nismatch anstatt ypmatch verwendest, um Namen zu suchen.
hosts:
Gib den langen Namen wenigstens als Alias und vorzüglich als die Primary-Form dazu. Überlege auch die Verwendung von DNS, wenn es praktisch ist.
LMHOSTS:
Das ist ein normaler Fehler; der LAN Manager kann die lange Form nicht verwenden. Überlege einen Umstieg auf DNS oder hosts.

9.2.8.4 Ungewöhnliche Wartezeiten

Wenn eine lange Wartezeit eintritt, bevor sich das Erwartete ergibt:

DNS:
Teste denselben Namen mit dem Kommando nslookup auf der langsamen Maschine (Client oder Server). Wenn nslookup ebenfalls langsam ist, hast du ein DNS-Problem. Wenn es auf einem Client langsamer ist, hast du zu viele Protokolle an die Ethernetkarte gebunden. Entferne NetBEUI, das berüchtigt langsam ist, und möglicherweise Novell in der Annahme, dass du beide nicht brauchst. Dies ist besonders wichtig unter Windows 95, das besonders empfindlich auf ein Übermaß an Protokollen ist.
Broadcast/ WINS:
Teste den Client mit nmblookup, und wenn es schneller ist, hast du wahrscheinlich das Problem mit den Protokollen, wie im vorigen Absatz erwähnt.
NIS:
Versuche ypmatch, und wenn es langsam ist, berichte dein Problem deinem Netzwerk-Manager.
NIS+:
Versuche nismatch ähnlich.
hosts:
hosts-Dateien, wenn von vernüftiger Größe, sind immer schnell. Du hast wahrscheinlich das Problem mit den Protokollen, wie oben unter DNS erwähnt.
LMHOSTS:
Das ist kein Namensfinder-Problem; LMHOSTS-Dateien sind so schnell wie hosts-Dateien.

9.2.8.5 Localhost-Fragen

Wenn ein Localhost nicht 127.0.0.1 ist, versuch das Folgende:

DNS:
Es gibt wahrscheinlich keine Aufzeichnung für localhost. Ein 127.0.0.1. Sorg dafür, dass ein Eintrag und ein umgekehrter Eintrag hinzugefügt werden, 1.0.0.127.IN-ADDR.ARPA PTR 127.0.0.1.
Broadcast/WINS:
Nicht anwendbar.
NIS:
Wenn localhost in der Tabelle nicht vorkommt, füg ihn hinzu.
NIS+:
Wenn localhost in der Tabelle nicht vorkommt, füg ihn hinzu.
hosts:
Ergänze eine Zeile in der hosts-Datei, lautend 127.0.0.1 localhost
LMHOSTS:
Nicht anwendbar.

9.2.9 Troubleshooting von Netzwerk-Adressen

Eine Anzahl von bekannten Problemen werden von nicht korrektem Internetadressen-Routing oder der falschen Zuordnung von Adressen verursacht. Dieser Abschnitt hilft dir zu bestimmen, was deine Adressen sind.

9.2.9.1 Netzmasken

Die Netzmasken sagen jeder Maschine, welche Adressen direkt erreicht werden können (sind auf deinem lokalen Netzwerk) und welche Adressen Forwarding-Pakete durch einen Router erfordern. Wenn die Netzmaske falsch ist, machen die Maschinen einen von zwei Fehlern. Einer ist der Versuch, lokale Pakete im Wege eines Routers zu routen, was eine kostspielige Möglichkeit ist, Zeit zu vergeuden - es könnte akzeptabel schnell arbeiten, es könnte langsam laufen oder es könnte total fehlschlagen. Der zweite Fehler ist das Versagen, Pakete für eine Remote-Maschine zum Router zu senden, welcher sie daran hindert, zur Remote-Maschine geforwardet zu werden.

Die Netzmaske ist eine Zahl wie eine IP-Adresse mit 1-Bits für den Netzwerkteil einer Adresse und 0-Bits für den Host-Anteil. Die Netzmaske wird buchstäblich für das Maskieren von Teilen der Adresse innerhalb des TCP/IP-Codes verwendet. Wenn die Maske 255.255.0.0 ist, sind die ersten 2 Bytes der Netzwerkteil und die letzten 2 der Hostteil. Gebräuchlicher ist 255.255.255.0, worin die ersten 3 Bytes der Netzwerkteil sind und das letzte der Hostteil ist.

Sagen wir z.B., deine IP-Adresse wäre 192.168.0.10 und der Sambaserver wäre 192.168.236.86. Wenn deine Netzmaske 255.255.255.0 enthält, ist der Netzwerkteil der Adresse die ersten 3 Bytes und der Hostteil ist das letzte Byte. In diesem Fall sind die Netzwerkteile verschieden, und die Maschinen liegen in verschiedenen Netzwerken:

Netzwerkteil	Hostteil
192 168 000	10
192 168 235	86

Wenn deine Netzmaske 255.255.0.0 lautet, umfasst der Netzwerkteil nur die ersten zwei Bytes. In diesem Fall stimmen die Netzwerkteile überein, und daher befinden sich die zwei Maschinen auf demselben Netzwerk:

Netzwerkteil	Hostteil
192 168	000 10
192 168	236 86

Wenn natürlich deine Netzmaske so sagt und dein Netzwerk-Manager sagt anders, ist die Netzmaske falsch.

9.2.9.2 Broadcast-Adressen

Die Broadcast-Adresse ist eine normale Adresse mit dem Hostteil von lauter 1-Bits. Das bedeutet "alle Hosts auf deinem Netzwerk". Du kannst sie leicht aus deiner Netzmaske und Adresse ausrechnen: nimm die Adresse und setze 1-Bits für alle 0-Bits am Ende der Netzmaske (der Hostteil). Die folgende Tabelle verdeutlicht das:

	Netzwerkteil	Hostteil
IP-Adresse	192 168 236	86
Netzmaske	255 255 255	000
Broadcast	192 168 236	255

In diesem Beispiel ist die Broadcast-Adresse auf dem 192.168.236-Netzwerk 192.168.236.255. Es gibt auch eine alte "universelle" Broadcast-Adresse, 255.255.255.255. Router dürfen diese nicht forwarden, aber die meisten Maschinen auf deinem lokalen Netzwerk werden Broadcasts zu dieser Adresse beantworten.

9.2.9.3 Netzwerk-Adressbereiche

Eine Anzahl von Adressbereichen wurden zum Testen und für private Netzwerke reserviert; wir verwenden einen davon für das Buch. Wenn du noch keine Adresse hast, sei so frei und verwende eine davon, um damit zu beginnen. Sie umfassen ein Klasse A-Netzwerk (groß), 10.*.*.*, und 254 Klasse C-Netzwerke (kleiner), 192.168.1.* bis 192.168.254.*. In diesem Buch benützen wir eines der letzteren, 192.168.236.*. Die Domäne example.com ist auch für private Netzwerke, erläuternde Beispiele und Bücher reserviert.

Wenn du dich tatsächlich ins Internet einwählst, musst du einen wirklichen Netzwerknamen und einen Domänennamen bekommen, wahrscheinlich über dieselbe Firma, die deine Verbindung zur Verfügung stellt.

9.2.9.4 Auffinden deiner Netzwerk-Adresse

Wenn du deine IP-Adresse nicht aufgeschrieben hast, wird sie vom Befehl ifconfig unter Unix oder vom Kommando IPCONFIG unter Windows 95 und NT gezeigt. (Untersuche deine Manual-Seiten wegen irgendwelcher Optionen, die von deiner Version von Unix verlangt werden: Sun möchte ifconfig -a). Du solltest eine Ausgabe ähnlich der folgenden sehen:

server% 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

Eines der Interfaces wird loopback sein (in unseren Beispielen lo0), und das andere ist das reguläre IP-Interface. Die Flags sollten anzeigen, dass das Interface läuft, und Ethernet-Interfaces melden ebenfalls, dass sie Broadcasts unterstützen (PPP-Interfaces tun das nicht). Andere Plätze zum Suchen von IP-Adressen sind /etc/hosts-Dateien, Windows HOSTS-Dateien, Windows LMHOSTS-Dateien, NIS, NIS+ und DNS.

9.2.10 Troubleshooting bei NetBIOS-Namen

Die SMB-Protokolle hingen historisch vom NetBIOS Namenssystem ab, auch das LAN Manager Namenssystem genannt. Das war ein einfaches Schema, wo jede Maschine einen einzigen Namen aus 20 Zeichen hatte und ihn auf dem LAN broadcastete, damit ihn jeder kannte. Bei TCP/IP pflegen wir Namen wie client.example.com, gespeichert in /etc/hosts-Dateien, zu verwenden, durch DNS oder WINS.

Die übliche Zuordnung zu Domainnamen wie server.example.com verwendet einfach den Server-Teil als den NetBIOS-Namen und wandelt ihn in Großbuchstaben um. Leider funktioniert das nicht immer, besonders wenn du eine Maschine mit einem 21-Buchstaben-Namen hast; nicht jeder verwendet dieselben NetBIOS- und DNS-Namen. Zum Beispiel ist corpvm1 zusammen mit vm1.corp.com nicht unüblich.

Eine Maschine mit einem verschiedenen NetBIOS-Namen und Domainnamen ist verwirrend, wenn du Troubleshooting durchführst; wir empfehlen, dass du dies wenn möglich zu vermeiden suchst. NetBIOS-Namen können mit smbclient entdeckt werden:

Wenn du Shares auf deinem Sambaserver mit smbclient und einer Option -L (liste Shares auf) des short_name_of_server auflisten kannst, ist der kurze Name der NetBIOS-Name.
Wenn du "Get_Hostbyname: Unknown host name" bekommst, gibt es wahrscheinlich keine Übereinstimmung. Überprüfe in der smb.conf-Datei, ob der NetBIOS-Name explizit gesetzt ist.
Versuch es noch einmal mit der Angabe von -I und der IP-Adresse des Sambaservers (z.B. smbclient -L server -I 192.168.236.86). Das hebt die Namenssuche auf und zwingt die Pakete, zur IP-Adresse zu gehen. Wenn das funktioniert, gab es keine Übereinstimmung.
Versuch es mit -I und dem vollen Domainnamen des Servers (z.B. smbclient -L server -I server.example.com). Das testet die Suche nach dem Domainnamen und benützt egal welches Schema, das der Sambaserver verwendet (z.B. DNS). Wenn das fehlschlägt, hast du ein Nameservice-Problem. Du solltest den Abschnitt 9.2.8 noch einmal lesen, nachdem du das Troubleshooting der NetBIOS-Namen beendet hast.
Versuch es mit -n (NetBIOS-Name) und dem Namen, mit dem du arbeiten willst (z.B. smbclient -n server -L server-12), aber ohne die IP-Adresse durch -I aufzuheben. Wenn das funktioniert, dann ist der Name, den du mit -n angegeben hast, der aktuelle NetBIOS-Name des Servers. Wenn du "Get-Hostbyname: Unknown host MARY" erhältst, ist es noch nicht der richtige Server.
Wenn so weit nichts funktioniert, wiederhole die Tests mit der Angabe von -U username und -W workgroup, mit Username und Workgroup in Großbuchstaben, um sicherzustellen, dass du nicht durch eine Nicht-Übereinstimmung eines Users oder einer Arbeitsgruppe entgleist.
Wenn noch immer nichts funktioniert und du Beweise für ein Nameservice-Problem hattest, mach ein Troubleshooting des Nameservices im Abschnitt 9.2.8 und kehr dann zum NetBIOS-Nameservice zurück.


9.1 Die Werkzeugtasche		9.3 Zusätzliche Ressourcen

Using Samba