9. Feststellen und Lösen von Problemen unter Samba

Inhalt:
Die Werkzeugtasche
Der Fehlerbaum
Zusätzliche Ressourcen

Samba ist extrem robust. Hast du einmal alles in der gewünschten Weise eingerichtet, wirst du wahrscheinlich vergessen, dass es läuft. Wenn Schwierigkeiten auftreten, dann typischerweise während der Installation oder wenn du versuchst, etwas Neues auf dem Server hinzuzufügen. Glücklicherweise gibt es eine breite Palette von Ressourcen, die du zur Diagnose dieser Schwierigkeiten heranziehen kannst. Obwohl wir nicht die Lösung jedes Problems im Detail beschreiben können, das dir begegnen mag, solltest du für einen guten Start zu einem Entschluss befähigt werden, dem Rat zu folgen, der in diesem Kapitel erteilt wird.

Der erste Abschnitt des Kapitels beschreibt die Werkzeugtasche, eine Sammlung von Tools, die für das Troubleshooting unter Samba zur Verfügung stehen; der zweite Abschnitt ist ein genaues Howto und der letzte Abschnitt zählt Extra-Ressourcen auf, die du brauchen kannst, besonders hartnäckige Probleme ausfindig zu machen.

9.1 Die Werkzeugtasche

Manchmal scheint Unix aus einer Handvoll Applikationen und Werkzeugen zu bestehen. Es gibt Werkzeuge für das Troubleshooting von Werkzeugen. Und natürlich gibt es einige Möglichkeiten dieselbe Aufgabe zu bewältigen. Wenn du ein Problem in Bezug auf Samba zu lösen versuchst, ist es ein gute Vorgangsweise, Folgendes zu überprüfen:

Samba-Logdateien
Fehler-Baum
Unix-Utililies
Samba-Testutilities
Dokumentation und FAQs
Such-Archive
Samba-Newsgroups

Gehen wir sie alle in den folgenden Abschnitten Punkt für Punkt durch.

9.1.1 Samba Logs

Du solltest als Erstes immer die Log-Dateien in Angriff nehmen. Die Samba-Logdateien sind hilfreich beim Diagnostizieren der weitaus meisten Probleme, mit denen angehende Samba-Administratoren wahrscheinlich rechnen müssen. Du kannst den Server so aufsetzen, dass er wenig oder viel protokolliert, wie du willst. Einsetzen von Variablen, die dir erlauben, individuelle Logs für jede Maschine, Share oder Kombination davon zu isolieren.

Als Voreinstellung sind Logs in samba_directory /var/smbd.log und samba_directory /var/nmbd.log zu Hause, wobei samba_directory der Standort ist, wo Samba installiert wurde (typischerweise /usr/local/samba). Wie wir in Kapitel 4, Disk Shares erwähnten, kannst du den Standort und den Namen verändern, indem du die Konfigurations-Option log file in der smb.conf verwendest. Diese Option akzeptiert alle Substitutions-Variablen, die im Kapitel 2, Samba auf einem Unix-System installieren, erwähnt wurden, so könntest du leicht den Server zu einem eigenen Log für jeden angeschlossenen Client veranlassen, indem du das Folgende in der Sektion [global] der smb.conf festlegst:

log file = %m.log

Alternativ kannst du ein Log-Verzeichnis angeben, was mit dem Signal -l auf der Kommandozeile geschieht. Zum Beispiel:

smbd -l /usr/local/var/samba

Ein anderer brauchbarer Trick ist, den Server ein Protokoll für jeden angebotenen Dienst (jede Share) führen zu lassen, besonders wenn du vermutest, dass eine bestimmte Share Schwierigkeiten verursacht. Benütze die Variable %S, um dies in der Sektion [global] der Konfigurationsdatei einzurichten:

log file = %S.log

9.1.1.1 Log-Levels

Der von Samba verwendete Level beim Logging kann in der Datei smb.conf mit der globalen Option log level oder debug level gesetzt werden; beide sind gleichwertig. Der Log-Level ist ein Ganzzahlwert, der sich von 0 (kein Logging) bis zu umfangreichem Logging bei log level = 3 steigert. Nehmen wir z.B. an, dass wir einen Windows-Client verwenden werden, um ein Verzeichnis auf einem Sambaserver zu browsen. Für ein kleines bisschen Log-Information kannst du log level = 1 benützen, was Samba anweist, nur oberflächliche Information herzuzeigen, in diesem Fall nur die Verbindung selbst:

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

Höhere Debug-Levels erzeugen genauere Information. Üblicherweise wirst du nicht mehr brauchen als Level 3; das ist mehr als ausreichend für die meisten Samba-Administratoren. Levels über 3 gehören für den Gebrauch durch die Entwickler und produzieren enorme Mengen an kryptischer Information.

