Created attachment 17162 [details] tar of relevant config and log files This is an upstream report of https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=1005721, and seems to also be https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1914420 . > What led up to the situation? Copying around 50GB consisting of 3-4MB JPG and 400MB to 4.9GB MP4 files from an SD card mounted by a Windows 10 Version 10.0.19044.1526 client over a home mesh WiFi to an AMD64 NAS running Debian 11 and smbd Version 4.13.13-Debian stored in a usershare on a ZFS filesystem. > What exactly did you do (or not do) that was effective (or ineffective)? I first tried copying a large directory from the SD card(D:\DCIM\). The Windows GUI client reported an error and asked if I wanted to try again. Trying again fixed the current file, but usually later another file failed and had to be repeated. When I tried Beyond Compare 4's directory comparison function and selected the failed files to by re-copied, and more copied, but this time I saved the error text: "An unexpected network error occurred" > What was the outcome of this action? When windows GUI client failed to copy a file, it left a zero-byte file on the NAS. When I repeated the copy with beyond-compare, most of the failed files were correctly copied and only one remained. It seems each time the "network error occurred" smbd actually crashed and left a coredump. I tried installing libc6-dbg, but after reproducing was unable to get the backtrace to resolve calls inside libc6.so.6. I reviewed the source code of volume_label() in loadparm.c - it seems the only libc function call there is a call to strcpy(), so perhaps the label pointer was NULL or otherwise invalid? I copied a total of 47.2GB split over 291 files from this SD card, I would guess I had to repeat a file at most 10 times, perhaps a failure rate around 3%. > Draw us a picture of your environment ┌──────┐ ┌───────────────────────────────┐ │LAPTOP├────┤WiFi Mesh Point and DHCP Server│ │Win 10│5ghz└──────────────────────┬────────┘ └──────┘wifi │5ghz wifi ┌───────────┐ ┌──────┴────────┐ │Debian 11 ├───────────────┤WiFi Mesh Point│ │AMD64 NAS │ 1gig eth └───────────────┘ │Samba 4.13 │ └───────────┘ I've saved a copy of the coredump, but would prefer not to post it publicly, but will share with anyone from samba.org if you like. I've hopefully attached all other relevant config and log files. Recent crashes are in var/log/samba/log.rsaxvc-laptop I believe this has been occasionally happening since I set up Debian 11 on the NAS, in late 2021, but only yesterday did it happen enough in a day to wonder why. I understand 4.13 is out of maintenance with upstream - when I have time I'll try to reproduce against samba.org master or otherwise report back. I'll try to catch it in GDB and increase the log level to 10 when I do so.
I've tried to reproduce this from a few other machines, and it only seems Windows(I tried only Windows 10) causes it. I'll also note I have two malformed usershare configs. It took a few minutes of running windirstat while copying and deleting files from a ramdisk mount, but I was able to catch this with tcpdump running on the nas. I'm not familiar with SMB2, but there appear to be requests and responses. Many times it's a request and the nas responds. But right before the connection dies with TCP reset, client sends "GetInfo Request FILE_INFO/SMB2_FILE_STANDARD_INFO File: srvsvc" and immediately "GetInfo Request FS_INFO/FileFsFullSizeInformation File:" the nas responds with a "GetInfo Response" to the first request, the client sends two more packets(a Bind and a CreateRequestFile) but the server only responds with a TCP reset. I can share the pcap privately if needed. So, it seems to be related to the "GetInfo Request FS_INFO/FileFsFullSizeInformation"
I've been seeing what appears to be same issue for probably a year on Ubuntu Server 22.04. Recently updated to 22.10 and it's still there in Samba 4.16.4 so wanted to see if there is anything I can provide to help. # smbd -V Version 4.16.4-Ubuntu Server runs an Ivy Bridge-EP Xeon, but I was seeing the same error previously on a desktop Ivy Bridge CPU. Am running ZFS (2.1.5-1ubuntu6) and smbd (4.16.4-Ubuntu) as distributed with Ubuntu Server 22.10. Network is 10GbE, and client is running Ubuntu 22.10 desktop. Am fairly certain I have seen the same issue on the M1 Mac Mini as well but cannot swear to it. This tends to happy during heavy usage and it's still fairly unusual, so guessing it may be able to happen any time but the odds are very much against it during light use. I've uploaded a pair of backtraces and my smb.conf. Happy to provide additional detail or the core files themselves if it helps.
Created attachment 17608 [details] Two backtraces plus smb.conf smb.conf contains some unused bits I was playing with long ago. Rather than take them out, I'm leaving them in just in case they have some unexpected (by me) relevance.
This is very similar to https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1817027 where the same thing happens, but with push_ucs2_talloc() rather than strlen. Thanks for all the hard work with network diagrams, but the problem is quite simple and can be deduced entirely from the code. lp_volume() at a time in the past could never return NULL, as it returned a static 'fstring'. This was changed to return allocated memory, firstly on talloc_tos() implicitly, and then on talloc_tos() explicity. Sadly this is not constant because it can contain macros, the simple fix would be to make the volume parameter unable to use smb.conf macros. However, given it uses macros, it must of course allocate memory, and any talloc() can fail to allocate at any given time. This impacts both getting the volume name and getting the volume ID, which is just the MD4 of the unicode version of the volume name.
(In reply to Allen Belletti from comment #3) Thanks so much for the backtraces, these make the problem very clear.
I forgot to mention I think the fix is to compute and store the volume name and ID at connection time, giving an error then if that fails (unlikely, as not under memory pressure then).
Created attachment 17881 [details] /proc/meminfo a few minutes after smbd was crashing
> However, given it uses macros, it must of course allocate memory, and any talloc() can fail to allocate at any given time. I'm not familiar with talloc(), but if it helps I've attached /proc/meminfo from after smbd was crashing. I have 3.8GB of memory available to the OS, with less than 10% reserved by kernel and processes. Is it possible to tell if this is caused by a system out of memory condition, or a talloc pool hitting its limit? ZFS can use a bit of memory, but I think I have all the memory intensive features disabled.
Created attachment 18642 [details] backtrace from Version 4.17.12-Debian I believe I am hitting something similar on Debian 12, Samba Version 4.17.12-Debian, zfs-2.3.1-1~bpo12+1 I can trigger it reasonably reliably after 30-40GB copied by Macrium Reflect on a Windows system to the Debian box. If this isn't the same, please let me know and I'll open another bug report with this backtrace.
Created attachment 18643 [details] log from 4.21.5-Debian-4.21.5+dfsg-1~bpo12+1 reproduced against 4.21.5-Debian-4.21.5+dfsg-1~bpo12+1
Interesting coincidence that we're all running ZFS.
Still an issue with 2:4.22.4+dfsg-1~deb13u1. I should probably create a VM and see if I can get it to happen there.
Hi there, I believe I am also encountering this issue. Intro: Like the other reports, this error is intermittent and while I can trigger it frequently through regular usage, I do not have a reproduction. I recently encountered this issue after I migrated my Obsidian Vault (i.e. folder of markdown files) to my Samba running NAS and found that the Obsidian application would close my vault a couple of times a day while I was in the middle of editing files. Upon inspecting the Samba logs I discovered a similar backtrace to corroborate previous reports and I wanted to provide it here for your records. Crucially, I believe I can show that this error is related (at least in my case) to insufficient permissions for the Samba user on the smbd host. Ensuring the Samba users on the smbd host can read the usershares directory has stopped the segmentation faults on my machine. Hopefully this offers my fellow users a fix for this issue, and potentially offers the Samba developers insight into some undesired behaviour. My NAS (Samba host): ``` $ lsb_release -a Distributor ID: Ubuntu Description: Ubuntu 24.04.2 LTS Release: 24.04 Codename: noble $ zfs --version zfs-2.2.2-0ubuntu9.1 zfs-kmod-2.2.2-0ubuntu9.2 $ smbd -V smbd 4.19.5-Ubuntu $ lscpu | grep '^Model name' Model name: AMD Ryzen 3 PRO 4350G with Radeon Graphics ``` My client is a desktop running Windows 10 (22H2, Build 19045.6466). The network topology between the desktop and NAS is: ``` ┌───────┐ ┌──────────────┐ │Client ┼─────────────┼2.5 GbE Switch│ └───────┘ 2.5 GbE └─────────────┬┘ │ ┌───────┐ ┌─────────────┼┐ │NAS ┼─────────────│10 Gb Agg Sw. │ └───────┘ 10 Gb SFP+ └──────────────┘ ``` I have configured ZFS with the `sharesmb=on` option. Setting this option with `zfs set sharesmb=on` is equivalent to running `net usershare add <sharename> <path>` on the CLI (https://github.com/openzfs/zfs/blob/zfs-2.2.2/lib/libshare/os/linux/smb.c#L249). This creates a usershare in `/var/lib/samba/usershares` as follows (I've sanitised the pool path to a/b): ``` #VERSION 2 path=/pools/a/b comment=Comment: /pools/a/b usershare_acl=S-1-1-0:F guest_ok=n sharename=a_b ``` My NAS has no other function than serving a ZFS filesystem to two Windows computers via Samba. Crashes are observed on both Windows clients, but I have the means to debug my own client better. Crashes occur intermittently for both users, regardless of whether one or both are using the system. The server runs at low CPU and RAM usage: my grafana telemetry does not indicate any spikes in load or memory usage during crash events (although the 60s interval would miss small events). At 60s intervals, memory usage is consistently around 40%, and the least idle core is 1% at all times, other than a ZFS snapshot every 15 minutes which brings least idle core load to 20%. smbd crashes are not correlated with the ZFS snapshotting. The server remains responsive during incidences of the smbd crash. Using `tail -f` I can observe the log file for an affected client update the same moment the Obsidian Vault closes on the client. I see no OOM or other suspicious events in the syslog around the time of a crash. Error: Now to the error itself. I have set `debug level = 10` as per your debugging instructions and captured the error. My log appears to corroborate other reports, indicating an intermittent issue with `smbd_smb2_getinfo_send` culminating in a segfault that appears to be related to a bad memory access encountered inside `volume_label` (https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c?ref_type=tags#L4385). ``` [2026/01/22 23:50:56.079338, 10, pid=1225061, effective(8000, 8000), real(8000, 0), class=smb2_credits] source3/smbd/smb2_server.c:2722(smbd_smb2_request_verify_creditcharge) smbd_smb2_request_verify_creditcharge: mid 656, CreditCharge: 1, NeededCharge: 1 [2026/01/22 23:50:56.079345, 10, pid=1225061, effective(8000, 8000), real(8000, 0), class=smb2] source3/smbd/smb2_getinfo.c:277(smbd_smb2_getinfo_send) smbd_smb2_getinfo_send: obsidian/miffy/investigations/2026-01 smbd crashing.md - fnum 1247396707 [2026/01/22 23:50:56.079365, 0, pid=1225061, effective(8000, 8000), real(8000, 0)] lib/util/fault.c:178(smb_panic_log) =============================================================== [2026/01/22 23:50:56.079371, 0, pid=1225061, effective(8000, 8000), real(8000, 0)] lib/util/fault.c:179(smb_panic_log) INTERNAL ERROR: Signal 11: Segmentation fault in smbd (smbd[10.10.8.6]) (client [10.10.8.6]) pid 1225061 (4.19.5-Ubuntu) [2026/01/22 23:50:56.079377, 0, pid=1225061, effective(8000, 8000), real(8000, 0)] lib/util/fault.c:186(smb_panic_log) 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 [2026/01/22 23:50:56.079383, 0, pid=1225061, effective(8000, 8000), real(8000, 0)] lib/util/fault.c:191(smb_panic_log) =============================================================== [2026/01/22 23:50:56.079392, 0, pid=1225061, effective(8000, 8000), real(8000, 0)] lib/util/fault.c:192(smb_panic_log) PANIC (pid 1225061): Signal 11: Segmentation fault in 4.19.5-Ubuntu [2026/01/22 23:50:56.079632, 0, pid=1225061, effective(8000, 8000), real(8000, 0)] lib/util/fault.c:303(log_stack_trace) BACKTRACE: 29 stack frames: #0 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(log_stack_trace+0x37) [0x7c7ab3587517] #1 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(smb_panic+0x15) [0x7c7ab3587d25] #2 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(+0x2dca) [0x7c7ab3587dca] #3 /lib/x86_64-linux-gnu/libc.so.6(+0x45330) [0x7c7ab3245330] #4 /lib/x86_64-linux-gnu/libc.so.6(+0x18b79d) [0x7c7ab338b79d] #5 /lib/x86_64-linux-gnu/libsmbconf.so.0(volume_label+0x53) [0x7c7ab3890963] #6 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-samba4.so.0(smbd_do_qfsinfo+0xa2) [0x7c7ab3962c82] #7 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-samba4.so.0(smbd_smb2_request_process_getinfo+0x276) [0x7c7ab39c5096] #8 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-samba4.so.0(smbd_smb2_request_dispatch+0x10c7) [0x7c7ab39aad07] #9 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-samba4.so.0(smbd_smb2_request_dispatch_immediate+0x97) [0x7c7ab39ac477] #10 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_invoke_immediate_handler+0x170) [0x7c7ab351a080] #11 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_immediate+0x22) [0x7c7ab351a0e2] #12 /lib/x86_64-linux-gnu/libtevent.so.0(+0xed92) [0x7c7ab351dd92] #13 /lib/x86_64-linux-gnu/libtevent.so.0(+0x6004) [0x7c7ab3515004] #14 /lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x9b) [0x7c7ab3516bab] #15 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x2b) [0x7c7ab3516cfb] #16 /lib/x86_64-linux-gnu/libtevent.so.0(+0x6084) [0x7c7ab3515084] #17 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base-samba4.so.0(smbd_process+0x7eb) [0x7c7ab399834b] #18 smbd: client [10.10.8.6](+0xa5d6) [0x647e883165d6] #19 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_invoke_fd_handler+0x98) [0x7c7ab3519e48] #20 /lib/x86_64-linux-gnu/libtevent.so.0(+0xefda) [0x7c7ab351dfda] #21 /lib/x86_64-linux-gnu/libtevent.so.0(+0x6004) [0x7c7ab3515004] #22 /lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x9b) [0x7c7ab3516bab] #23 /lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x2b) [0x7c7ab3516cfb] #24 /lib/x86_64-linux-gnu/libtevent.so.0(+0x6084) [0x7c7ab3515084] #25 smbd: client [10.10.8.6](main+0x1432) [0x647e88314032] #26 /lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca) [0x7c7ab322a1ca] #27 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b) [0x7c7ab322a28b] #28 smbd: client [10.10.8.6](_start+0x25) [0x647e88314a95] [2026/01/22 23:50:56.079693, 0, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/lib/util.c:691(smb_panic_s3) smb_panic(): calling panic action [/usr/share/samba/panic-action 1225061] [2026/01/22 23:50:56.081519, 0, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/lib/util.c:698(smb_panic_s3) smb_panic(): action returned status 0 ``` `volume_label` deferences pointers in such a way that it clearly expects that neither `lp_volume` or `lp_servicename` can return NULL. I figured this code would have been patched long ago if something was truly wrong with that assumption. So I tried to think about other lines of questioning instead, my attention was drawn to the `effective(8000, 8000)` provided by the higher debug level. I could imagine that some permission issue could potentially cause the intermittent behaviour we're observing. I see from my client log that `smbd` makes calls to `change_to_root_user` and `change_to_user_impersonate` to change the security context: ``` $ grep 'Primary group is' _client.log | sort | uniq -c 111497 Primary group is 0 and contains 0 supplementary groups 245 Primary group is 65534 and contains 1 supplementary groups 1078 Primary group is 8000 and contains 4 supplementary groups ``` process_usershare_file permission denied: Now, here is where things get a little interesting. My client log also has "Permission denied" errors when trying to access the file that describes the usershare. I had missed these previously, as it is the segmentation fault that appears at crash time and these permission errors are several thousand log lines earlier. The example below occurs less than ten seconds before the fatal segfault logged above: ``` [2026/01/22 23:50:48.084740, 0, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/param/loadparm.c:3480(process_usershare_file) process_usershare_file: stat of /var/lib/samba/usershares/a_b failed. Permission denied ``` Crucially, these permission denied errors only occur in the non-root security context (i.e. when the primary group is not 0) and when the context is `nobody` or my Samba user (i.e. 8000). ``` $ grep -B1 --no-group-separator 'stat of /var/lib/samba/usershares/a_b' _client.log | grep -v 'Permission denied' | awk '{ print $5,$6,$7,$8 }' | sort | uniq -c 147 effective(65534, 65534), real(65534, 0)] 113 effective(8000, 8000), real(8000, 0)] ``` I confirmed that indeed, my Samba user had insufficient permissions to read any file in the usershares directory because I had not added them to the `sambashare` group that would grant access to this directory to read and write usershares. I created my Samba users with `adduser` and provided access to SMB with `pdbedit` as follows: ``` adduser user --uid 8000 usermod -a -G some groups but not sambashare pdbedit -a user ``` Appropriate permissions stops segfaults: I believe the root cause of this segmentation fault is a user error whereby the administrator has managed to set up Samba users that do not have permission to read the files in `/var/lib/samba/usershares`. Without an adequate repro I cannot prove that resolving this permission error definitively fixes the issue, but I have been running Samba for two weeks without a single segmentation fault on either client. As an experiment, I reverted my working configuration (ie. removed my user from the sambashare group) and crashes resumed again. In just 1 hour of using my Obsidian Vault I experienced 5 crashes. Segfaults redux: The question remains, why does this seemingly innocuous permission denied error lead to a segmentation fault? Here I provide more context before the Permission denied error: ``` [2026/01/22 23:50:48.030237, 1, pid=1225061, effective(8000, 8000), real(8000, 0), class=rpc_parse] librpc/ndr/ndr.c:493(ndr_print_function_debug) dfs_GetDFSReferral: struct dfs_GetDFSReferral in: struct dfs_GetDFSReferral req: struct dfs_GetDFSReferral_in max_referral_level : 0x0004 (4) servername : '\nas\a_b' [2026/01/22 23:50:48.030269, 10, pid=1225061, effective(8000, 8000), real(8000, 0), class=msdfs] source3/smbd/msdfs.c:78(parse_dfs_path_strict) parse_dfs_path_strict: path = |\nas\a_b| [2026/01/22 23:50:48.030275, 10, pid=1225061, effective(8000, 8000), real(8000, 0), class=msdfs] source3/smbd/msdfs.c:114(parse_dfs_path_strict) parse_dfs_path_strict: hostname: nas [2026/01/22 23:50:48.030282, 10, pid=1225061, effective(8000, 8000), real(8000, 0), class=msdfs] source3/smbd/msdfs.c:140(parse_dfs_path_strict) parse_dfs_path_strict: servicename: a_b [2026/01/22 23:50:48.030288, 10, pid=1225061, effective(8000, 8000), real(8000, 0), class=msdfs] source3/smbd/msdfs.c:150(parse_dfs_path_strict) parse_dfs_path_strict: rest of the path: [2026/01/22 23:50:48.030350, 5, pid=1225061, effective(8000, 8000), real(8000, 0)] lib/dbwrap/dbwrap.c:172(dbwrap_lock_order_lock) dbwrap_lock_order_lock: check lock order 1 for /var/lib/samba/share_info.tdb [2026/01/22 23:50:48.030356, 10, pid=1225061, effective(8000, 8000), real(8000, 0)] lib/dbwrap/dbwrap.c:157(debug_lock_order) lock order: 1:/var/lib/samba/share_info.tdb 2:<none> 3:<none> 4:<none> [2026/01/22 23:50:48.030368, 5, pid=1225061, effective(8000, 8000), real(8000, 0)] lib/dbwrap/dbwrap.c:204(dbwrap_lock_order_unlock) dbwrap_lock_order_unlock: release lock order 1 for /var/lib/samba/share_info.tdb [2026/01/22 23:50:48.083920, 5, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/param/loadparm.c:1430(free_service) free_service: Freeing service a_b [2026/01/22 23:50:48.083971, 7, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/param/loadparm.c:4374(lp_servicenumber) lp_servicenumber: couldn't find a_b [2026/01/22 23:50:48.083982, 5, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/lib/username.c:182(Get_Pwnam_alloc) Finding user a_b [2026/01/22 23:50:48.083990, 5, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/lib/username.c:121(Get_Pwnam_internals) Trying _Get_Pwnam(), username as lowercase is a_b [2026/01/22 23:50:48.084414, 5, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/lib/username.c:141(Get_Pwnam_internals) Trying _Get_Pwnam(), username as uppercase is A_B [2026/01/22 23:50:48.084687, 5, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/lib/username.c:153(Get_Pwnam_internals) Checking combinations of 0 uppercase letters in a_b [2026/01/22 23:50:48.084697, 5, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/lib/username.c:159(Get_Pwnam_internals) Get_Pwnam_internals didn't find user [a_b]! [2026/01/22 23:50:48.084707, 3, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/param/service.c:162(find_service) checking for home directory a_b gave (NULL) [2026/01/22 23:50:48.084715, 3, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/param/service.c:180(find_service) checking whether a_b is a valid printer name... [2026/01/22 23:50:48.084727, 3, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/param/service.c:194(find_service) a_b is not a valid printer name [2026/01/22 23:50:48.084740, 0, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/param/loadparm.c:3480(process_usershare_file) process_usershare_file: stat of /var/lib/samba/usershares/a_b failed. Permission denied [2026/01/22 23:50:48.084750, 3, pid=1225061, effective(8000, 8000), real(8000, 0)] source3/param/service.c:261(find_service) find_service() failed to find service a_b [2026/01/22 23:50:48.084762, 10, pid=1225061, effective(8000, 8000), real(8000, 0), class=smb2] source3/smbd/smb2_ioctl.c:314(smbd_smb2_request_ioctl_done) smbd_smb2_request_ioctl_done: smbd_smb2_ioctl_recv returned 0 status NT_STATUS_NOT_FOUND ``` Caveats aside (I had no familiarity with the Samba codebase until investigating this issue), I believe the chain of events that leads to the segfault is as follows: - Business as usual - We are dropped to the (8000, 8000) user context - `get_referred_path` calls `parse_dfs_path_strict` to split out the path components https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/smbd/msdfs.c#L938 - `get_referred_path` calls `lp_servicenumber` to determine the service number https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/smbd/msdfs.c#L964 - `lp_servicenumber` calls `usershare_exists` to ensure the usershare still exists https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L4354 - `usershare_exists` silently fails if `sys_lstat` fails when reading the usershare file https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L3646 - `usershare_exists` exits false, causing the service to be freed by `lp_servicenumber` using `free_service_byindex` https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L4358 - As logged, the `a_b` service is freed by `free_service` called via `free_service_byindex` https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L1430 - The `ServicePtrs[idx]` entry corresponding to the `a_b` usershare has been freed and is now `NULL` - We're still in `get_referred_path` and failed to find the service with `lp_servicenumber`, so we now call `find_service` to find the service we just destroyed https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/smbd/msdfs.c#L967 - `find_service` calls `load_usershare_service` to try and determine if this is a usershare https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/service.c#L206 - `load_usershare_service` calls `process_usershare_file` https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L3744 - As logged, the usershare file cannot be stat https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L3480 - As logged, `find_service` fails to find our service https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/service.c#L261 - Some time passes... A new request comes in... - `smbd_do_qfsinfo` calls `volume_label` https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/smbd/smb2_trans2.c#L2051 (with a stale service number, presumably as the client connection has no idea the service it was using has been freed) - `volume_label` interrogates `lp_volume` https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L4390 - My understanding is that `lp_volume` is generated by `FN_LOCAL_SUBSTITUTED_STRING` https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L1101, as per `param_table_gen.c` which is autogenerated from the docs (https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/lib/param/wscript_build#L27, https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/docs-xml/smbdotconf/misc/volume.xml) - `FN_LOCAL_SUBSTITUTED_STRING` checks for a valid service and either returns the service's field, or falls back to the default value; before substituting for the final value. As `LP_SNUM_OK(i)` will be false (as the service was freed) we fallback to `sDefault.volume` which at first glance appears to be NULL (https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L161) but is actually set to the `lpcfg_string_empty` empty string by `init_globals` calling `lpcfg_string_set` (https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L544) with a destination in `sDefault` calculated by `lp_parm_ptr` (https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L2683). - `lp_volume` is therefore `lpcfg_string_empty` for our freed service and `volume_label` will move on to try `lp_servicename` https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L4394 - `lp_servicename` is similarly a `FN_LOCAL_SUBSTITUTED_STRING` https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L1135 but does not appear in `parm_table` and is not initialised by `init_globals` like `volume`, I believe it therefore retains its compile time default of `NULL` https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L127 - Falling back to the `NULL` default, `lpcfg_substituted_string` uses `loadparm_s3_global_substitution_fn` to determine the final output value for `lp_servicename`, which returns `NULL` if its input is `NULL` https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L1054 - `volume_label` fatally calls `strlen` on the `NULL` `lp_servicename` result, causing the segmentation fault https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L4403 Although the root cause is (again, in my case at least) user misconfiguration, I imagine it is undesirable that this misconfiguration leads to a segfault. It is surprising to me that `lp_servicenumber` is ostensibly for finding a service number by its name but has a potential side-effect of calling `free_service_byindex` to destroy a service, whereas `load_usershare_shares` more carefully does a mark and sweep of known services (https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L3893) and retains them if they are still in use (https://gitlab.com/samba-team/samba/-/blob/samba-4.19.5/source3/param/loadparm.c#L3900). I do not have enough understanding of Samba to even think about where an appropriate fix in this chain would go to avoid a segmentation fault, though I would be happy to try and contribute with a little direction! Summary: - I believe I am experiencing the same issue described by this ticket. - The root cause appears to be a user misconfiguration where Samba users on the smbd host lack permission to read entries in `/var/lib/samba/usershares`. - When operating in a security context with insufficient privileges to read the usershare directory entries, `lp_servicenumber` calls `usershare_exists` which silently fails and triggers the service to be freed. Later access to the service by the index causes a segmentation fault. - I have made the segmentation fault stop by ensuring my Samba users can read the entries in the usershare directory.