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/
- With this approach we ensure to have the start date of the testing in the log files.
3. Edit /etc/samba/smb.conf and set the following variables in the in the [general] section of the config:
debug level = 10 debug pid = Yes max log size = 0
- Instead of setting a global debug level in smb.conf it's also visible to use
smbcontrol <damon_name> debug 10
- to increase the debug level of the Samba daemon in question to 10 at run time.
- 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.
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).
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.
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> #echo 0 > /proc/fs/cifs/cifsFYI /* Disables additional debugging */ #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
See also LinuxCIFS troubleshooting
Contributions to the cifs-utils and samba packages
We welcome contributions to the cifs-utils and samba package. The changes to the package have to be submitted via the Open Build Service (OBS).
Things to note while submitting changes:
- Please stick to the cifs-utils/samba changelog message format as this is important to provide a consistent change log that is visible to our users. The recommended method is to use "osc vc" to edit the cifs-utils.changes file. The message is generally of the form:
- Short changelog; (bnc#<bugid>) or (bso#<bugid>).
- Fix processing of open modes in POSIX open; (bnc#530683).
For more examples, have a look at the cifs-utils.changes or samba.changes files.