Fehler/Samba

aus openSUSE, der freien Wissensdatenbank

Samba-Fehlerberichte und erweiterte Debugging-Informationen

Wenn Sie hierbei oder bei in SUSE Linux-Produkten enthaltenen Pakten auf Fehler stoßen, beschuldigen Sie bitte nicht das Samba-Team . Prüfen Sie statt dessen zuerst die Samba-Problemlösungsseite . Falls das nicht hilft, erstellen Sie einen Fehlerbericht im Samba-Bugzilla, wählen Sie als Produkt Samba ihre.Version, dann Wählen Sie als 'component' Packaging und setzen 'assign to' auf samba-maintainers at suse dot de. Oder nutzen Sie statt dessen das Novell-Bugzilla und nutzen Sie die gleiche Adresse um den Fehler zuzuweisen.

Dateien als Anhang bereitstellen

Stellen Sie alle Protokolldateien aus /var/log/samba/ bereit und die tdb-Dateien aus /var/lib/samba und die Konfigurationsdatei /etc/samba/smb.conf. Schreiben Sie auch die Ausgabe von 'rpm -qi samba' oder 'rpm -qi samba-<Unterpaket>' in ihren Bericht. Wir benötigen diese Informationen um rekonstruieren zu können, was passiert ist.

Wenn winbind Teil des Problems ist, dann stellen Sie bitte auch /etc/security/pam_winbind.conf bereit und wenn Sie in pam_winbind.conf debug aktiviert haben, dann wird auch /var/log/messages benötigt.

Eine detailliertere Beschreibung verschiedener Samba-Komponenten finden Sie unterhalb dieses Abschnitts.

Daemons testen (winbind, smb, nmb)

1. Stoppen Sie alle laufenden Samba-Prozesse (winbind, smb, nmb)

2. Entfernen Sie alle Protokolldateien aus /var/log/samba/

3. Bearbeiten Sie /etc/samba/smb.conf und setzen Sie im Konfigurationsabschnitt [general] die folgenden Variablen:

     debug level = 10
     max log size = 0

Dadurch erhalten wir in den Protokolldateien das Startdatum der Tests.

Falls winbind Teil des Szenarios ist, setzen Sie bitte auch

     debug = yes

in /etc/security/pam_winbind.conf

4. Starten Sie die Prozesse wieder (winbind, smb, nmb)

5. Reproduzieren Sie den Fehler und notieren Sie die Zeit, wann jeder Test beginnt. Wenn während der Tests ein Fehler auftritt, notieren Sie die Zeit (nutzen Sie date auf dem System, auf dem Sie die Tests durchführen, um eine Zeit zu erhalten, die zu den Protokolldateien passt).

Hängen Sie ihrem Fehlerbericht die Protokolldateien aus /var/log/samba/ und die tdb-Dateien aus /var/lib/samba/ an. Falls möglich löschen Sie die tdb-Dateien und stellen saubere Dateien bereit. Das Beste ist, wenn Sie sie in einem komprimierten tar-Archiv zusammen bündeln. Die relevanten Teile aus /var/log/messages könnten ebenfalls von Interesse sein.

pam_winbind testen

Wenn Sie ein Problem mit pam_winbind haben, aktivieren Sie in /etc/security/pam_winbind.conf das Debugging. Fügen Sie der Datei die folgende Zeile hinzu:

 debug = yes

Das winbind-PAM-Modul wird alles in /var/log/messages protokollieren.

Client-Werkzeuge testen (net, smbclient, usw.)

Die Client-Werkzeuge protokollieren nicht in die Dateien in /var/log/samba/, diese Werkzeuge protokollieren nach stderr und Sie müssen die debug-Ausgabe auf der Kommandozeile aktivieren. Wenn Sie die debug-Ausgabe des net-Kommandos beim Betreten einer Domäne haben wollen, müssen Sie folgendes machen:

Das Bereitstellen von Netzwerkbeobachtungen (traces) könnte bei Problemen mit den Client-Werkzeugen ebenfalls helfen (siehe unten).

Traces

Netzwerk-Traces

Wenn Sie mit tcpdump erstellte Netzwerk-Traces einsenden, dann stellen Sie sicher, dass Sie dieses Kommando nutzen:

  tcpdump -i SCHNITTSTELLE -s 0 -w /tmp/tracefile

Ersetzen Sie SCHNITTSTELLE durch ihre Netzwerkschnittstelle. Erläutern Sie bitte auch noch zusätzlich die Rollen der in den Netzwerk-Trace eingebundenen Maschinen (wer ist der Client, wer ist der Server, welche IP-Adressen haben sie, usw.). Die Hardware betreffende Informationen sind in der Regel nicht von Interesse.

Rückverfolgungen

Wenn Sie in /var/log/messages eine panic-Nachricht sehen, können Sie mit den folgenden Anweisungen eine GNU-Debugger-Rückverfolgung (gdb backtrace) erstellen:

• Installieren Sie gdb
• Installieren Sie die Pakete samba-debuginfo und samba-doc
• Machen Sie das backtrace-Skript ausführbar: chmod +x /usr/share/doc/packages/samba/examples/scripts/debugging/linux/backtrace
• Fügen Sie die folgende Zeile dem global-Abschnitt der Samba-Konfigurationsdatei /etc/samba/smb.conf hinzu:

 panic action = /usr/share/doc/packages/samba/examples/scripts/debugging/linux/backtrace %d

Wenn Sie die Umstände zum Auslösen der panic reproduziert haben, wird die Rückverfolgung in das Verzeichnis /var/log/samba geschrieben.

Lesen von Samba-Protokollen

Die folgenden grep-Kommandos sind hilfreich:

 grep -R -n -B2 -i "failed" $@
 grep -R -n -B2 "timeout [0-9]* seconds" $@

cifs-vfs-Client debuggen

Das cifs-vfs-Kernel-Modul cifs.ko wird üblicherweise genutzt, um Windows- und Samba-Server einzubinden und um von solchen Mounts angeforderte Anwendungen zu starten.

Wenn Sie ein Problem mit dem cifs-vfs-Client annehmen, stellen Sie bitte die folgenden Debugging-Informationen bereit:

• Ausgabe der Kommandos`cat /proc/fs/cifs/DebugData' und `uname -r`
• Ein Netzwerkabgriff von cifs-Paketen

   #tcpdump -s0 -w cifs-debug.cap 'port 137 || 138 || 139 || 445'

• Wenn bei mount/umount oder bei Dateioperationen das System einfriert, fügen Sie die Ausgabe von `sysrq + t' hinzu. Um dies zu machen, müssen die Magic-Sysrq-Tasten aktiviert sein. Halten Sie sich dazu an Fehler/Kernel, um sysrq zu aktivieren und zu nutzen.
• dmesg oder syslog (/var/log/messages) wird verschiedene ernste Fehler anzeigen, zusätzliche cifs debugging flags können die Ausgabe aber noch erhöhen. Sie erreichen dies folgendermaßen:

   #dmesg -c /* dies leert den Kernel-Ringzwischenspeicher */
   #echo 3 > /proc/fs/cifs/cifsFYI /* aktiviert zusätzliches debugging */
   <starten Sie die Operation>
   #dmesg > cifs-debug.txt
   Hängen Sie cifs-debug.txt an.

• Wenn bei mount/umount Probleme auftreten, stellen Sie bitte die folgenden Informationen bereit:

   - Ausgabe des Kommandos `mount' und/oder `cat /etc/mtab'
   - mount -vV (gibt die Version aus)
   - Falls mount fehlschlägt, hängen eine strace-Ausgabe an, die während der mount-Operation aufgenommen wurde