Hier sieht man eine Musterausgabe bei Level 2 und 3 für dieselbe Operation. Verfall nicht in Panik, wenn du die Feinheiten einer SMB-Verbindung nicht verstehst; der Sinn ist, dir einfach zu zeigen, welche Arten Information bei den verschiedenen Logging-Levels zu sehen sind:

 /* 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/98 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/98 22:15:09 server (192.168.236.86) connect to service IPC$ as user pcguest (uid=503,gid=100) (pid 3377)
05/25/98 22:15:09 tconX service=ipc$ user=pcguest cnum=105
05/25/98 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/98 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/98 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/98 22:15:11 Transaction 67 of length 53
switch message SMBgetatr (pid 3377)
chdir to /

[...]

Wir schnitten dieses Listing nach dem ersten Paket ab, weil es noch viele Seiten weitergeht. Nun, du solltest dir bewusst sein, dass Log-Levels über 3 deine Platte schnell anfüllen mit Megabytes von qualvollen Details über Samba-interne Operationen. Log-Level 3 ist extrem praktisch, um das zu verfolgen, was der Server gerade tut, und die meiste Zeit ist es beim Überfliegen der Logdatei klar, wo ein Fehler passiert.

Ein Wort zur Warnung: die Verwendung eines hohen Log-Levels (3 oder darüber) verlangsamt den Sambaserver ernsthaft. Denk daran, dass jede erzeugte Log-Meldung einen Schreibvorgang auf der Platte verursacht (eine naturgemäß langsame Operation) und Log-Levels größer als 2 riesige Mengen an Daten produzieren. Unentbehrlich sollte das Einschalten des Log-Levels 3 nur sein, wenn du aktiv ein Problem auf dem Sambaserver verfolgst.

9.1.1.2 Logging aktivieren und deaktivieren

Um Logging ein- und auszuschalten, setz den geeigneten Level in der Sektion [global] der smb.conf. Dann kannst du entweder Samba neu starten oder den laufenden Dämon zwingen, die Konfigurationsdatei wieder aufzubereiten. Du kannst auch dem smbd-Prozess ein SIGUSR1-Signal senden, um seinen Log-Level während des Betriebes um eins zu erhöhen, und ein SIGUSR2-Signal, um ihn um eins herabzusetzen:

# Increase the logging level by 1
kill -SIGUSR1 1234

# Decrease the logging level by 1
kill -SIGUSR2 1234

9.1.1.3 Logging durch einzelne Client-Maschinen oder User

Eine effektive Methode, um Probleme ohne Behinderung anderer User zu diagnostizieren, ist die Bestimmung verschiedener Log-Levels für verschiedene Maschinen in der Sektion [global] der smb.conf-Datei. Wir können das bewerkstelligen, indem wir auf der Strategie aufbauen, die wir an früherer Stelle vorstellten:

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

Diese Optionen instruieren Samba, einzigartige Konfiguration und Log-Dateien für jeden Client zu benützen, der sich anmeldet. Alles, was du jetzt tun musst, ist, eine smb.conf-Datei für eine bestimmte Client-Maschine mit einem Eintrag log level = 3 darin zu erstellen (die anderen holen sich den voreingestellten Log-Level 0) und diese Logdatei zu verwenden, um das Problem ausfindig zu machen.

Wenn nur einzelne User ein Problem erleben und es folgt ihnen von Maschine zu Maschine, kannst du in ähnlicher Weise das Logging für einen bestimmten User isolieren, indem du Folgendes in der Datei smb.conf ergänzt:

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

Dann kannst du eine separate smb.conf-Datei für jeden User erzeugen (z.B. /usr/local/samba/lib/smb.conf.tim). Die Dateien enthalten die Konfigurations-Option log level = 3, und nur diese User werden ein genaueres Logging bekommen.

9.1.2 Samba Test-Utilities

Eine strenge Reihe Tests, welche die größten Teile von Samba abdecken, werden in verschiedenen Dateien im Verzeichnis /docs/textdocs des Werkzeugkastens der Samba-Distribution beschrieben, beginnend mit DIAGNOSIS.TXT. Der fault tree in diesem Kapitel ist eine genauere Version von den grundlegenden, vom Sambateam vorgeschlagenen Tests, umfasst aber nur Installation und Rekonfigurations-Diagnose wie DIAGNOSIS.TXT. Die anderen Dateien in den Unterverzeichnissen von /docs sprechen besondere Probleme an (wie Windows NT-Clients) und instruieren dich, wie du Dinge aufspüren kannst, die nicht in diesem Buch vorkommen. Wenn der fault tree nicht genügt, schau zur Sicherheit bei DIAGNOSIS.TXT und seinen Freunden nach.

9.1.3 Unix-Utilities

Manchmal verwendet man besser ein Werkzeug außerhalb der Samba-Suite zur Überprüfung der Vorgänge innerhalb des Servers. Unix ist immer ein "Spülbecken"-Betriebssystem gewesen. Zwei Diagnose-Werkzeuge können als besondere Hilfe bei der Fehlersuche infolge Samba-Schwierigkeiten herangezogen werden: trace und tcpdump.

9.1.3.1 Verwendung von trace

Der Befehl trace versteckt sich hinter einigen verschiedenen Namen, abhängig vom Betriebsystem, das du benützt. Unter Linux ist es strace, bei Solaris verwendest du truss und SGI hat padc und par. Alle haben im Wesentlichen dieselbe Aufgabe, jeden Aufruf einer Funktion des Betriebssystems darzustellen, wie er ausgeführt wird. Das erlaubt dir, der Ausführung eines Programms wie der Sambaserver zu folgen, und legt oft den genauen Aufruf fest, der die Schwierigkeit verursacht.

Ein Problem, das trace hervorheben kann, ist der Ort einer unkorrekten Version einer dynamisch gelinkten Bibliothek. Das kann passieren, wenn du vorgefertigte Binaries von Samba heruntergeladen hast. Du erkennst typischerweise den fehlerhaften Aufruf am Ende von trace, kurz bevor das Programm endet.

Eine Musterausgabe von strace für das Betriebssystem Linux folgt. Das ist ein kleiner Abschnitt einer größeren Datei, die während des Öffnens eines Verzeichnisses auf dem Sambaserver erstellt wurde. Jede Zeile ist der Name eines Systemaufrufs und enthält seine Parameter und den Rückgabe-Wert. Wenn ein Fehler auftrat, werden auch der Fehlercode (z.B. ENOENT) und seine Erklärung gezeigt. Du kannst die Parameter-Typen und Fehler einsehen, die in der entsprechenden trace-Manual-Page für das von dir verwendete Betriebssystem aufscheinen können.

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 einige stat-Aufrufe, die bei der Suche nach Dateien, die erwartet wurden, fehlschlagen. Du musst kein Experte sein, um zu sehen, dass die Datei desktop.ini in diesem Verzeichnis fehlt. Tatsächlich können viele schwierige Probleme bei der Suche nach offensichtlichen, wiederholbaren Fehlern mit trace identifiziert werden. Oft brauchst du nicht weiter zu schauen als zur letzten Meldung vor einem Absturz.

9.1.3.2 Verwendung von tcpdump

Das Programm tcpdump, geschrieben von Van Jacobson, Craig Leres und Steven McCanne und erweitert von Andrew Tridgell, erlaubt dir, den Netzwerkverkehr in Echtzeit zu überwachen. Eine Auswahl von Ausgabeformaten steht zur Verfügung, und du kannst die Ausgabe filtern, um nur eine bestimmte Art Verkehr zu betrachten. Das Programm tcpdump lässt dich die ganze Konversation zwischen Client und Server kontrollieren, SMB- und NMB-Broadcast-Messages eingeschlossen. Während seine Troubleshooting-Fähigkeiten hauptsächlich bei der OSI-Netzwerk-Schicht liegen, kannst du noch seine Ausgabe benützen, um eine generelle Idee davon zu bekommen, was der Server und der Client zu vollbringen versuchen.

Ein Muster- tcpdump-Log folgt. In diesem Beispiel hat der Client ein Verzeichnis-Listing angefordert, und der Server hat entsprechend geantwortet, indem er die Verzeichnisnamen homes, public, IPC$ und temp übergab (wir haben einige Erklärungen auf der rechten Seite angefügt):

$ tcpdump -v -s 255 -i eth0 port not telnet
SMB PACKET: SMBtrans (REQUEST)	                        

Request packet
SMB Command   =  0x25                                 

Request was ls or dir.

[000] 01 00 00 10                                     ....


>>> NBT Packet                                                                 

Outer frame of SMB packet
NBT Session Packet
Flags=0x0
Length=226
[lines skipped]
                         
SMB PACKET: SMBtrans (REPLY)	                           

Beginning of a reply to  request 
SMB Command   =  0x25			                                  

Command was an ls or dir
Error class   =  0x0			 
Error code    =  0                                                                    

No errors
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)                                                        

			Actual directory contents:
[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

Das ist mehr von derselben Debugging-Sitzung als beim Befehl trace; das Listing eines Verzeichnisses. Die von uns verwendeten Optionen waren -v (verbose=wortreich), -i eth0, um tcpdump das Interface bekanntzugeben, auf dem es horchen soll (ein Ethernet-Port), und -s 255, um es anzuweisen, die ersten 255 Bytes jedes Pakets zu sichern, anstatt die ersten 68 laut Vorgabe. Die Option port not telnet wird benützt, um Schirme des Telnet-Verkehrs zu vermeiden, solange wir beim Server remote eingeloggt waren. Das Programm tcpdump hat eigentlich eine ziemliche Zahl von Optionen, um gerade den Verkehr zu filtern, den du dir ansehen willst. Wenn du snoop oder etherdump verwendet hast, die betrachten das gewohnt unklar.

Du kannst das modifizierte tcpdump vom Samba FTP-Server unter ftp://samba.anu.edu.au/pub/samba/tcpdump-smb herunterladen. Andere Versionen enthalten keine Unterstützung für das SMB-Protokoll; wenn du keine Ausgabe siehst wie die im Beispiel gezeigte, musst du die SMB-fähige Version benützen.


8.7 Backups mit smbtar		9.2 The Fault Tree

Using Samba