Univention Bugzilla – Bug 56383
Copying many small files from Windows 10 to Samba/AD aborts due to a Samba panic
Last modified: 2023-08-23 14:54:17 CEST
In Ticket#2023070521000235 we backtraces like these in log.smbd: ============ [2023/07/18 11:29:16.564491, 0, pid=28273] ../../lib/util/fault.c:185(smb_panic_log) PANIC (pid 28273): Signal 6: Abgebrochen in 4.18.3-Univention [2023/07/18 11:29:16.564785, 0, pid=28273] ../../lib/util/fault.c:293(log_stack_trace) BACKTRACE: 38 stack frames: #0 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(log_stack_trace+0x30) [0x7f3e9047a690] #1 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(smb_panic+0x9) [0x7f3e9047a8e9] #2 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(+0x1981) [0x7f3e9047a981] #3 /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730) [0x7f3e90424730] #4 /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b) [0x7f3e9024a8eb] #5 /lib/x86_64-linux-gnu/libc.so.6(abort+0x121) [0x7f3e90235535] #6 /lib/x86_64-linux-gnu/libheimbase.so.1(+0x816b) [0x7f3e8698e16b] #7 /lib/x86_64-linux-gnu/libpthread.so.0(+0xf997) [0x7f3e90421997] #8 /lib/x86_64-linux-gnu/libheimbase.so.1(heim_base_once_f+0x3d) [0x7f3e8698e31d] #9 /lib/x86_64-linux-gnu/libkrb5.so.26(krb5_init_context+0xe9) [0x7f3e8685a7b9] #10 /lib/x86_64-linux-gnu/security/pam_krb5.so(+0x885b) [0x7f3e87a9285b] #11 /lib/x86_64-linux-gnu/security/pam_krb5.so(+0x5f3e) [0x7f3e87a8ff3e] #12 /lib/x86_64-linux-gnu/security/pam_krb5.so(pam_sm_close_session+0xf) [0x7f3e87a9197f] #13 /lib/x86_64-linux-gnu/libpam.so.0(+0x3d14) [0x7f3e8ed4ad14] #14 /usr/lib/x86_64-linux-gnu/samba/libauth-samba4.so.0(+0xdbb3) [0x7f3e9045abb3] #15 /usr/lib/x86_64-linux-gnu/samba/libauth-samba4.so.0(smb_pam_close_session+0xa6) [0x7f3e9045b1a6] #16 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-samba4.so.0(session_yield+0x9e) [0x7f3e9089705e] #17 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-samba4.so.0(invalidate_vuid+0x40) [0x7f3e9089bd80] #18 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-samba4.so.0(smbXsrv_session_logoff+0x78) [0x7f3e9090d578] #19 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-samba4.so.0(+0xc0b84) [0x7f3e908f1b84] #20 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_invoke_immediate_handler+0x17a) [0x7f3e903f313a] #21 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_immediate+0x23) [0x7f3e903f3163] #22 /lib/x86_64-linux-gnu/libtevent.so.0(+0xf01b) [0x7f3e903f901b] #23 /lib/x86_64-linux-gnu/libtevent.so.0(+0xd2a7) [0x7f3e903f72a7] #24 /lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x91) [0x7f3e903f1f01] #25 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x7f3e903f219b] #26 /lib/x86_64-linux-gnu/libtevent.so.0(+0xd247) [0x7f3e903f7247] #27 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-samba4.so.0(smbd_process+0x830) [0x7f3e908dae90] #28 smbd: client [10.86.1.220](+0xa0be) [0x564039cdd0be] #29 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_invoke_fd_handler+0x93) [0x7f3e903f2be3] #30 /lib/x86_64-linux-gnu/libtevent.so.0(+0xf22f) [0x7f3e903f922f] #31 /lib/x86_64-linux-gnu/libtevent.so.0(+0xd2a7) [0x7f3e903f72a7] #32 /lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x91) [0x7f3e903f1f01] #33 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x7f3e903f219b] #34 /lib/x86_64-linux-gnu/libtevent.so.0(+0xd247) [0x7f3e903f7247] #35 smbd: client [10.86.1.220](main+0x1453) [0x564039cda233] #36 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f3e9023709b] #37 smbd: client [10.86.1.220](_start+0x2a) [0x564039cdaada] [2023/07/18 11:29:16.565431, 0, pid=28273] ../../source3/lib/dumpcore.c:315(dump_core) dumping core in /var/log/samba/cores/smbd ============ In that case they may have led to aborted file copies to the Marktplatz share but that could also be unrelated.
In Ticket#2023030721000677 we had a backtrace that looks similar in the top 10 stack frames (also involving the function heim_base_once_f in stack frame #8) but in that case the code path involved smb_pam_claim_session instead of smb_pam_close_session. ============ #5 /lib/x86_64-linux-gnu/libc.so.6(abort+0x121) [0x7f739eddb535] #6 /usr/lib/x86_64-linux-gnu/libheimbase.so.1(+0x816b) [0x7f7390f2616b] #7 /lib/x86_64-linux-gnu/libpthread.so.0(+0xf997) [0x7f739efc5997] #8 /usr/lib/x86_64-linux-gnu/libheimbase.so.1(heim_base_once_f+0x3d) [0x7f7390f2631d] #9 /usr/lib/x86_64-linux-gnu/libkrb5.so.26(krb5_init_context+0xe9) [0x7f7390c947b9] #10 /lib/x86_64-linux-gnu/security/pam_krb5.so(+0x885b) [0x7f7390fad85b] #11 /lib/x86_64-linux-gnu/security/pam_krb5.so(+0x5f3e) [0x7f7390faaf3e] #12 /lib/x86_64-linux-gnu/security/pam_krb5.so(pam_sm_open_session+0xd) [0x7f7390fac8cd] #13 /lib/x86_64-linux-gnu/libpam.so.0(+0x3d14) [0x7f739d995d14] #14 /usr/lib/x86_64-linux-gnu/samba/libauth-samba4.so.0(+0xdba5) [0x7f739efe4ba5] #15 /usr/lib/x86_64-linux-gnu/samba/libauth-samba4.so.0(smb_pam_claim_session+0xa9) [0x7f739efe5099] ============ In that earlier ticket the analysis of the core dump showed that the function "pthread_key_create" from libpthread exited (in the context of pam_krb5), as it didn't seem to have space left to add a certain threading-specific variable. The second common, characteristic error message in log.smbd, occurring just before the samba panic is: Error: pthread_key_create() failed, cannot continue: Die Ressource ist zur Zeit nicht verfügbar In English language that detailed error corresponds to "Resource temporarily unavailable". The man page says about this: ============ The pthread_key_create() function shall fail if: [EAGAIN] The system lacked the necessary resources to create another thread-specific data key, or the system-imposed limit on the total number of keys per process {PTHREAD_KEYS_MAX} has been exceeded. ============ During the SambaXP I had a short chat with Metze from the Samba Team about this and he pointed out that 1) Samba Heimdal is not compiled with pthread support by default and 2) that the calling /usr/lib/x86_64-linux-gnu/libheimbase.so.1 is actually from Debian-Heimdal and not Samba-Heimdal. It could be that this mix of (binary) code causes this issue and some resource (pthread keys per process) gets consumed but not released.
Ok the affected customer reported that ucr set samba/pam/restrictions=no /etc/init.d/samba restart fixes the problem, which indicates that the analysis from Comment 1 seems valid. But then home directories are not created any longer, I guess, because that's done via pam_mkhomedir.so (or univention-mount-homedir) in /etc/pam.d/common-session. It would be good if we could adjust /etc/pam.d/samba to avoid calling pam_krb5.so
https://git.knut.univention.de/univention/ucs/-/issues/1666
690b9c84a8 | Don't include common-auth in samba PAM stack (in univention-samba4) b58b30c36a | skip pam_krb5 for service samba 6f4f3e52a9 | Advisories Advisories: https://git.knut.univention.de/univention/ucs/-/commit/6f4f3e52a996d77cef2b4f4810cc695d604b905d Packages built: Package: univention-pam Version: 13.0.6-2 Branch: ucs_5.0-0 Scope: errata5.0-4 Package: univention-samba4 Version: 9.0.13-6 Branch: ucs_5.0-0 Scope: errata5.0-4
- OK univention-samba4 (9.0.13-6) - OK univention-pam (13.0.6-2) - OK manual tests - OK jenkins tests - OK yaml
(In reply to Felix Botner from comment #5) > - OK yaml FIXED: un{ -> ne}cessary
<https://errata.software-univention.de/#/?erratum=5.0x787> <https://errata.software-univention.de/#/?erratum=5.0x788>