JorgeB

Looks like the server is rebooting on its own: Nov 19 18:19:29 mediaserver emhttpd: unclean shutdown detected And then the array doesn't start because: Nov 19 18:19:38 mediaserver emhttpd: Missing encryption key

With google or by trying it.

Please post the diagnostics and the output of fdisk -l /dev/sdX replace X with the correct letter for disk1 for example.

No, though bad power can damage a drive.

Double post:

It's not fixed. Yes, if there's no data there or it can easily be moved.

See here: https://forums.unraid.net/topic/115767-solved-unraid-v692-upgrading-cache-pool-drive/?do=findComment&comment=1052576

It's because of the way Unraid calculates the total capacity, not long ago the free space would also be incorrect in that circumstance, but that was fixed starting on v6.9, IIRC.

Delete BTRS.key from the config folder, it's an invalid key or a cracked one.

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/