Howboys

I think this was because of USB3 (or more accurately because unraid doesn't officially support USB3). Most modern computers don't have USB2 ports and mist flash drives are USB3. So you're kinda screwed. My solution was to just move to using snapraid and mergerfs. Much less headache and I use vanilla Ubuntu. I was getting tired of unraid's limitations like these.

I don't have diagnostics because the server was hung (couldn't do anything), but any idea why this might be happening? Would retrying downloading rclone help with transient network glitches?

Yes borgmatic. Good to know for future

Solution: I had a container (stopped) that didn't have a working icon URL. I deleted that container and things are good now. I wish unraid was better at handling these situations (or letting us disable pulling icons).

Unfortunately, https://github.com/Steini1984/unRAID6-Sainoid/tree/master/packages contains sanoid from 2 years ago. The actual repo hasn't had an official release since then either (though there's been MANY changes since then).

So slow that it can take 30-60 seconds to load the page. All my containers are on an nvme (appdata), and I have ~25 containers out of which 8 are stopped. Diagnostics attached. tower-diagnostics-20230627-2204.zip

Okay I get that but just blurting out the same message isn't really helpful. There's a bug here - the USB controller is reporting the right information but unraid isn't receiving it correctly. But since you seem to be an expert on USB interfaces: what are the other problems exactly?

I'm also seeing this with 2 different enclosures. Each drive is recognized and the Identity part of the disk reads the correct serial/model/smart. But the Main page only shows drives like JMicron_Generic_0123456789ABCDEF-0:0. This is mostly fine except preclear freaks out (clicking preclear only seems to kick off the operation on the first drive regardless of which button you press). I would really love a solution to this.

Did you ever figure this out? I just got a 800 G4 Mini and I'm seeing very similar symptoms. I've tried booting EFI and legacy, similar results. Basically, half my boots are okay. The other half result in Boot device not found error. Occasionally, I'll see the blue unraid screen without and text (but the boot would hang). I've messed around with BIOS settings but nothing helped. I'm using a Samsung 32GB flash drive. I've tried all USB ports on the computer (none are USB 2.0). Basically, I just can't get unraid to boot reliably on this system.

I'm already on 11.5.

Anyone from unraid look at this?

Actually, looks like using Cx File Explorer, deleting any files on the SMB mount crashes and: looks like unraid's smbd is definitely broken in some way.

Exact same. I started seeing it a few months ago too but I don't think I had upgraded unraid at all. I can reproduce it by deleting large files from the nfs mount. Related: Unfortunately no one from the team has responded

