JorgeB

Sorry, can't really help with that, someone else might be able to.

Check filesystem on disk1, ATA errors on disks 2 and 8, disk8 issue doesn't look like a disk problem, could be power/connection related or the controller since it's using a SATA port multiplier and those are a known issue.

Check/replace cables (both SATA and power) on parity and disk1.

You don't have VMs so it's likely container related, you can try running with just some or leave one disable at a time to see if you can find the culprit.

Not sure what you mean by this, number of SATA cables is not a problem except for cable management. Apparently it can be flashed to IT mode but there won't be SMART: https://forums.servethehome.com/index.php?threads/crossflashing-of-lsi-9341-8i-to-lsi-9300-8i-success-but-no-smart-pass-through.3522/ That's incorrect, it can happen with very old controllers/backplanes, with SATA or SAS.

This is no longer needed, as of at least Unraid v6.10-rc4 and later included Samba supports reflinks over SMB by default (for XFS also), and note that as of now (Unraid v6.10.0-rc7) and due to an apparent Samba bug any copy to a share with this enable done using server side copy will crash Samba.

Thanks, that's it, in a way glad I didn't know how it worked, or I would probably still be looking my issue

Cache filesystem is corrupt, you should backup and re-format.

Found the problem, reflinking over SMB is now enable by default with Samba, me adding "vfs objects = btrfs" was causing the problem, it's no longer needed for reflinks, though it's still a valid option, so server side copy making Samba crash with it enable now looks like a Samba bug. Having a second vfs object "fixed" the problem because apparently Unraid only loads the last one, so basically wasn't loading "vfs objects = btrfs", on a related note if I needed to set two or more vfs objects for one share how could I do that? P.S. reflinks over SMB now also work with XFS, assuming it's a relatively recent XFS filesystem with reflink support, so you can just right-click one or more files with Windows explorer and select copy here (or copy/paste) to make reflinks, it works with disk shares and user shares.

