JorgeB

This.

You can do it now, though if containers will be doing a lot of reading or writing to the array it will affect rebuild time.

This part is strange, lets see how it goes for others.

System and domains are on cache, and that is fine, data is mostly on disk1, but like mentioned any new data written to that share goes initially to cache, that is expected behavior.

Negative Ghost Rider, you need to wait for v6.11.1, it should be out soon.

Sep 28 11:50:56 Ascension emhttpd: shcmd (520): mount -t btrfs -o noatime,space_cache=v2 /dev/sdc1 /mnt/cache Sep 28 11:50:56 Ascension root: mount: /mnt/cache: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error. Your cache is not mounting, and no valid btrfs filesystem in being found on boot, are you sure it was btrfs? You are using a raid volume, that might be the part of the problem, it might have change something: import 30 cache device: (sdc) LOGICAL_VOLUME_5001438016327E90_3600508b1001c52ba5e10bd5d90a2e4dc

And Unraid agrees: Try typing in the console: unraid-api restart If that doesn't help you should contact support and they will replace the key for you.

If they use a Matrox GPU it's a known issue, a driver will be included on the next release, hopefully it helps.

Then you can rebuild, just stop the array, re-assign the disk and start the array to begin.

Try wiping it with "blkdiscard -f /dev/xxx", if that doesn't help post the diagnostics after a format attempt.

Shares are not showing in the diags, go to shares click "compute all" and post a screenshot.

For eth0 looks more like a connection problem, try replacing the cable or using a different switch/router eth1 crashed, only a reboot will fix that: Sep 29 05:36:42 fs kernel: DMAR: DRHD: handling fault status reg 2 Sep 29 05:36:42 fs kernel: DMAR: [DMA Read] Request device [05:00.1] PASID ffffffff fault addr f4a19000 [fault reason 06] PTE Read access is not set Sep 29 05:36:42 fs kernel: DMAR: [DMA Read] Request device [05:00.1] PASID ffffffff fault addr f9d54000 [fault reason 06] PTE Read access is not set Unrelated but the server is detecting RAM errors, should fix that.

You can check with: lsattr /path/to/file If the output is ---------------C------ nocow is set, if there's no C it's not set.

I would suggest installing an add-on NIC to test, if that's an option.

Check that contents look correct, also look for a lost+found folder any lost data there, if all looks good rebuild on top, might be a good idea to replace/swap cables first to rule that out if the same thing happens again. https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself

This looks more like a compatibility issue, look for a BIOS update for the board, also for a firmware update for the disks, failing that best bet would be trying with a different controller (or board), many users using the same model disks with Unraid, so it's not an Unraid/Linux issue.

Correct, you can add parity and/or more data disks at any time.

What do you mean by this? With cache=yes any new files written to that share will go to cache.

You cannot start the array with only parity assigned, if you are going to use a single device for now assign it as disk1.

Diags are not showing, so go to shares click on compute all and post a screenshot of the results.

If booting UEFI try legacy or vice versa.

Try recreating the flash drive, backup current config folder, recreate it manually or using the USB tool, restore the config folder.

It does a full surface test, though there are some utils you can use that also show for example slow sectors, and those won't be in a SMART test result.

You'd need to move the data, re-create the share with cow=auto and move the data back, VMs must be off during that.