Unfortunately, some UNIXes (in particular some recent Linux kernels) refuse to dump a core file if the task has changed UID (which smbd does often). To debug with this sort of system, you could try to attach to the running process using gdb smbd PID , where you get PID from smbstatus. Then use c to continue and try to cause the core dump using the client. The debugger should catch the fault and tell you where it occurred.

Sometimes it is necessary to build Samba binary files that have debugging symbols so as to make it possible to capture enough information from a crashed operation to permit the Samba Team to fix the problem.

Compile with -g to ensure you have symbols in place. Add the following line to the smb.conf file global section:

panic action = "/bin/sleep 90000"

to catch any panics. If smbd seems to be frozen, look for any sleep processes. If it is not, and appears to be spinning, find the PID of the spinning process and type:

root#  gdb /usr/local/samba/sbin/smbd

then “attach `pid'” (of the spinning process), then type “bt” to get a backtrace to see where the smbd is in the call path.