itimpi

Normally ANY XMP profile is an overclock and bad for stability.

That is the Connect plugin logging.

Not quite sure why it is not working for you? I click on the leftmost icon for the flash device and it takes me into a view showing the folders and files on the flash device. When I navigate to the config folder and click on the ‘go’ file it opens it up for editing.

As I said have you gone to the ‘Boot Device” section of the Main tab? The screenshot is only the ‘Array Devices’ section of the Main tab.

Did you try clicking on the boot device on the Main tab to get to the flash drive?

If you install the Dynamix File Manager plugin it should allow you to edit text files

I think the problem lies somewhere within the Linux kernel (probably in a driver) - not in any code developed by Limetech. Newer Unraid releases tend to use newer kernels and rely on kernel level issues being fixed by the maintainer of any particular component. That is why it is so hard to track down the cause. Note that this is not a 'new' issue as it has happened for some users for many Unraid releases. It is just that something in the Linux kernels being used by the latest Unraid releases seem to mean it occurs more frequently and/or on a wider variety of different hardware.

You could use a Trial licence to build out the new machine. On completion you could then copy the 'config' folder for the new machine (except for the trial licence key file) to the flash drive with the Pro licence to transfer the settings of the new machine to it.

The syslog in the diagnostics is the RAM copy and only shows what happened since the reboot. It could be worth enabling the syslog server to get a log that survives a reboot so we can see what happened prior to the reboot. The mirror to flash option is the easiest to set up, but if you are worried about excessive wear on the flash drive you can put your server’s address into the Remote Server field.

the biggest culprit recently has been the Connect plugin doing excessive logging. The latest update to the plugin fixes this, but you then need to reboot to get the log space reset.

Are you sure you have the right cables for connecting the drives? Forward and reverse cables look identical but are wired differently.

OK. Normally a write error makes Unraid disable the drive. I only see read errors in the syslog. It might be worth running an extended SMART test on it (either before or after it has been replaced) as failing that is the best indication that a drive needs replacing.

Strange then - the diagnostics do not show that disk11 has failed. In them it is marked as OK.

I assume that we will need to wait for a new Unraid release before this problem can be fixed. I have seen suggestions that 6.12.7 might be imminent. That would be expected if you have uninstalled the plugin as you mentioned earlier? That folder should always be there if the plugin is installed.

If you have the Dynamix File Manager plugin installed then you can navigate to the plugins folder on the flash drive /boot/config/plugins/parity.check.tuning/ to get a file listing.

Which disk is disabled/failed? Your diagnostics suggest it is parity2. If that is the case then you can stop array assign new 8TB drive to parity2 start array to rebuild parity2 The parity swap procedure is needed when it is data drive that has failed and you want to upgrade parity and re-use the old parity drive to replace the data drive as a single operation. In fact if the failing drive IS parity2 then you could replace parity1 with a 8TB drive at the same time as replacing parity2 and rebuild both parity drives simultaneously (keeping the old parity1 intact just in case something goes wrong with a data drive while rebuilding the parity drives).

Not sure I understand the question - you just plug in two dummy flash drives and configure one of them as parity (making sure it is the larger one if they are not the same size).

If you want to stop using a parity drive you can simply stop array; unassigned parity drive; restart array to commit change

Did you run without -n (the no modify flag) ?

It does - at the point the file is first opened and has 0 size. If the free space is below Minimum Free Space at that point another drive is chosen. Once the drive is chosen Unraid does not change its mind if the file subsequently does not fit - it gives an out of space error. That is why you want have to have a value for minimum free space that is larger than the biggest new file that might be written to the disk.

Normal mode

If you btrfs that has built-in check summing for detecting bitrot.

More often than not when a drive is disabled (because a write failed) it was due to an external factor and the drive is physically OK.

If the CPU fan is OK perhaps the thermal paste needs renewing?

Good - that helps when looking at diagnostics to look at issues regarding share settings.