MowMdown

I suggest running a memtest from the boot screen for 24 hours to rule out the potential for bad ram.

Please post diagnostics

sounds like you have something mapped using /mnt/cache which would have wrote to RAM since you dont actually have a pool named cache and lost upon a reboot. This would be simply due to a pre-defined path in a container template most likely. the real PSA is always check your paths.

@SimonF This is your dept.

The array is not a pool, it's JBOD + Parity. Each disk in the array is an independent filesystem. Unraid Pools can be single disk (like yours) or multi-disk in a Mirror/RAID configuration (my screenshot).

I attached screenshots of OP's setup in my previous comment, all 14TB disks are known data disks, it's a matter of finding out which of the two 24TB, the 20TB, and the 16TB disks were data disks or parity disks. The 14TB disks however are currently unmountable, how do we correct these so we can mount them? From there how can we identify, of the 4 remaining disks, which two had a valid filesystem vs just being a parity disk?

The situation OP is currently in is all of their disks are shown an "Unmountable" and they are not sure which two are the parity disks. The plan was to attempt to identify which two disks were going to be reported as unmountable to determine which two disks were parity, assign them back to P1 and P2 slots. However we ran into a snag, due to issues with disk assignments missing (old super.dat) it wasnt possible to start the array to use unassigned devices to mount the disks with the RO flag. Plan B was to invaldiate parity by mounting all the disks to the array slots only, after running tools > new config, and then simply identify which two disks didnt mount/have a valid filesystem. Ran into another issue where all of their disks are showing as unmountable. The goal now is to fix the filesystems on the disks that had filesystems and rebuild parity as parity was invalidated. Disks, 1,2,3,5,6 are known XFS disks, Disks 4,7,8,9 are the unknown disks. Note that the 16TB and 20TB were old parity disk assignments and one of these has since been re-assigned as a data disk by OP at some point during a parity upgrade.

You should be able to choose any filesystem type including the encrypted options, you just have to stop the array, erase the data partition, then click on "cache" and select xfs-encrypted from the filesystem menu, then go back and start the array and check the format box Just make sure you move your data out of the cache data partition before you do this.

Please post diagnostics too

You can only format the "data" partition of a single boot disk pool to encrypted xfs, if your boot pool consists of two disks, your only options are encrypted btrfs or zfs. the boot partition cannot be encrypted or changed from zfs.

considering unraid is not a full fledged linux distribution, your mileage may vary with installing such packages if their dependencies are not found. If you really insist on having those you need to find them on slackware's package site and you can place the .tar.gz file under /boot/extra on the boot USB/disk and unraid will extract and install them on each boot.

It appears that disk2 connection issues have been corrected, I dont see any connection issues in the new logs but now you need to repair the filesystem Stop the parity check. Stop the array. Check the "Maintenance Mode" checkbox, then click start array. Once array is started in maintenance mode, click on disk2, then click the check filesystem button, and report back once it finishes. (you can find further information by clicking on the underlined text) Note: If it cannot find a superblock after a few hours, it likely wont find one and you can stop the filesystem check.

Unraid is now very strict about the partition created on the USB drive. You may need to back it up and re-create it, then restore the config folder. This can be addressed later.

check and replace the cables on disk2 "WD40EZAX-00C8UB0" and post new diagnostics

It is new yes.

I really advise against installing plugins outside of CA as there is no validity to those plugins. Considering they run directly on your system.

you need to check your driver version, p2000 needs to be on nvidia 585 or lower to function.

In my opinion this plugin causes more problems than it solves.

Well unraid parity is more like RAID4 but without data striping of any kind. Each disk in the unraid array remains an individual filesystem. RAID1 is just a mirror of two drives which act as a single unit. If you need more technical details I highly suggest reading the unraid documentation as it explains it in detail.

You created two btrfs raid1 pools. If you wanted to use the unraid array you should have instead added the disks to the array slots above the pool section when the array is stopped. Btrfs goes into degraded mode when you pulled a disk, however it was likely in the process of rebalancing itself to single mode before you interrupted it. Please refer to the docs: https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/cache-pools/#removing-disks-from-a-pool To fix this you need to start the array with both disks assigned, let it rebalance back into RAID1 mode. Once that’s done you can remove ONE of the disks, set the slot to “missing” and start the array. Then it will once again balance into SINGLE mode. It will display degraded until the process is complete. You can check the balance status by clicking on the pool name “data” or opening the console/terminal and typing in btrfs balance status /mnt/data

Make sure Fastboot is disabled Check boot drive order in the BIOS to make sure it's booting off the correct device See if there is a BIOS update It cant be related to updating the OS if the OS doesnt even load which it sounds like it's not.

Might be worth a read? https://www.1password.dev/connect/get-started

UGreen DXP2800 has TPM 2.0 so if the USB device doesnt, OP has a backup fallback option. (source I own a dxp2800 running unraid)

Either: You have SAS disks that dont like spin-downs You have plugins reading/polling disks You are running VMs/Docker containers reading/writing to the disks. SMB/NFS client connections waking disks up to read contents. Boot into SAFE MODE, disable docker and VM services from the settings menu, and observe the disks.

You need to check your entire network from start to finish to make sure it is all fully capable of supporting 2.5Gbps, Modem/Router, Cables, NIC, Switches, whatever you are using. All of it has to support 2.5Gbps. If you're using a commercial VPN service, you're likely capped at 1Gbps over the VPN. What does your network widget report?