smbd exited on singal 6
Description
Problem/Justification
Impact
relates to
SmartDraw Connector
Katalon Manual Tests (BETA)
Activity

I agree that the severity of this issue is underappreciated. I'm have smb encrypt = mandatory for some shares and this bug makes SMB pretty much unusable. The service crashes every few MB...

I had tried "server multi channel support = no" already and I just did again and can still reproduce it, like before.

Hey, no, you must disable multichannel:
IMHO:
I don't know how the ixsystems folks fixed it in the upcomming release, but it seems to me it's an SMB / Samba issue. So probably not related to a TrueNAS problem but an issue of the samba.org project. So regarding the "severeness" of this ticket probably you could lower your expectations, even If you're a paying customer. Sometimes things break and get fixed in the next release. Especially with non default values like SMB multi channel which is just an reverse implementation of Microsoft's feature for samba.org.
Anyhow: Time Machine - If you don't like it or not like it (huh?).
This feature's promise sounds to good to be true and in real life it's just a big pain. Even more over network (yes, also over 1G ethernet and with Apple Timecapsule).
My experience with Time Machine over the years:
Time Machine is so reliable as it's slide in animation lags/is slow: it's just not good and it breaks an Apple promise from the Steve Jobs area: "It just doesn't work-s-"
Once upon a time, there was a Snow Leopard which gave us this all-mighty stability...
Unfortunately it was a one-hit-wonder.It kinda works over AFP, but I would never wan't to depend on
Over SMB ? Get anything else.

Thanks Flo. First off, I didn't want to sound whiny but it seems most in this bug don't appreciate the severeness - this is completely breaking TM because it will stop at the first disconnect. Restarting TM takes a non-trivial amount of time while it "Prepares to backup" and I typically only get ~ 400 MB backed up before it bails again. I didn't speak up because I thought the fix would be in U1.1.
It isn't clear to me what "disabledsmb multi channel" implies, but I tried adding
server multi channel support = yes
aio read size = 1
aio write size = 1
to the Auxiliary Paramaters in the SMB service, but that had no effect.
I also tried adding "vfs objects = streams_xattr zfs_space" to no avail.
So far I've found nothing to work around it and I can reproduce it at will within a minute or so.

@Tommy Thorn:
just to make sure because it worked for me and yes, I know you wrote that "none of the workarounds" worked out for you, but probably you just did not see my workaround:
Try to disabledsmb multi channel.
I tested it a few times on my systems (only with Windows clients, which are smb multichannel capable).
But as I'm writing these lines > macOS can't handle SMB Multichannel, what am I thinking 🐛? Probably unlikely, but who knows...
Even If Apple kinda deprecated AFP (Netatalk is free server implementation), the AFP client still exists on Big Sur and I benchmark/compared it with SMB.
End result: SMB sucked so hard on macOS forever. Apple is recommending SMB, yes, but that doesn't mean the quality is getting any better.
I personally don't like answers like myself is posting here alá "Tool A is not working for you, I will not contribute to any fix but I recommend something different" - But in this case: Give AFP a chance. I was blown away how fast and responsive the Finder suddenly behaved. Command + K > afp://host.domain.com > bam, select share, bam: there you are. Compared to SMB with Latest and greatest bottom right corner MBP16", 10GB LAN > SRV2K19 it's a night and day difference.
Best regards, Flo.
Hello, I am seeing this error in the console messages each night during high activity of data transfer, when it happens it loses connection to the share and then reconnects, these are Windows Server 2019 machines connecting to TrueNAS. In the smbd.log file I see the following:
[2020/12/15 01:00:25.121870, 0] ../../lib/util/fault.c:79(fault_report)
===============================================================
[2020/12/15 01:00:25.121902, 0] ../../lib/util/fault.c:80(fault_report)
INTERNAL ERROR: Signal 11 in pid 17897 (4.12.9)
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
[2020/12/15 01:00:25.121917, 0] ../../lib/util/fault.c:86(fault_report)
===============================================================
[2020/12/15 01:00:25.121925, 0] ../../source3/lib/util.c:830(smb_panic_s3)
PANIC (pid 17897): internal error
[2020/12/15 01:00:25.122874, 0] ../../lib/util/fault.c:265(log_stack_trace)
BACKTRACE: 6 stack frames:
#0 0x801296217 <log_stack_trace+0x37> at /usr/local/lib/samba4/libsamba-util.so.0
#1 0x802f9b656 <smb_panic_s3+0x56> at /usr/local/lib/samba4/libsmbconf.so.0
#2 0x801296007 <smb_panic+0x17> at /usr/local/lib/samba4/libsamba-util.so.0
#3 0x8012963ee <log_stack_trace+0x20e> at /usr/local/lib/samba4/libsamba-util.so.0
#4 0x801295fe9 <fault_setup+0x59> at /usr/local/lib/samba4/libsamba-util.so.0
#5 0x8099dbc20 <_pthread_sigmask+0x530> at /lib/libthr.so.3
[2020/12/15 01:00:25.122941, 0] ../../source3/lib/dumpcore.c:315(dump_core)
dumping core in /var/db/system/cores
Is there a way to provide the core dump file that is not public? Also is there anything else that would help?
Thanks.