Hi, after upgrading from 4.19 to 4.20 I see lots of PANIC errors in log.smbd. I see it every time I'm trying to write a file into samba share using Dolphin. [2025/02/02 16:56:09.823293, 0] ../../lib/util/fault.c:193(smb_panic_log) PANIC (pid 8625): async open timeout in 4.20.7 [2025/02/02 16:56:09.827129, 0] ../../lib/util/fault.c:304(log_stack_trace) BACKTRACE: 20 stack frames: #0 0x3645750f6ec7 <log_stack_trace+0x37> at /usr/local/lib/samba4/private/libgenrand-private-samba.so #1 0x3645750f6f9e <smb_panic+0xe> at /usr/local/lib/samba4/private/libgenrand-private-samba.so #2 0x36456b707b24 <smbd_exit_server+0x1b4> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so #3 0x36456b707981 <smbd_exit_server+0x11> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so #4 0x364575394bcc <exit_server+0x1c> at /usr/local/lib/samba4/private/libsmbd-shim-private-samba.so #5 0x36456b6b2b10 <delete_all_streams> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so #6 0x364575935dff <tevent_common_invoke_timer_handler+0x18f> at /usr/local/lib/libtevent.so.0 #7 0x364575935fa4 <tevent_common_loop_timer_delay+0x94> at /usr/local/lib/libtevent.so.0 #8 0x3645759337c5 <tevent_context_same_loop+0xb15> at /usr/local/lib/libtevent.so.0 #9 0x36457592f36a <_tevent_loop_once+0xea> at /usr/local/lib/libtevent.so.0 #10 0x36457592f5f2 <tevent_common_loop_wait+0x32> at /usr/local/lib/libtevent.so.0 #11 0x36456b6cd34b <smbd_process+0x83b> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so #12 0x363d4788f9bd <main+0x42fd> at /usr/local/sbin/smbd #13 0x36457593067e <tevent_common_invoke_fd_handler+0x9e> at /usr/local/lib/libtevent.so.0 #14 0x364575933a44 <tevent_context_same_loop+0xd94> at /usr/local/lib/libtevent.so.0 #15 0x36457592f36a <_tevent_loop_once+0xea> at /usr/local/lib/libtevent.so.0 #16 0x36457592f5f2 <tevent_common_loop_wait+0x32> at /usr/local/lib/libtevent.so.0 #17 0x363d4788df3f <main+0x287f> at /usr/local/sbin/smbd #18 0x363d4788cbac <main+0x14ec> at /usr/local/sbin/smbd #19 0x36457742ac3a <__libc_start1+0x12a> at /lib/libc.so.7
I had the same thing, and I'm pretty sure that it's caused by one of the high numbered patches (0099, 0100, 0101, or 0102), all of which I disabled and then stuff began to work. Did not delve much further. I've been running 4.20, 4.21, and now even 4.22rc1 without those and no complaints with my setup.
(In reply to Raivo Hool from comment #1) > caused by one of the high numbered patches (0099, 0100, 0101, or 0102), > all of which I disabled and then stuff began to work 0099 is already excluded by port's Makefile. Without 0102 the build is failed. I tried to build it without 0100 and 0101 (and with 0102). It started, but when I tried to open a share in Dolphin I'm getting The file or folder smb://nas/data does not exist. and empty view. Could you share your smb4.conf?
(In reply to Denis Shaposhnikov from comment #2) Careful now; patch 0100 is the one that fixed time machine for 4.19: https://cgit.freebsd.org/ports/commit/?id=aa8c5beb655f79c21e6ec7837b4b669919fcb89f
I can confirm - Samba 4.20.7_1, FreeBSD 14.2-Release Both AD member and standalone. No successful write on ZFS residing shares. I couldn't test if this depends on the file system type. Feb 11 21:47:58 leo smbd[4373]: =============================================================== Feb 11 21:47:58 leo smbd[4373]: [2025/02/11 21:47:58.809493, 0] ../../lib/util/fault.c:185(smb_panic_log) Feb 11 21:47:58 leo smbd[4373]: INTERNAL ERROR: async open timeout in smbd () (client [ip]) pid 4373 (4.20.7) Feb 11 21:47:58 leo smbd[4373]: [2025/02/11 21:47:58.809520, 0] ../../lib/util/fault.c:190(smb_panic_log) Feb 11 21:47:58 leo smbd[4373]: If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting Feb 11 21:47:58 leo smbd[4373]: [2025/02/11 21:47:58.809534, 0] ../../lib/util/fault.c:191(smb_panic_log) Feb 11 21:47:58 leo smbd[4373]: =============================================================== Feb 11 21:47:58 leo smbd[4373]: [2025/02/11 21:47:58.809550, 0] ../../lib/util/fault.c:193(smb_panic_log) Feb 11 21:47:58 leo smbd[4373]: PANIC (pid 4373): async open timeout in 4.20.7 Feb 11 21:47:58 leo smbd[4373]: [2025/02/11 21:47:58.810322, 0] ../../lib/util/fault.c:304(log_stack_trace) Feb 11 21:47:58 leo smbd[4373]: BACKTRACE: 20 stack frames: Feb 11 21:47:58 leo smbd[4373]: #0 0x1599756ebec7 <log_stack_trace+0x37> at /usr/local/lib/samba4/private/libgenrand-private-samba.so Feb 11 21:47:58 leo smbd[4373]: #1 0x1599756ebf9e <smb_panic+0xe> at /usr/local/lib/samba4/private/libgenrand-private-samba.so Feb 11 21:47:58 leo smbd[4373]: #2 0x159969c62b14 <smbd_exit_server+0x1b4> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so Feb 11 21:47:58 leo smbd[4373]: #3 0x159969c62971 <smbd_exit_server+0x11> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so Feb 11 21:47:58 leo smbd[4373]: #4 0x1599751a5bcc <exit_server+0x1c> at /usr/local/lib/samba4/private/libsmbd-shim-private-samba.so Feb 11 21:47:58 leo smbd[4373]: #5 0x159969c0daf0 <delete_all_streams> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so Feb 11 21:47:58 leo smbd[4373]: #6 0x159977e46dff <tevent_common_invoke_timer_handler+0x18f> at /usr/local/lib/libtevent.so.0 Feb 11 21:47:58 leo smbd[4373]: #7 0x159977e46fa4 <tevent_common_loop_timer_delay+0x94> at /usr/local/lib/libtevent.so.0 Feb 11 21:47:58 leo smbd[4373]: #8 0x159977e447c5 <tevent_context_same_loop+0xb15> at /usr/local/lib/libtevent.so.0 Feb 11 21:47:58 leo smbd[4373]: #9 0x159977e4036a <_tevent_loop_once+0xea> at /usr/local/lib/libtevent.so.0 Feb 11 21:47:58 leo smbd[4373]: #10 0x159977e405f2 <tevent_common_loop_wait+0x32> at /usr/local/lib/libtevent.so.0 Feb 11 21:47:58 leo smbd[4373]: #11 0x159969c2833b <smbd_process+0x83b> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so Feb 11 21:47:58 leo smbd[4373]: #12 0x1591471a89bd <main+0x42fd> at /usr/local/sbin/smbd Feb 11 21:47:58 leo smbd[4373]: #13 0x159977e4167e <tevent_common_invoke_fd_handler+0x9e> at /usr/local/lib/libtevent.so.0 Feb 11 21:47:58 leo smbd[4373]: #14 0x159977e44a44 <tevent_context_same_loop+0xd94> at /usr/local/lib/libtevent.so.0 Feb 11 21:47:58 leo smbd[4373]: #15 0x159977e4036a <_tevent_loop_once+0xea> at /usr/local/lib/libtevent.so.0 Feb 11 21:47:58 leo smbd[4373]: #16 0x159977e405f2 <tevent_common_loop_wait+0x32> at /usr/local/lib/libtevent.so.0 Feb 11 21:47:58 leo smbd[4373]: #17 0x1591471a6f3f <main+0x287f> at /usr/local/sbin/smbd Feb 11 21:47:58 leo smbd[4373]: #18 0x1591471a5bac <main+0x14ec> at /usr/local/sbin/smbd Feb 11 21:47:58 leo smbd[4373]: #19 0x15997896bc3a <__libc_start1+0x12a> at /lib/libc.so.7 Feb 11 21:47:58 leo smbd[4373]: [2025/02/11 21:47:58.810502, 0] ../../source3/lib/dumpcore.c:310(dump_core) Feb 11 21:47:58 leo smbd[4373]: unable to change to %N.core Reverting back to net/samba419 solves the problem.
Not sure if it's for the same reasons as the original poster or the commenters, but having lots of panics from smb since upgrading to 4.20 machine is a FreeBSD14.2p2, samba version: samba420-4.20.7_2 - using ZFS for the storage on which the shares reside. Feb 23 14:17:51 abch062 smbd[1453]: [2025/02/23 14:17:51.788104, 0] ../../lib/util/fault.c:178(smb_panic_log) Feb 23 14:17:51 abch062 smbd[1453]: =============================================================== Feb 23 14:17:51 abch062 smbd[1453]: [2025/02/23 14:17:51.789001, 0] ../../lib/util/fault.c:185(smb_panic_log) Feb 23 14:17:51 abch062 smbd[1453]: INTERNAL ERROR: async open timeout in smbd () (client [192.168.1.85]) pid 1453 (4.20.7) Feb 23 14:17:51 abch062 smbd[1453]: [2025/02/23 14:17:51.789073, 0] ../../lib/util/fault.c:190(smb_panic_log) Feb 23 14:17:51 abch062 smbd[1453]: If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting Feb 23 14:17:51 abch062 smbd[1453]: [2025/02/23 14:17:51.789180, 0] ../../lib/util/fault.c:191(smb_panic_log) Feb 23 14:17:51 abch062 smbd[1453]: =============================================================== Feb 23 14:17:51 abch062 smbd[1453]: [2025/02/23 14:17:51.789216, 0] ../../lib/util/fault.c:193(smb_panic_log) Feb 23 14:17:51 abch062 smbd[1453]: PANIC (pid 1453): async open timeout in 4.20.7 Feb 23 14:17:51 abch062 smbd[1453]: [2025/02/23 14:17:51.791801, 0] ../../lib/util/fault.c:304(log_stack_trace) Feb 23 14:17:51 abch062 smbd[1453]: BACKTRACE: 20 stack frames: Feb 23 14:17:51 abch062 smbd[1453]: #0 0x172979231ec7 <log_stack_trace+0x37> at /usr/local/lib/samba4/private/libgenrand-private-samba.so Feb 23 14:17:51 abch062 smbd[1453]: #1 0x172979231f9e <smb_panic+0xe> at /usr/local/lib/samba4/private/libgenrand-private-samba.so Feb 23 14:17:51 abch062 smbd[1453]: #2 0x172971185324 <smbd_exit_server+0x1b4> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so Feb 23 14:17:51 abch062 smbd[1453]: #3 0x172971185181 <smbd_exit_server+0x11> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so Feb 23 14:17:51 abch062 smbd[1453]: #4 0x172978dc5bcc <exit_server+0x1c> at /usr/local/lib/samba4/private/libsmbd-shim-private-samba.so Feb 23 14:17:51 abch062 smbd[1453]: #5 0x172971130300 <delete_all_streams> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so Feb 23 14:17:51 abch062 smbd[1453]: #6 0x17297beb4dff <tevent_common_invoke_timer_handler+0x18f> at /usr/local/lib/libtevent.so.0 Feb 23 14:17:51 abch062 smbd[1453]: #7 0x17297beb4fa4 <tevent_common_loop_timer_delay+0x94> at /usr/local/lib/libtevent.so.0 Feb 23 14:17:51 abch062 smbd[1453]: #8 0x17297beb27c5 <tevent_context_same_loop+0xb15> at /usr/local/lib/libtevent.so.0 Feb 23 14:17:51 abch062 smbd[1453]: #9 0x17297beae36a <_tevent_loop_once+0xea> at /usr/local/lib/libtevent.so.0 Feb 23 14:17:51 abch062 smbd[1453]: #10 0x17297beae5f2 <tevent_common_loop_wait+0x32> at /usr/local/lib/libtevent.so.0 Feb 23 14:17:51 abch062 smbd[1453]: #11 0x17297114ab4b <smbd_process+0x83b> at /usr/local/lib/samba4/private/libsmbd-base-private-samba.so Feb 23 14:17:51 abch062 smbd[1453]: #12 0x17214d164aad <main+0x436d> at /usr/local/sbin/smbd Feb 23 14:17:51 abch062 smbd[1453]: #13 0x17297beaf67e <tevent_common_invoke_fd_handler+0x9e> at /usr/local/lib/libtevent.so.0 Feb 23 14:17:51 abch062 smbd[1453]: #14 0x17297beb2a44 <tevent_context_same_loop+0xd94> at /usr/local/lib/libtevent.so.0 Feb 23 14:17:51 abch062 smbd[1453]: #15 0x17297beae36a <_tevent_loop_once+0xea> at /usr/local/lib/libtevent.so.0 Feb 23 14:17:51 abch062 smbd[1453]: #16 0x17297beae5f2 <tevent_common_loop_wait+0x32> at /usr/local/lib/libtevent.so.0 Feb 23 14:17:51 abch062 smbd[1453]: #17 0x17214d16302f <main+0x28ef> at /usr/local/sbin/smbd Feb 23 14:17:51 abch062 smbd[1453]: #18 0x17214d161c2c <main+0x14ec> at /usr/local/sbin/smbd Feb 23 14:17:51 abch062 smbd[1453]: #19 0x17297cd75c3a <__libc_start1+0x12a> at /lib/libc.so.7 Feb 23 14:17:51 abch062 smbd[1453]: [2025/02/23 14:17:51.792431, 0] ../../source3/lib/dumpcore.c:310(dump_core) Feb 23 14:17:51 abch062 smbd[1453]: unable to change to %N.core Feb 23 14:17:51 abch062 smbd[1453]: refusing to dump core
(In reply to ctineo from comment #5) smb4.conf below: [Global] server string = ABCH062 netbios name = ABCH062 workgroup = WORKGROUP encrypt passwords = yes name resolve order = wins bcast unix extensions = No map to guest = Bad Password security = user vfs objects = fruit streams_xattr fruit:metadata = stream fruit:model = MacSamba fruit:posix_rename = yes fruit:veto_appledouble = no fruit:nfs_aces = no fruit:zero_file_id = yes fruit:wipe_intentionally_left_blank_rfork = yes fruit:delete_empty_adfiles = yes fruit:resource = stream case sensitive = No map archive = No ea support = yes dos charset = CP437 unix charset = UTF-8 min protocol = SMB2 # acl check permissions = yes inherit acls = yes csc policy = disable store dos attributes = yes dos filemode = no map read only = no # aio read size = 16384 # aio write size = 16384 create mask = 0777 force create mode = 0777 directory mask = 0777 force directory mode = 0777 client signing = disabled server signing = disabled client ipc signing = disabled [Local] path = "/Pool/Local/" printable = no aio write size = 0 veto files = /.snapshot/.windows/.mac/.zfs/ writeable = yes browseable = yes access based share enum = yes hide dot files = yes guest ok = no nfs4:mode = special nfs4:acedup = merge nfs4:chown = true zfsacl:acesort = dontcare mangled names = no valid users = cedric write list = cedric
I have the same thing on a server (14.2, ZFS), with a trivial map-all-guest kinda config. It caused a lot of guest access to hang, as well as dumping the panics in the log. The various 'aio X size' params sound like they should have some affect, but even with them set to 0 (presumptively disabling asyncness) it still happens. Downgrading to Samba 4.19 works fine.
(In reply to Craig Leres from comment #3) I can confirm the cause for this lies in 0100-Fix-pathref-handling-for-FreeBSD-13plus_samba42x.patch. I did a simple test: _ run Samba 4.20 from the port; _ used smbclient to connect (RW guest share, no VFS, nothing fancy); _ "put" a file; _ smbd fails. Removing the above patch (and obviously recompiling) fixes this simple case. I haven't conducted more thorough testings yet. In any case I don't have a Mac and cannot try Time Machine. Notice the same patch is quite different in 4.19 and 4.20. Specifically the one for 4.20 includes a fragment which is not present in 4.19: diff -Naurp a/source3/smbd/open.c b/source3/smbd/open.c --- a/source3/smbd/open.c 2024-08-02 07:54:09.637892500 -0400 +++ b/source3/smbd/open.c 2024-08-05 21:27:26.052148000 -0400 @@ -1165,47 +1165,52 @@ static NTSTATUS reopen_from_fsp(struct files_struct *d bool *p_file_created) { NTSTATUS status; + int new_fd; int old_fd; - if (fsp->fsp_flags.have_proc_fds && - ((old_fd = fsp_get_pathref_fd(fsp)) != -1)) { + old_fd = fsp_get_pathref_fd(fsp); + if (old_fd == -1) { + return NT_STATUS_MORE_PROCESSING_REQUIRED; + } ... I followed both Samba 4.19 and 4.20 in GDB and both arrive at reopen_from_fsp with fsp->fh->fd==-1. However the above makes 4.20 bail out with NT_STATUS_MORE_PROCESSING_REQUIRED, while 4.19 goes on and creates the file. Unfortunately I have no idea why this was added, so, maybe, this is expected and some other code should compensate later?
(In reply to ml from comment #8) Before patch 0100, samba419 would let you *create* a file but not *rename* it. I don't have time to test it now but this was the simplest failure case I could find: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281360#c1 m2 46 % touch frob m2 47 % rm frob rm: frob: Operation not supported It's a shame upstream doesn't have a test for this.
I'm having the same issue on my newly created virtual FreeBSD machine: #uname -a FreeBSD VM-FreeBSD-TS 14.2-RELEASE FreeBSD 14.2-RELEASE releng/14.2-n269506-c8918d6c7412 GENERIC amd64 I've reverted from samba420 to samba419 without changing any of my config files and it is all working now! Samba420 crashed on me when I've tried to create a new file from windows. Creating a new folder worked. Also editing or deleting existing files did work.
Created attachment 260194 [details] Attempt at a fix I'm attaching a patch that makes Samba 4.20 work (so far) for me. I've tested it succesfully with smbclient and a Windows 10 client with my usual workload (mainly compilation). I did NOT test it with Mac clients and or vfs_fruit; I'll probably be able to do it in a not so near future (although I won't test TimeMachine). I didn't even test ACLs (which, right now, I'm not using). I just guess "working in some cases" is better than "never working". Notice my changes were aimed at fixing file creation, altering the 0100 patch as little as possible, since, as I said, I don't undertand it fully. So I really wish someone with better Samba insight would check this... Anyway, feel free to use it at your own risk.