Bugs/Samba

From openSUSE

Samba bug reporting and advanced debugging information

If you encounter any problem with these or in SUSE Linux products included packages please don't blame the Samba Team. Instead check first the Samba trouble-shooting page. If this doesn't help file a bug to the Samba Bugzilla, pick product Samba your.version, then select 'component' Packaging and set 'assign to' to samba-maintainers at suse dot de. Or use the Novell Bugzilla instead and use the same address to assign the bug.

Providing files as attachment

Provide all log files from /var/log/samba/ directory and the tdb files from /var/lib/samba and the configuration file /etc/samba/smb.conf. Post the output of 'rpm -qi samba' or 'rpm -qi samba-<subpackage>' too. We need that information to reconstruct what happened.

If winbind is part of the problem please provide /etc/security/pam_winbind.conf and if you have enabled debug in pam_winbind.conf /var/log/messages is requried too.

More detailed description about different Samba components can be found blow this section.

Testing daemons (winbind, smb, nmb)

1. Stop all running Samba processes (winbind, smb, nmb)

2. Remove all log files from /var/log/samba/

3. Edit /etc/samba/smb.conf and set the following variables in the in the [general] section of the config:

     debug level = 10
     max log size = 0

With this approach we ensure to have the start date of the testing in the log files.

If winbind is part of the scenario please set

     debug = yes

in /etc/security/pam_winbind.conf

4. Start the processes again (winbind, smb, nmb)

5. Reproduce the error and note the time when you start any test. If a problem occurs while testing note the time (use date on the system you perform the tests on to get a time fitting to the log files).

Attach the log files from /var/log/samba/ and the tdb files from /var/lib/samba/ to the bug. If possible, remove the tdb files and provide clean files. Therefore it's best to bond them to one compressed tar archive. The relevant parts of /var/log/messages could be interesting too.

Testing pam_winbind

If you have a problem with pam_winbind enable debugging in /etc/security/pam_winbind.conf. Add the following line to the file:

 debug = yes

The winbind pam module will log everything to /var/log/messages.

Testing client tools (net, smbclient, etc.)

The client tools don't log to the log files in /var/log/samba/, these tools log to stderr and you have to enable debug output via the command line. If you want debug output with the net command joining a domain you have to the following

 net -d 10 ads join -U Administrator%secret

It would help if you could provide network traces if you have a problem with the client tools (see below).

Traces

Network traces

When sending network traces created with tcpdump please make sure to use this command:

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

Replace INTERFACE with your network interface. In addition, please explain the roles of the machines involved in the network trace (who is the client, who is the server, what ip addresses do they have, etc.). Any hardware related information is usually not of interest.

Backtraces

When you see a panic message in /var/log/messages, you can generate a GNU debugger (gdb) backtrace by following these instructions:

• install gdb
• install the samba-debuginfo and samba-doc package
• make the backtrace script executeable: chmod +x /usr/share/doc/packages/samba/examples/scripts/debugging/linux/backtrace
• add this line into the global section of your Samba configuration file at /etc/samba/smb.conf:

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

When you have reproduced the circumstances to produce the panic, the backtrace will be written into /var/log/samba directory.

Reading Samba logs

The following grep commands are useful:

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

Debugging cifs vfs client

The cifs vfs kernel module cifs.ko is typically used to mount Windows and Samba servers and run demanding applications from those mounts.

If you suspect a problem with the cifs vfs client, please provide the following debugging information:

• Output of `cat /proc/fs/cifs/DebugData' and `uname -r` commands
• A network capture of cifs packets

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

• If you encounter a system freeze during mount/umount or doing file operations, attach `sysrq + t' output. To do this you need to enable Magic Sysrq keys. Please refer http://en.opensuse.org/Bugs/Kernel#Using_sysrq to enable sysrq and using it.
• The dmesg or syslog (/var/log/messages) will show certain serious errors, but enable additional cifs debugging flags to increase the debug output. You can do this by doing:

   #dmesg -c /* this clears kernel ring buffer */
   #echo 3 > /proc/fs/cifs/cifsFYI /* Enables additional debugging */
   <do the operation>
   #dmesg > cifs-debug.txt
   Attach cifs-debug.txt

• If you encounter mount/umount issues, please provide the following information:

   - Output of `mount' command and/or `cat /etc/mtab'
   - mount -vV (gives version)
   - If mount fails, attach strace output taken during mount operation