Kilrah

That is about docker filesystem storage, not RAM. Post diagnostics

fTPM is fine.

Preclear Add THEN once part of the array you get the option to format.

Delete and recreate it with the new name?

Those don't support RAID, being able to have mirrored boot drives was kind of a primary feature.

Replace the config folder on the USB with the one from the internal boot pool, then it'll have all your changes. Gotta understand and be ready to mess with that kind of stuff when running unfinished betas.

Check min free space setting on your backups share.

?

Looks OK

The home keyboard key, not browser icon. He's talking of the forums, some have something like this.

At least without folderview there is a basic/advanced toggle for each of the unraid and the compose section.

Unraid doesn't get "installed" to them but stores data on a configured array or pool. If you have neither of these it can't. You likely have at least one of those on your existing server.

No, it's because you don't have any storage assigned for unraid itself to use. You can assign full drives for VMs but you still need at least one more drive to make a pool for Unraid itself to store the system share (and appdata if you want to use Docker).

First post wasn't updated with clear "how to migrate" instructions though. Do Compose Down on your stacks, go to Apps, search for compose manager, select Reinstall, up your stacks again.

Looking around the only reason I can see is that you have your default container name set as "Pihole-DoT-DoH" so CA probably sets the main appdata folder as "/mnt/user/appdata/Pihole-DoT-DoH" to match the name. May or may not be considered a bug in CA but I guess you should be able to circumvent it by just not messing with case in the container name.

Anything reading/writing to the array while the rebuild is running will slow it down. Avoid any activity if you want it to run as fast as possible.

Search for the "ata13.00" in syslog, you'll find a line with the drive model, then refer to your main page Mar 23 12:53:55 Tower kernel: ata13.00: ATA-11: ST10000NE0008-2PL103, SN04, max UDMA/133

Disk6 keeps having connection errors and being reset/downgraded to SATA 1 speeds, check/replace SATA cable. Mar 23 13:41:50 Tower kernel: ata13: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Mar 23 13:41:50 Tower kernel: ata13.00: configured for UDMA/33 Mar 23 13:41:50 Tower kernel: ata13: EH complete Mar 23 13:41:53 Tower kernel: ata13.00: exception Emask 0x10 SAct 0x1f000 SErr 0x4890000 action 0xe frozen Mar 23 13:41:53 Tower kernel: ata13.00: irq_stat 0x0c400040, interface fatal error, connection status changed Mar 23 13:41:53 Tower kernel: ata13: SError: { PHYRdyChg 10B8B LinkSeq DevExch } Mar 23 13:41:53 Tower kernel: ata13.00: failed command: READ FPDMA QUEUED Mar 23 13:41:53 Tower kernel: ata13.00: cmd 60/98:60:30:60:12/03:00:03:00:00/40 tag 12 ncq dma 471040 in Mar 23 13:41:53 Tower kernel: res 40/00:01:04:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Mar 23 13:41:53 Tower kernel: ata13.00: status: { DRDY } Mar 23 13:41:53 Tower kernel: ata13.00: failed command: READ FPDMA QUEUED Mar 23 13:41:53 Tower kernel: ata13.00: cmd 60/10:68:c8:63:12/02:00:03:00:00/40 tag 13 ncq dma 270336 in Mar 23 13:41:53 Tower kernel: res 40/00:0d:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Mar 23 13:41:53 Tower kernel: ata13.00: status: { DRDY } Mar 23 13:41:53 Tower kernel: ata13.00: failed command: READ FPDMA QUEUED Mar 23 13:41:53 Tower kernel: ata13.00: cmd 60/c0:70:d8:65:12/04:00:03:00:00/40 tag 14 ncq dma 622592 in Mar 23 13:41:53 Tower kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Mar 23 13:41:53 Tower kernel: ata13.00: status: { DRDY } Mar 23 13:41:53 Tower kernel: ata13.00: failed command: READ FPDMA QUEUED Mar 23 13:41:53 Tower kernel: ata13.00: cmd 60/30:78:98:6a:12/04:00:03:00:00/40 tag 15 ncq dma 548864 in Mar 23 13:41:53 Tower kernel: res 40/00:01:e0:4f:c2/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Mar 23 13:41:53 Tower kernel: ata13.00: status: { DRDY } Mar 23 13:41:53 Tower kernel: ata13.00: failed command: READ FPDMA QUEUED Mar 23 13:41:53 Tower kernel: ata13.00: cmd 60/50:80:c8:6e:12/04:00:03:00:00/40 tag 16 ncq dma 565248 in Mar 23 13:41:53 Tower kernel: res 40/00:01:e0:4f:c2/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Mar 23 13:41:53 Tower kernel: ata13.00: status: { DRDY } Mar 23 13:41:53 Tower kernel: ata13: hard resetting link Mar 23 13:41:59 Tower kernel: ata13: link is slow to respond, please be patient (ready=0) Mar 23 13:42:04 Tower kernel: ata13: hard resetting link Mar 23 13:42:09 Tower kernel: ata13: link is slow to respond, please be patient (ready=0) Mar 23 13:42:14 Tower kernel: ata13: hard resetting link

Before the beta released the video showed it using btrfs, but it was changed to zfs cause btrfs caused problems (not sure which). Better have something that works than something that doesn't I guess.

If there isn't a pool named "cache" that would be mounted as /mnt/cache then that path doesn't have anything mounted to it and will be in RAM. It's fine, it's bad template publising practice to use default mounts that may not exist, publisher should fix.

Maybe say for what reason?

Any manually created top level folder on a drive will see a share automatically created with default settings.

So you're the one who carried out malicious activity, got it.

If you still have access to that account then either you got hacked and someone used it without your knowledge and you need to change your passwords/credentials/revoke any access to 3rd party apps or you should know why.

Would disable Docker, reboot, try again, if it doesn't help check filesystem on the disk in question.