From nobody Thu Dec 07 10:55:41 2023 X-Original-To: ports-bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SmB593mNgz541wb for ; Thu, 7 Dec 2023 10:55:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SmB5904p4z3H82 for ; Thu, 7 Dec 2023 10:55:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1701946541; a=rsa-sha256; cv=none; b=kywwhIFyiR3n65Nxqxcl5MyecX86FaUXf045tP+1B+pOEsFR8YWzWLgQtZRj4vp6jpkFcR WqTVGajBj8eMYopW8NZafGNWqaNHSWmqjFG2MZQ0rTmD0awTRz2Yxd9/baPdsRh0DAE3Bo 1RdysIvVyiL+va28m4+WYwOmbR86TIpyh+7XsndAmBmXExETSxJbkxecyr/kBY3gSVGtzd 85b8wDm5UTiDdUZfEWLNk1VNEAEdZChOZUTkPr6Q6B/ne8t7JCI4YFyosEz7m6BjahgmLM w/vfUFcB+4VFlomSRSAHZh9OTHBwu74awN6Yuu+XJEp2BrjT52NpFIvIg3VQ8w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1701946541; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Yc2VZKL4KXRLTbl4WYQGuPeGwaMleOTFzKWqnt0LQ2Y=; b=r37NRaU7gH6poGxqCEEQ42s1wdWIGIEpKmtx92y0z9hY+HcMp7+KHPuC5M5N5/naWKQ5BF KvUcxGzKTfvq0PaS/wnDZBjf2unfzUo718UjbdLoVHWKqnE+QXXnX18QZ/ItcrXR2RQVbo 20lQLypmEL7+rCbt9mUA7dNSGlYIU+Cf/tEEDsM5V0aQMLn7d4Tr8hbUw3vNlglxrBAo+R kaueXBtO9dJZfDZyoYldX7EK9L0G+0Opm8abY4Zc2xQK8XUyyDiyNMxqCZiuF6skrxjN3Q khV+zMzPUguASzQT8omTfGIxF5R5mjJvXed4h/mGtmWbMC+LxTSoN+l8x2ZR2Q== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4SmB586HvxzYhZ for ; Thu, 7 Dec 2023 10:55:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3B7AtehH029045 for ; Thu, 7 Dec 2023 10:55:40 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3B7Ate7w029044 for ports-bugs@FreeBSD.org; Thu, 7 Dec 2023 10:55:40 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 275597] Samba: smbd sometimes aborts by PANIC when 'vfs objects = cap' Date: Thu, 07 Dec 2023 10:55:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: uratan@miomio.jp X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ports-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Ports bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-ports-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports-bugs@freebsd.org X-BeenThere: freebsd-ports-bugs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275597 Bug ID: 275597 Summary: Samba: smbd sometimes aborts by PANIC when 'vfs objects =3D cap' Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: ports-bugs@FreeBSD.org Reporter: uratan@miomio.jp Created attachment 246852 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D246852&action= =3Dedit dmesg output of evaluating 14.0R I started evaluating FreeBSD 14.0R(i386) for use as my home server. And I have noticed that Samba: smbd often aborts abnormally like below. +---------------------------- |Dec 4 13:06:58 oxygen smbd[10655]: [2023/12/04 13:06:58.286037, 0] ../../lib/util/fault.c:172(smb_panic_log) |Dec 4 13:06:58 oxygen smbd[10655]:=20=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |Dec 4 13:06:58 oxygen smbd[10655]: [2023/12/04 13:06:58.307281, 0] ../../lib/util/fault.c:176(smb_panic_log) |Dec 4 13:06:58 oxygen smbd[10655]: INTERNAL ERROR: Signal 11: Segmentation fault in pid 10655 (4.16.11) |Dec 4 13:06:58 oxygen smbd[10655]: [2023/12/04 13:06:58.307391, 0] ../../lib/util/fault.c:181(smb_panic_log) |Dec 4 13:06:58 oxygen smbd[10655]: If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versi= ons, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting |Dec 4 13:06:58 oxygen smbd[10655]: [2023/12/04 13:06:58.307505, 0] ../../lib/util/fault.c:182(smb_panic_log) |Dec 4 13:06:58 oxygen smbd[10655]:=20=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |Dec 4 13:06:58 oxygen smbd[10655]: [2023/12/04 13:06:58.307601, 0] ../../lib/util/fault.c:184(smb_panic_log) |Dec 4 13:06:58 oxygen smbd[10655]: PANIC (pid 10655): Signal 11: Segmentation fault in 4.16.11 |Dec 4 13:06:58 oxygen smbd[10655]: [2023/12/04 13:06:58.370441, 0] ../../lib/util/fault.c:245(log_stack_trace) |Dec 4 13:06:58 oxygen smbd[10655]: BACKTRACE: |Dec 4 13:06:58 oxygen smbd[10655]: #0 log_stack_trace + 0x43 [ip=3D0x203e84d3] [sp=3D0xffbfd35c] |Dec 4 13:06:58 oxygen smbd[10655]: #1 smb_panic_log + 0x6c [ip=3D0x203e835c] [sp=3D0xffbfd96c] |Dec 4 13:06:58 oxygen smbd[10655]: #2 smb_panic + 0x1a [ip=3D0x203e8= 6da] [sp=3D0xffbfd980] |Dec 4 13:06:58 oxygen smbd[10655]: #3 fault_setup + 0xae [ip=3D0x203= e82ee] [sp=3D0xffbfd994] |Dec 4 13:06:58 oxygen smbd[10655]: #4 _pthread_sigmask + 0x5c9 [ip=3D0x21162db9] [sp=3D0xffbfda2c] |Dec 4 13:06:59 oxygen smbd[10655]: #5 _pthread_setschedparam + 0x969 [ip=3D0x21162289] [sp=3D0xffbfdd40] |Dec 4 13:06:59 oxygen smbd[10655]: #6 [ip=3D0xffbff= 004] [sp=3D0xffbfdd80] |Dec 4 13:06:59 oxygen smbd[10655]: #7 vfs_readdirname + 0x56 [ip=3D0x2019ea46] [sp=3D0xffbfe15c] |Dec 4 13:06:59 oxygen smbd[10655]: #8 ReadDirName + 0x111 [ip=3D0x201396f1] [sp=3D0xffbfe18c] |Dec 4 13:06:59 oxygen smbd[10655]: #9 smbd_dirptr_get_entry + 0x161 [ip=3D0x20137f81] [sp=3D0xffbfe1c8] |Dec 4 13:06:59 oxygen smbd[10655]: #10 smbd_dirptr_lanman2_entry + 0= x151 [ip=3D0x2016f231] [sp=3D0xffbfe350] |Dec 4 13:06:59 oxygen smbd[10655]: #11 smbd_smb2_request_process_query_directory + 0xd9b [ip=3D0x201dbadb] [sp=3D0xffbfe480] |Dec 4 13:06:59 oxygen smbd[10655]: #12 smbd_smb2_request_process_query_directory + 0x884 [ip=3D0x201db5c4] [sp=3D0xffbfe578] |Dec 4 13:06:59 oxygen smbd[10655]: #13 smbd_smb2_request_dispatch + 0xce4 [ip=3D0x201c4834] [sp=3D0xffbfe604] |Dec 4 13:06:59 oxygen smbd[10655]: #14 smbd_smb2_process_negprot + 0x244a [ip=3D0x201c9cba] [sp=3D0xffbfe678] |Dec 4 13:07:00 oxygen smbd[10655]: #15 tevent_common_invoke_fd_handl= er + 0x8b [ip=3D0x2056b64b] [sp=3D0xffbfe6cc] |Dec 4 13:07:00 oxygen smbd[10655]: #16 tevent_context_same_loop + 0x= dd2 [ip=3D0x2056e612] [sp=3D0xffbfe6f4] |Dec 4 13:07:00 oxygen smbd[10655]: #17 _tevent_loop_once + 0xcf [ip=3D0x2056a5af] [sp=3D0xffbfe740] |Dec 4 13:07:00 oxygen smbd[10655]: #18 tevent_common_loop_wait + 0x2f [ip=3D0x2056a7bf] [sp=3D0xffbfe768] |Dec 4 13:07:00 oxygen smbd[10655]: #19 _tevent_loop_wait + 0x1c [ip=3D0x2056a84c] [sp=3D0xffbfe784] |Dec 4 13:07:00 oxygen smbd[10655]: #20 smbd_process + 0x795 [ip=3D0x201b2205] [sp=3D0xffbfe798] |Dec 4 13:07:00 oxygen smbd[10655]: #21 main + 0x4670 [ip=3D0xe690] [sp=3D0xffbfe7fc] |Dec 4 13:07:00 oxygen smbd[10655]: #22 tevent_common_invoke_fd_handl= er + 0x8b [ip=3D0x2056b64b] [sp=3D0xffbfe8b4] |Dec 4 13:07:00 oxygen smbd[10655]: #23 tevent_context_same_loop + 0x= dd2 [ip=3D0x2056e612] [sp=3D0xffbfe8dc] |Dec 4 13:07:00 oxygen smbd[10655]: #24 _tevent_loop_once + 0xcf [ip=3D0x2056a5af] [sp=3D0xffbfe924] |Dec 4 13:07:01 oxygen smbd[10655]: #25 tevent_common_loop_wait + 0x2f [ip=3D0x2056a7bf] [sp=3D0xffbfe94c] |Dec 4 13:07:01 oxygen smbd[10655]: #26 _tevent_loop_wait + 0x1c [ip=3D0x2056a84c] [sp=3D0xffbfe968] |Dec 4 13:07:01 oxygen smbd[10655]: #27 main + 0x2ab9 [ip=3D0xcad9] [sp=3D0xffbfe97c] |Dec 4 13:07:01 oxygen smbd[10655]: #28 main + 0x15e9 [ip=3D0xb609] [sp=3D0xffbfe9a0] |Dec 4 13:07:01 oxygen smbd[10655]: #29 __libc_start1 + 0x155 [ip=3D0x205e38c5] [sp=3D0xffbfebcc] |Dec 4 13:07:01 oxygen smbd[10655]: #30 _start + 0x36 [ip=3D0x9d06] [sp=3D0xffbfebf0] |Dec 4 13:07:01 oxygen smbd[10655]: [2023/12/04 13:07:01.547212, 0] ../../source3/lib/dumpcore.c:310(dump_core) |Dec 4 13:07:01 oxygen smbd[10655]: unable to change to %N.core |Dec 4 13:07:01 oxygen smbd[10655]: refusing to dump core +---------------------------- The various environments and configurations are as follows: (hostname is 'oxygen' and using i386 architecture) +---------------------------- |% uname -a |FreeBSD oxygen 14.0-RELEASE FreeBSD 14.0-RELEASE #3: Mon Nov 27 22:32:52= JST 2023 uratan@oxygen:/usr/src/sys/i386/compile/OXYGEN i386 | |% pkg info | grep samba |samba416-4.16.11 Free SMB/CIFS and AD/DC server and client for Unix +---------------------------- (essence of) /usr/local/etc/smb4.conf +---------------------------- |[global] | workgroup =3D METXXXXX | server string =3D Samba Server | local master =3D no | security =3D user | map to guest =3D Bad User | load printers =3D yes | printing =3D bsd | printcap cache time =3D 0 | unix charset =3D cp932 | dos charset =3D cp932 | server role =3D standalone server | hosts allow =3D 10. | guest account =3D nobody | log file =3D /var/log/samba4/log.%m | max log size =3D 50 | dns proxy =3D no | |[printers] | comment =3D All Printers | path =3D /var/spool/samba4 | browsable =3D no | guest ok =3D no | writeable =3D no | printable =3D yes | |[maindish] | comment =3D exported for PC | path =3D /home | vfs objects =3D cap | browseable =3D yes | guest ok =3D yes | guest only =3D yes | writeable =3D yes | create mask =3D 0775 | directory mask =3D 0775 +---------------------------- (essence of) /etc/rc.conf +---------------------------- |samba_server_enable=3D"YES" |nmbd_enable=3D"NO" |smbd_enable=3D"YES" |winbindd_enable=3D"NO" +---------------------------- Confirm attached file: dmesg-today.txt for misc hardware environments. note: re0 driver is replaced by RealTek's to avoid 'watchdog timeout'. (rtl_bsd_drv_v199.04.tgz from =20 https://www.realtek.com/ja/component/zoo/category/network-interface-control= lers-10-100-1000m-gigabit-ethernet-pci-express-software ) It should have nothing to do with this Samba problem because, when using GENERIC kernel at first phase, samba PANIC and re0: watchdog timeout were both seen in kernel messages. I suspected watchdog timeout was the core cause at first, but it wasn't. (maybe) I am using windows7 (also x86/32bit version) as the test client, and using win32 native executable diff.exe from UnxUtils in the subsequent reports. (see https://unxutils.sourceforge.net/ for UnxUtils) +---------------------------- |U:\> ver |Microsoft Windows [Version 6.1.7601] | |U:\> diff.exe --version |diff - GNU diffutils version 2.7 | |U:\> net use |-------------------------------------------------------- |OK I: \\silver\maindish Microsoft Wi... <=3D=3D 10.2R server (samba3= 6) |OK J: \\oxygen\maindish Microsoft Wi... <=3D=3D 14.0R (samba416) | +---------------------------- hostname 'silver' is my current home server, running with FreeBSD 10.2R (i386). +---------------------------- |% uname -a |FreeBSD silver 10.2-RELEASE FreeBSD 10.2-RELEASE #1: Sun Mar 12 09:07:49= JST 2017 uratan@silver:/usr/src/sys/i386/compile/OXYGEN i386 | |% pkg info | grep samba |samba36-3.6.25_1 Free SMB and CIFS client and server for Unix +---------------------------- (10.2R ? Win7 ? i386 ? The reason why various things are all outdated) (is because I am an old man also outdated who strongly likes stability.) - * - * - Show the error situation at first. (Please note the difference in drive letter i: or j:) "x:\win\Hardwares" has: 1454 dirs 9644 files 144GB in total. These errors reported are caused by smbd PANIC abort. The error files/dirs are different for each run. There is NO error that says the file contents are different. +---------------------------- |U:\> diff -rq i:\win\Hardwares j:\win\Hardwares |diff: j:\win\Hardwares\N3x50B\someDir_1: Invalid argument |diff: j:\win\Hardwares\N3x50B\someDir_4444\igdlh.cat: No such file or directory |diff: j:\win\Hardwares\T100Chi\someDir_777: Invalid argument | |U:\> diff -rq j:\win\Hardwares i:\win\Hardwares |diff: j:\win\Hardwares\ATerm\someDir_88: Invalid argument |diff: j:\win\Hardwares\N3x50B\someDir_4444\igdlh.cat: No such file or directory |diff: j:\win\Hardwares\ScanSnap\someDir_6666: Invalid argument |diff: j:\win\Hardwares\T100Chi\someDir_777: Invalid argument +---------------------------- - * - * - I also tried another version of samba: samba413-4.13.17_6.pkg but the situation was the same, smbd aborts, too. I analyzed the PANIC abort logs left in the /var/log/messages from beginning of the evaluation to today. There are 54 logs in total by both version of samba. See the summary of BACKTRACEs below, the intermediate flow is slightly different, but the flow to PANIC abort seems to be almost same. The is very suspicious and, I think, the failure of ReadDirName() or vfs_readdirname() are not so far, I think, from the errors reported by diff.exe: "Invalid argument" or "No such file or directory". -------------------------------------------------------------------------= ---- | 25 times by samba416 | 29 times by samba413 ----25times----------------COMMON FLOW----------29times-----------------= ---- | _start + 0x36 | _start + 0x36 | __libc_start1 + 0x155 | __libc_start1 + 0x155 | main + 0x15e9 | main + 0x199d | main + 0x2ab9 | main + 0x2db9 | _tevent_loop_wait + 0x1c | _tevent_loop_wait + 0x1c | tevent_common_loop_wait + 0x2f | tevent_common_loop_wait + 0x= 2f | _tevent_loop_once + 0xcf | _tevent_loop_once + 0xcf | tevent_context_same_loop + 0xdd2 | tevent_context_same_loop + 0= xdd2 | tevent_common_invoke_fd_handler + 0x8b | tevent_common_invoke_fd_hand= ler + 0x8b | main + 0x4670 | main + 0x4925 | smbd_process + 0x795 | smbd_process + 0x79b | _tevent_loop_wait + 0x1c | _tevent_loop_wait + 0x1c | tevent_common_loop_wait + 0x2f | tevent_common_loop_wait + 0x= 2f | _tevent_loop_once + 0xcf | _tevent_loop_once + 0xcf | tevent_context_same_loop + 0xdd2 | tevent_context_same_loop + 0= xdd2 | tevent_common_invoke_fd_handler + 0x8b | tevent_common_invoke_fd_hand= ler + 0x8b | smbd_smb2_process_negprot + 0x244a | smbd_smb2_process_negprot + 0x237a | smbd_smb2_request_dispatch + 0xXXX | smbd_smb2_request_dispatch + 0xXXX =20=20=20 ----15times----------------FLOW-CASE-A-----------6times--------------------- A smbd_smb2_request_process_create ( smbd_smb2_request_process_create A smbd_smb2_request_process_create ( smbd_smb2_request_process_create A filename_convert ( filename_convert A ( filename_convert A unix_convert 2 ( unix_convert A get_real_filename_full_scan ( get_real_filename_full_scan ----10times----------------FLOW-CASE-B----------23times------------------= --- B smbd_smb2_request_process_query_directory( smbd_smb2_request_process_query_directory B smbd_smb2_request_process_query_directory( smbd_smb2_request_process_query_directory B smbd_dirptr_lanman2_entry ( smbd_dirptr_lanman2_entry B smbd_dirptr_get_entry ( smbd_dirptr_get_entry B ( can_delete_directory_fsp ----25times----------------COMMON FLOW----------29times-----------------= ---- | ReadDirName + 0x111 | ReadDirName + 0x10b | vfs_readdirname + 0x56 | vfs_readdirname + 0x53 | | | _pthread_setschedparam + 0x969 | _pthread_setschedparam + 0x9= 69 | _pthread_sigmask + 0x5c9 | _pthread_sigmask + 0x5c9 | fault_setup + 0xae | fault_setup + 0xae | smb_panic + 0x1a | smb_panic + 0x1a | smb_panic_log + 0x6c | smb_panic_log + 0x6c | log_stack_trace + 0x43 | log_stack_trace + 0x43 -------------------------------------------------------------------------= ---- - * - * - To narrow down the factors, I added one more share for debug to /usr/local/etc/smb4.conf. This share is same as [maindish] except the configuration "vfs object". (and "comment") +---------------------------- |[m2-test] | comment =3D test | path =3D /home |; vfs objects =3D cap | browseable =3D yes | guest ok =3D yes | guest only =3D yes | writeable =3D yes | create mask =3D 0775 | directory mask =3D 0775 +---------------------------- Now they are seen like below from Win7 client. +---------------------------- |U:\> net use |-------------------------------------------------------- |OK I: \\silver\maindish Microsoft Wi... <=3D=3D 10.2R server (samba3= 6) |OK J: \\oxygen\maindish Microsoft Wi... <=3D=3D 14.0R (samba416, vfs object=3Dcap) |OK K: \\oxygen\m2-test Microsoft Wi... <=3D=3D 14.0R (samba416, NO = vfs object) +---------------------------- See the result of the test below. "x:\win\Hardwares\N3x50B" has: 622 dirs 3356 files 3.1GB in total. (I chose an area that did not contain Japanese file names.) (Please note the difference in drive letter i:, j: or k:) There, No error is reported when using drive k:. So 'vfs objects =3D cap' has the key of the BUG I think. I've gotten the obvious response and ... an unfortunate fact that a error reported from drive i: !!! "WAO NANTTE KOTTAI" (means "Oh my god !" or "what's the hell" in Japanese) +---------------------------- |U:\> diff -rq i:\win\Hardwares\N3x50B j:\win\Hardwares\N3x50B |diff: j:\win\Hardwares\N3x50B\someDir_22: Invalid argument |diff: j:\win\Hardwares\N3x50B\someDir_333: Invalid argument | |U:\> diff -rq i:\win\Hardwares\N3x50B j:\win\Hardwares\N3x50B |diff: j:\win\Hardwares\N3x50B\someDir_1: Invalid argument | |U:\> diff -rq i:\win\Hardwares\N3x50B k:\win\Hardwares\N3x50B | |U:\> diff -rq i:\win\Hardwares\N3x50B k:\win\Hardwares\N3x50B | |U:\> diff -rq i:\win\Hardwares\N3x50B j:\win\Hardwares\N3x50B |diff: j:\win\Hardwares\N3x50B\someDir_1: Invalid argument **|diff: i:\win\Hardwares\N3x50B\someDir_22: Invalid argument |diff: j:\win\Hardwares\N3x50B\someDir_333\libmfxhw32.dll: No such file or directory |diff: j:\win\Hardwares\N3x50B\someDir_55555\igdusc32.dll: No such file or directory | |U:\> diff -rq i:\win\Hardwares\N3x50B k:\win\Hardwares\N3x50B |U:\> +---------------------------- - * - * - I trusted my current home server silver(10.2R) because it works well for about 8 years. However, 74 smbd abortion logs are found in the /var/log/messages and "Subject: silver daily security run output" mails to root. But I have never felt that my files were lost. +---------------------- |2016-03-21 03:01:25 (smbd) on signal 6 : : **|2023-12-05 22:21:02 silver kernel: pid 90073 (smbd), uid 0: exited on signal 6 +---------------------- The configuration of samba36 is almost same as samba416 because smb4.conf inherited smb.conf of smaba36, except mainly below: +---------------------- smb4.conf | security =3D user | map to guest =3D Bad User +---------------------- smb.conf for samba36 on silver | security =3D share +---------------------- Also, silver is running on same motherboard to oxygen. (except number of CPU core, silver is 2 and oxygen is 4) - * - * - Aside from that, I have issued same test with replacing charset configuration to: +---------------------------- | unix charset =3D ascii | dos charset =3D ascii +---------------------------- The result is same, smbd aborts only when "vfs objects =3D cap". - * - * - CONCLUSION I think... Samba smbd with configuration 'vfs objects =3D cap' must have a bug near vfs_readdirname() from version 3.xx potentially, and it is exposed when some timing condition is match. The cap function is necessary for for my home server. Someone help me ! - * - * - From here, I would like to state my feelings, etc at last. (a) Why "I have never felt that my files were lost." ? Because it seems that Explorer.exe retries so seriously against any errors in the copy operation both src/dst direction. (So this problem does not become so critical because of this.) (Actually, it may not do any real harm to me either....except) (I'll be surprised when I look at the /var/log/messages....) (b) This PANIC abort occurs rather high frequency when: (b1) just after starting copy from Expoloer.exe (b2) issuing "Properties" from Explorer.exe (It seems that, Unlike in the case of copy, NO retries are) (made while "Properties", so it reports less capacities or ) (number of files if the PANIC abort occurs while counting up) In both case, Explorer.exe scans only directories to gather infos without access to the file contents itself. High density of the repeated request to the directories is the trigger of this problem, I think. For example... like this... +---------------------------- | initial_jobs(); | while(1) { | /* ready */ | wait_for_request(); | exec_the_request(); | answer_the_request(); /* because the client gets answer at here */ | post_jobs_for_ready(); /* next request may be arrived while here */ | } /* before returning to ready... */ +---------------------------- p.s. I noticed just NOW, that the depth of the directory hierarchy might have something to do with the problem, so I have also attached a file: list-of-err-files.txt which has a list of the actual full path names where the error occurred. --=20 You are receiving this mail because: You are the assignee for the bug.=