May 4 09:45:00 Mongo kernel: macvlan_broadcast+0x116/0x144 [macvlan] May 4 09:45:00 Mongo kernel: macvlan_process_broadcast+0xc7/0x110 [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 and switching to ipvlan might fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info. https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

Please post the diagnostics.

That's fine, and preferable IMHO, as long as the use cache is not set to "yes" like it was, or some data would be moved to the array and missing in the docker(s)

Extended test pass so disk is OK, SMART attributes also look healthy.

Try recreating the docker image, not sure it will help but it won't hurt.

Yes, it works normally as long as there's an additional vfs object besides btrfs, though I only tested with two, shadow_copy2 and recycle, and no, no recycle bin plugin installed.

Some NVMe devices have issues with power states on Linux, try this, on the main GUI page click on flash, scroll down to "Syslinux Configuration", make sure it's set to "menu view" (on the top right) and add this to your default boot option, after "append initrd=/bzroot" nvme_core.default_ps_max_latency_us=0 e.g.: append initrd=/bzroot nvme_core.default_ps_max_latency_us=0 Reboot and see if it makes a difference.

After some more testing I found that apparently just need to add any other vfs object, i.e., with this config any copy/move from another share to this share done with Windows explorer Samba crashes immediately: [cache] path = /mnt/cache vfs objects = btrfs comment = browseable = yes public = yes writeable = yes case sensitive = auto preserve case = yes short preserve case = yes It works fine with for example this one: [cache] path = /mnt/cache vfs objects = btrfs vfs objects = recycle comment = browseable = yes public = yes writeable = yes case sensitive = auto preserve case = yes short preserve case = yes @limetech any idea if this could be specific to Unraid and how Samba or its config files are implemented or it's likely a Samba bug?

Next time please use the existing UD plugin support thread:

I believe it's a known issue, you'd need to run it manually, but note the warning, btrfs check --repair should only be run as a last resort, or it could makes thing worse, if the filesystem is unmountable some safe things you can try first here.

According to diags both parity drives and cache are on the onboard SATA, all others are on the RAID controllers, and very likely the reason they are not spinning down.

It's fine to copy the docker image, though IIRC under some circumstances you can get a false image is corrupt warning in the GUI after, but if you use CA to restore the apps it will restore them all with one click, except maybe the duplicates, not sure about those.

If it's a Realtek NIC take a look below, though not quite clear what the fix was. https://forums.unraid.net/topic/122274-write-good-read-bad/

Looks like a network problem, several internet unreachable errors: May 6 11:44:42 StewartsTower nginx: 2022/05/06 11:44:42 [error] 25358#25358: connect() to [2001:559:19:1800::1720:2e12]:80 failed (101: Network is unreachable) while requesting certificate status, responder: r3.o.lencr.org, peer: [2001:559:19:1800::1720:2e12]:80, certificate: "/etc/ssl/certs/unraid_bundle.pem" ... May 6 11:54:16 StewartsTower root: Error: Failed to connect to keys.lime-technology.com port 443: No route to host

I doubt many are using "vfs objects = btrfs" for one or more btrfs based shares to allow reflinking over SMB, but in case someone is and to avoid spending a week like I did trying to debug this, since upgrading to v6.10 reflinking over SMB was working fine but I was having issues with Samba reverting to non server side copy or most often just crashing when doing a copy to some shares, later noticed that it would only happened for shares with that option enable. When it reverts do over lan copy it logs: May 6 18:12:39 Tower7 smbd[537]: [2022/05/06 18:12:39.134808, 0] ../../source3/smbd/smb2_ioctl_network_fs.c:229(fsctl_srv_copychunk_vfs_done) May 6 18:12:39 Tower7 smbd[537]: fsctl_srv_copychunk_vfs_done: copy chunk failed [NT_STATUS_OBJECT_NAME_NOT_FOUND] chunk [0] of [16] And when it crashes, always right at the beginning of the copy operation, it leaves a corrupt file in the destination and logs: May 6 11:30:22 Tower7 smbd[6096]: [2022/05/06 11:30:22.120598, 0] ../../lib/util/fault.c:172(smb_panic_log) May 6 11:30:22 Tower7 smbd[6096]: =============================================================== May 6 11:30:22 Tower7 smbd[6096]: [2022/05/06 11:30:22.120686, 0] ../../lib/util/fault.c:173(smb_panic_log) May 6 11:30:22 Tower7 smbd[6096]: INTERNAL ERROR: Signal 11: Segmentation fault in pid 6096 (4.15.7) May 6 11:30:22 Tower7 smbd[6096]: [2022/05/06 11:30:22.120717, 0] ../../lib/util/fault.c:177(smb_panic_log) May 6 11:30:22 Tower7 smbd[6096]: 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 May 6 11:30:22 Tower7 smbd[6096]: [2022/05/06 11:30:22.120745, 0] ../../lib/util/fault.c:182(smb_panic_log) May 6 11:30:22 Tower7 smbd[6096]: =============================================================== May 6 11:30:22 Tower7 smbd[6096]: [2022/05/06 11:30:22.120788, 0] ../../lib/util/fault.c:183(smb_panic_log) May 6 11:30:22 Tower7 smbd[6096]: PANIC (pid 6096): Signal 11: Segmentation fault in 4.15.7 May 6 11:30:22 Tower7 smbd[6096]: [2022/05/06 11:30:22.120988, 0] ../../lib/util/fault.c:245(log_stack_trace) May 6 11:30:22 Tower7 smbd[6096]: BACKTRACE: May 6 11:30:22 Tower7 smbd[6096]: #0 log_stack_trace + 0x39 [ip=0x14f6ead24029] [sp=0x7ffe431ab540] May 6 11:30:22 Tower7 smbd[6096]: #1 smb_panic + 0x9 [ip=0x14f6ead24389] [sp=0x7ffe431abe80] May 6 11:30:22 Tower7 smbd[6096]: #2 smb_panic + 0x9a [ip=0x14f6ead2441a] [sp=0x7ffe431abe90] May 6 11:30:22 Tower7 smbd[6096]: #3 funlockfile + 0x50 [ip=0x14f6ea82b3a0] [sp=0x7ffe431abf40] May 6 11:30:22 Tower7 smbd[6096]: #4 vfs_offload_token_db_fetch_fsp + 0x37 [ip=0x14f6eae76b37] [sp=0x7ffe431ac4f0] May 6 11:30:22 Tower7 smbd[6096]: #5 <unknown symbol> [ip=0x14f6e62c9288] [sp=0x7ffe431ac530] May 6 11:30:22 Tower7 smbd[6096]: #6 smb2_ioctl_named_pipe + 0x5c0 [ip=0x14f6eaf53b40] [sp=0x7ffe431ac670] May 6 11:30:22 Tower7 smbd[6096]: #7 smb2_ioctl_network_fs + 0x7f2 [ip=0x14f6eaf548e2] [sp=0x7ffe431ac6b0] May 6 11:30:22 Tower7 smbd[6096]: #8 smbd_smb2_request_process_ioctl + 0x570 [ip=0x14f6eaf51810] [sp=0x7ffe431ac790] May 6 11:30:22 Tower7 smbd[6096]: #9 smbd_smb2_request_dispatch + 0xf94 [ip=0x14f6eaf42404] [sp=0x7ffe431ac800] May 6 11:30:22 Tower7 smbd[6096]: #10 smbd_smb2_request_dispatch_immediate + 0x547 [ip=0x14f6eaf43017] [sp=0x7ffe431ac890] May 6 11:30:22 Tower7 smbd[6096]: #11 tevent_common_invoke_fd_handler + 0x91 [ip=0x14f6eaa083f1] [sp=0x7ffe431ac930] May 6 11:30:22 Tower7 smbd[6096]: #12 tevent_wakeup_recv + 0x108f [ip=0x14f6eaa0e91f] [sp=0x7ffe431ac960] May 6 11:30:22 Tower7 smbd[6096]: #13 tevent_signal_get_tag + 0xb7 [ip=0x14f6eaa0ca87] [sp=0x7ffe431ac9c0] May 6 11:30:22 Tower7 smbd[6096]: #14 _tevent_loop_once + 0x94 [ip=0x14f6eaa07844] [sp=0x7ffe431ac9e0] May 6 11:30:22 Tower7 smbd[6096]: #15 tevent_common_loop_wait + 0x1b [ip=0x14f6eaa07b2b] [sp=0x7ffe431aca10] May 6 11:30:22 Tower7 smbd[6096]: #16 tevent_signal_get_tag + 0x57 [ip=0x14f6eaa0ca27] [sp=0x7ffe431aca30] May 6 11:30:22 Tower7 smbd[6096]: #17 smbd_process + 0x828 [ip=0x14f6eaf30c38] [sp=0x7ffe431aca50] May 6 11:30:22 Tower7 smbd[6096]: #18 start_lsasd + 0x2e25 [ip=0x55c72dd1d385] [sp=0x7ffe431acae0] May 6 11:30:22 Tower7 smbd[6096]: #19 tevent_common_invoke_fd_handler + 0x91 [ip=0x14f6eaa083f1] [sp=0x7ffe431acbc0] May 6 11:30:22 Tower7 smbd[6096]: #20 tevent_wakeup_recv + 0x108f [ip=0x14f6eaa0e91f] [sp=0x7ffe431acbf0] May 6 11:30:22 Tower7 smbd[6096]: #21 tevent_signal_get_tag + 0xb7 [ip=0x14f6eaa0ca87] [sp=0x7ffe431acc50] May 6 11:30:22 Tower7 smbd[6096]: #22 _tevent_loop_once + 0x94 [ip=0x14f6eaa07844] [sp=0x7ffe431acc70] May 6 11:30:22 Tower7 smbd[6096]: #23 tevent_common_loop_wait + 0x1b [ip=0x14f6eaa07b2b] [sp=0x7ffe431acca0] May 6 11:30:22 Tower7 smbd[6096]: #24 tevent_signal_get_tag + 0x57 [ip=0x14f6eaa0ca27] [sp=0x7ffe431accc0] May 6 11:30:22 Tower7 smbd[6096]: #25 main + 0x1ebe [ip=0x55c72dd1805e] [sp=0x7ffe431acce0] May 6 11:30:22 Tower7 smbd[6096]: #26 __libc_start_main + 0xcd [ip=0x14f6ea65e03d] [sp=0x7ffe431ad020] May 6 11:30:22 Tower7 smbd[6096]: #27 _start + 0x2a [ip=0x55c72dd181fa] [sp=0x7ffe431ad0f0] May 6 11:30:22 Tower7 smbd[6096]: [2022/05/06 11:30:22.137979, 0] ../../source3/lib/dumpcore.c:315(dump_core) May 6 11:30:22 Tower7 smbd[6096]: dumping core in /var/log/samba/cores/smbd Now, by pure luck I found that if you add "vfs objects = shadow_copy2" to the share's Samba extra config no more crashes and server side copy always works like it did before, no idea why this helps since I'm not using shadow_copy.

Correct.