JorgeB

If that's a straight shelf the HBA will work, you just need to connect one cable, some more info here: https://forums.servethehome.com/index.php?threads/emc-ktn-stl3-15-bay-chassis.23244/

Using the CLI instead of the GUI.

That happens when using different capacity devices with RAID1, but used and free space will be correct, if using v6.9 or newer.

In my experience btrfs fs corruption is most often caused by hardware issues, mostly RAM or device firmware related.

You can try btrfs repair as a last resort but probably will need to restore from backups.

There's also fs corruption on disk21.

Nov 19 09:28:27 Storage kernel: Call Trace: Nov 19 09:28:27 Storage kernel: fh_getattr+0x45/0x5f [nfsd] Nov 19 09:28:27 Storage kernel: fill_post_wcc+0x2c/0x94 [nfsd] Nov 19 09:28:27 Storage kernel: fh_unlock+0x12/0x33 [nfsd] Nov 19 09:28:27 Storage kernel: nfsd3_proc_rmdir+0x4a/0x4f [nfsd] Nov 19 09:28:27 Storage kernel: nfsd_dispatch+0xb0/0x11e [nfsd] Nov 19 09:28:27 Storage kernel: svc_process+0x3dd/0x546 [sunrpc] Nov 19 09:28:27 Storage kernel: ? nfsd_svc+0x27e/0x27e [nfsd] Nov 19 09:28:27 Storage kernel: nfsd+0xef/0x146 [nfsd] Nov 19 09:28:27 Storage kernel: ? nfsd_destroy+0x57/0x57 [nfsd] Nov 19 09:28:27 Storage kernel: kthread+0xe5/0xea Nov 19 09:28:27 Storage kernel: ? __kthread_bind_mask+0x57/0x57 Nov 19 09:28:27 Storage kernel: ret_from_fork+0x22/0x30 Nov 19 09:28:27 Storage kernel: ---[ end trace 83e36f2bb8ca0fa2 ]--- nfsd is the NFS daemon.

Not really, just that NFS crashed bringing down the user shares.

For NVMe devices is /dev/nvmeXn1p1 Replace X with correct number.

Server is constantly running out of RAM, check memory allocations.

Should be fixed.

AFAIK only a reboot will fix it, also it was caused by NFS, so disable if you don't need it or can change everything to SMB.

You can use for example the CA backup and restore plugin.

First thing is to run xfs_repair.

If don't have an appdata backup you'll lose the settings.

Unfortunately there's no kernel panic or nothing else relevant logged before the crash, lots of log spam though, there's a nf_nat call trace earlier, so see if the below applies to you, if yes, 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/

It's a known issue, it's just the GUI, device is not actually being read.

Enable syslog server and post that log after the next crash.

There's fs corruption on that device, you can see here some recovery options.

That's strange as that would suggest there's no valid filesystem, syslog suggests otherwise, please disable array auto-start, reboot, start the array in maintenance mode and post the output of: xfs_repair -v /dev/md9

Go to Settings-> VM Manager and set a valid path for "default ISO storage path".

Diags after array start please.

It's a btrfs issue, it has to do with the number of devices, with raid10 it will show the correct stats with 4, 8, etc.

Please post the command you used to run xfs_repair.

Yep, IP from eth0.