SAMBA BUG REPORTING ++++++++++++++++++++ Give the programmer some credit for basic intelligence: if the program really didn't work at all, they would probably have noticed. Since they haven't noticed, it must be working for them. Therefore, either you are doing something differently from them, or your environment is different from theirs. They need information; providing this information is the purpose of a bug report. More information is almost always better than less. Read more at http://www.chiark.greenend.org.uk/~sgtatham/bugs This is a small howto to help you to provide all information which are needed to find out what's going on your machine. This is a general howto so maybe it will cover more things you don't use. Providing instructions how the reproduce the error =================================================== The first aim of a bug report is to let the developer see the failure with their own eyes. If you can't be with them to make it fail in front of them, give them detailed instructions how to reproduce the problem so that they can reproduce the error on their development environment. If this doesn't work, DESCRIBE EVERYTHING IN DETAIL! The more information you provide the easier for us to understand what's going on. Here are some examples of general questions: When the daemon is running at 100%, can it still do it's normal task but slowly? Give details and describe the impact to your work and the expected behaviour/result. Is there a special event which triggers the problem? Describe how to trigger it. How many connections does the daemon have to handle? 10 or 10000 About users and groups ---------------------- In which groups is the user a member of? Do you see group information from a user who already logged in? What is the scope and the type of the group involved (Domain Local, Global or Universal)? Trusted domains --------------- Draw us a picture with http://asciiflow.com/ of your environment Here is an example: +---------------+ +---------------+ | | | | | Forest 1 | +--------------> | Forest 2 | | DOM ROOT | | DOM ROOT | | | <--------------+ | | +-------+-------+ 2-way +-------+-------+ ^ Trust ^ | | AD-JOIN +-------+-------+ +-----+-----+ | | | | | CHILD.FOREST1 | | WINBIND | | | | | +---------------+ +-----------+ Providing Samba log files ========================== Post the output of 'rpm -q samba' if you're on a RPM based system. It gives detailed information about the installed packages. We need that information to reconstruct what happened and possibly to reproduce the bug on our machines. Always provide all log files from the '/var/log/samba/' directory and the samba configuration. You can print the configuration using the 'testparm' command. If you see errors in tdb files make sure you add the related tdb files from '/var/lib/samba'. If authenticating a user is the issue please provide '/etc/security/pam_winbind.conf' and if you have enabled debug in 'pam_winbind.conf' '/var/log/messages' or '/var/log/secure' is required too. More detailed description about different Samba components can be found below this section. Providing backtraces ===================== If you discover a crash in one of the Samba components, please make sure that you have installed debuginfo packages. Often the backtrace can be found in the log files. If you have installed debuginfo packages, you can find a short backtrace in the log files and a few lines later the full backtrace. Make sure you provide the full backtrace using: (gdb) backtrace full If you're in gdb, also dump the talloc tree with: (gdb) call talloc_report_full(0, fopen("/tmp/talloc_report.log","w")) Then send the created logfile /tmp/talloc_report.log. 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 [global] section of the config: debug level = 10 debug pid = true max log size = 0 If the variable 'log file' is set it should be commented out. Please don't forget to set the debug options back to your settings or the defaults else your hard drives could be flood pretty fast with big log files. Instead of setting a global debug level in smb.conf it's also visible to use smbcontrol 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 edit /etc/security/pam_winbind.conf and set: debug = yes 4. Start the processes again (winbind, smb, nmb) 5. Reproduce the error and note the time when you start any test. !!!!! IMPORTANT !!!!! IF A PROBLEM OCCURS WHILE TESTING NOTE THE TIME AND DATE (use the 'date' command on the system you perform the tests on to get a time fitting to the log files). !!!!! IMPORTANT !!!!! 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. Network traces =============== If possible create network traces with tcpdump or wireshark from the problem and attach them too. Always make sure to capture only one problem per network trace file. This makes it easier to understand the problem. tcpdump -n -i eth0 -s 0 -w samba-problem-description.pcap Network traces should just capture which is going on between client(s) and server. So limiting the captures makes it easier to process the huge amount of information. Logfiles should match network traces. Network topology ================= If you have a special network setup especially with Active Domain controllers please describe how you're network looks like and what the domain names are. Tell us which version of Windows you're using, the functional level of AD and which trust relationships exist.