Created attachment 18203 [details] Samba logs, share config and software versions Copying from a non-btrfs share to a btrfs share using a Win10 client casuses a segfault and throws Error 0x8007003B: An unexpected network error occurred on the client. The issue seems to be caused if the share has the "vfs objects = btrfs" flag. By removing this flag, the copy/move process no longer results in a segfault. For this reason I selected the component "VFS modules". Please revise the component selection if this is not correct. I could not replicate this behaviour using a linux client (Ubuntu 22.04), but there it seems like the file makes the roundtrip server > client > server, whereas on windows the client issues the commands serverside and the files are never read/sent by the client. Another user of the OMV NAS Software can confirm this behaviour: https://forum.openmediavault.org/index.php?thread/50666-upgrade-samba-from-version-4-13-13-to-version-4-17-12-bullseye-backports/&postID=376439#post376439 https://pastebin.com/VGQQTGts See details in the attachment.
Can you install the debug symbols and get a full stack backtrace with line numbers ? You can add the line: panic action = /bin/sleep 999999 to the [global] section of your smb.conf, recreate the crash and then attach to the parent of the "sleep" process with gdb. Typing the "bt" (backtrace) command will then print out the full stack trace including line numbers. Thanks !
Created attachment 18204 [details] gdb output of ´bt´ when attaching to pid of smbd and smbd: client after triggering the panic.
Sorry, this is the first time I'm doing this, not sure if I did it right. I added panic action = /bin/sleep 999999 to [Global], but after triggering the panic I could not find a sleep pid using ´ps aux | grep sleep´ root@debian:~# ps aux | grep sleep root 4525 0.0 0.0 6856 1976 pts/3 S+ 10:02 0:00 grep sleep Instead I attached to smbd and smbd:client instead, and ran bt. root@debian:~# ps aux | grep smbd root 3147 0.0 1.2 85484 24192 ? Ss 09:41 0:00 /usr/sbin/smbd --foreground --no-process-group root 3149 0.0 0.2 83040 5960 ? S 09:41 0:00 smbd: notifyd . root 3150 0.0 0.2 83048 4252 ? S 09:41 0:00 smbd: cleanupd root 3176 0.0 0.8 94464 16824 ? S 09:42 0:00 smbd: client [fe80::d4e0:2d7d:4060:a48b%enp0s3] root 4372 0.0 0.1 6856 2016 pts/0 S+ 09:51 0:00 grep smbd Does this help you? It is attached in the attachment above. If not, please let me know where I went wrong and I'll try this again :)
Created attachment 18205 [details] Backtrace of the paniced smbd process Hi, I figured out what I did wrong. In the [Global] part, there was another panic action already defined, so that overwrote the `/bin/sleep` action. using ps aux and ps -p I was able to get the parent process of sh -c /bin/sleep 99999 triggered by smbd. Attaching to the parent process with gbd -p <parent_process_id> and then running bt resulted in the attached txt. Hope this helps!