I'm seeing this too: Jun 15 16:47:34 Tower smbd[5524]: [2023/06/15 16:47:34.320191, 0] ../../source3/smbd/close.c:312(close_remove_share_mode) Jun 15 16:47:34 Tower smbd[5524]: close_remove_share_mode: Could not get share mode lock for file Vault/stff/file.mp4 Jun 15 16:47:34 Tower smbd[5524]: [2023/06/15 16:47:34.320283, 0] ../../source3/smbd/fd_handle.c:39(fd_handle_destructor) Jun 15 16:47:34 Tower smbd[5524]: PANIC: assert failed at ../../source3/smbd/fd_handle.c(39): (fh->fd == -1) || (fh->fd == AT_FDCWD) Jun 15 16:47:34 Tower smbd[5524]: [2023/06/15 16:47:34.320297, 0] ../../lib/util/fault.c:173(smb_panic_log) Jun 15 16:47:34 Tower smbd[5524]: =============================================================== Jun 15 16:47:34 Tower smbd[5524]: [2023/06/15 16:47:34.320310, 0] ../../lib/util/fault.c:174(smb_panic_log) Jun 15 16:47:34 Tower smbd[5524]: INTERNAL ERROR: assert failed: (fh->fd == -1) || (fh->fd == AT_FDCWD) in pid 5524 (4.17.3) Jun 15 16:47:34 Tower smbd[5524]: [2023/06/15 16:47:34.320318, 0] ../../lib/util/fault.c:178(smb_panic_log) Jun 15 16:47:34 Tower smbd[5524]: 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 Jun 15 16:47:34 Tower smbd[5524]: [2023/06/15 16:47:34.320327, 0] ../../lib/util/fault.c:183(smb_panic_log) Jun 15 16:47:34 Tower smbd[5524]: =============================================================== Jun 15 16:47:34 Tower smbd[5524]: [2023/06/15 16:47:34.320335, 0] ../../lib/util/fault.c:184(smb_panic_log) Jun 15 16:47:34 Tower smbd[5524]: PANIC (pid 5524): assert failed: (fh->fd == -1) || (fh->fd == AT_FDCWD) in 4.17.3 Jun 15 16:47:34 Tower smbd[5524]: [2023/06/15 16:47:34.320686, 0] ../../lib/util/fault.c:292(log_stack_trace) Jun 15 16:47:34 Tower smbd[5524]: BACKTRACE: 38 stack frames: Jun 15 16:47:34 Tower smbd[5524]: #0 /usr/lib64/libgenrand-samba4.so(log_stack_trace+0x2e) [0x1476341fc64e] Jun 15 16:47:34 Tower smbd[5524]: #1 /usr/lib64/libgenrand-samba4.so(smb_panic+0x9) [0x1476341fc8a9] Jun 15 16:47:34 Tower smbd[5524]: #2 /usr/lib64/libsmbd-base-samba4.so(+0x4d10b) [0x1476345dd10b] Jun 15 16:47:34 Tower smbd[5524]: #3 /usr/lib64/libtalloc.so.2(+0x44df) [0x1476341ac4df] Jun 15 16:47:34 Tower smbd[5524]: #4 /usr/lib64/libsmbd-base-samba4.so(file_free+0xd6) [0x1476345ea2e6] Jun 15 16:47:34 Tower smbd[5524]: #5 /usr/lib64/libsmbd-base-samba4.so(close_file_free+0x29) [0x14763461ad49] Jun 15 16:47:34 Tower smbd[5524]: #6 /usr/lib64/libsmbd-base-samba4.so(+0x5d046) [0x1476345ed046] Jun 15 16:47:34 Tower smbd[5524]: #7 /usr/lib64/libsmbd-base-samba4.so(+0x5d1ce) [0x1476345ed1ce] Jun 15 16:47:34 Tower smbd[5524]: #8 /usr/lib64/libsmbd-base-samba4.so(files_forall+0x19) [0x1476345e9119] Jun 15 16:47:34 Tower smbd[5524]: #9 /usr/lib64/libsmbd-base-samba4.so(file_close_user+0x3d) [0x1476345e925d] Jun 15 16:47:34 Tower smbd[5524]: #10 /usr/lib64/libsmbd-base-samba4.so(smbXsrv_session_logoff+0x4d) [0x14763466600d] Jun 15 16:47:34 Tower smbd[5524]: #11 /usr/lib64/libsmbd-base-samba4.so(+0xd6445) [0x147634666445] Jun 15 16:47:34 Tower smbd[5524]: #12 /usr/lib64/libdbwrap-samba4.so(+0x5d18) [0x147633eded18] Jun 15 16:47:34 Tower smbd[5524]: #13 /usr/lib64/libdbwrap-samba4.so(+0x5f3a) [0x147633edef3a] Jun 15 16:47:34 Tower smbd[5524]: #14 /usr/lib64/libdbwrap-samba4.so(dbwrap_traverse+0x7) [0x147633edcf67] Jun 15 16:47:34 Tower smbd[5524]: #15 /usr/lib64/libsmbd-base-samba4.so(smbXsrv_session_logoff_all+0x5b) [0x1476346667fb] Jun 15 16:47:34 Tower smbd[5524]: #16 /usr/lib64/libsmbd-base-samba4.so(+0xdca0b) [0x14763466ca0b] Jun 15 16:47:34 Tower smbd[5524]: #17 /usr/lib64/libsmbd-base-samba4.so(smbd_reinit_after_fork+0) [0x14763466cff0] Jun 15 16:47:34 Tower smbd[5524]: #18 /usr/lib64/libsmbd-shim-samba4.so(exit_server_cleanly+0x14) [0x147634201284] Jun 15 16:47:34 Tower smbd[5524]: #19 /usr/lib64/libsmbd-base-samba4.so(smbd_server_connection_terminate_ex+0x4d6) [0x1476346424c6] Jun 15 16:47:34 Tower smbd[5524]: #20 /usr/lib64/libtevent.so.0(tevent_common_invoke_fd_handler+0x91) [0x1476341bf791] Jun 15 16:47:34 Tower smbd[5524]: #21 /usr/lib64/libtevent.so.0(+0xec87) [0x1476341c5c87] Jun 15 16:47:34 Tower smbd[5524]: #22 /usr/lib64/libtevent.so.0(+0xcd77) [0x1476341c3d77] Jun 15 16:47:34 Tower smbd[5524]: #23 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x1476341beb61] Jun 15 16:47:34 Tower smbd[5524]: #24 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x1476341bee3b] Jun 15 16:47:34 Tower smbd[5524]: #25 /usr/lib64/libtevent.so.0(+0xcd17) [0x1476341c3d17] Jun 15 16:47:34 Tower smbd[5524]: #26 /usr/lib64/libsmbd-base-samba4.so(smbd_process+0x817) [0x147634633ce7] Jun 15 16:47:34 Tower smbd[5524]: #27 /usr/sbin/smbd(+0xb090) [0x55d319c56090] Jun 15 16:47:34 Tower smbd[5524]: #28 /usr/lib64/libtevent.so.0(tevent_common_invoke_fd_handler+0x91) [0x1476341bf791] Jun 15 16:47:34 Tower smbd[5524]: #29 /usr/lib64/libtevent.so.0(+0xec87) [0x1476341c5c87] Jun 15 16:47:34 Tower smbd[5524]: #30 /usr/lib64/libtevent.so.0(+0xcd77) [0x1476341c3d77] Jun 15 16:47:34 Tower smbd[5524]: #31 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x1476341beb61] Jun 15 16:47:34 Tower smbd[5524]: #32 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x1476341bee3b] Jun 15 16:47:34 Tower smbd[5524]: #33 /usr/lib64/libtevent.so.0(+0xcd17) [0x1476341c3d17] Jun 15 16:47:34 Tower smbd[5524]: #34 /usr/sbin/smbd(main+0x1489) [0x55d319c53259] Jun 15 16:47:34 Tower smbd[5524]: #35 /lib64/libc.so.6(+0x23177) [0x147633fc9177] Jun 15 16:47:34 Tower smbd[5524]: #36 /lib64/libc.so.6(__libc_start_main+0x85) [0x147633fc9235] Jun 15 16:47:34 Tower smbd[5524]: #37 /usr/sbin/smbd(_start+0x21) [0x55d319c53b31] Jun 15 16:47:34 Tower smbd[5524]: [2023/06/15 16:47:34.320857, 0] ../../source3/lib/dumpcore.c:315(dump_core) Jun 15 16:47:34 Tower smbd[5524]: dumping core in /var/log/samba/cores/smbd From what I can tell, this only happens from Cx File Manager from.

Adding another data point - I'm seeing this as well. It's disheartening that this isn't prioritized for 6.12 at all