itimpi

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread. The syslog in the diagnostics is the RAM copy and only shows what happened since the reboot. It could be worth also 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.

1 parity drive can handle 1 drive failing.

Not sure if it is intended to make it into 6.13 or we need to wait for 6.14.

I think it should be 0 3 * * * Note that space is a field separator so there should be 4 spaces between the 5 fields.

The system powering itself off almost invariably indicates a hardware issue with the most common culprits being the CPU overheating or the PSU struggling (unless you are explicitly running something to power it off).

You can always put in a small flash drive that you do not intend to use for storing anything to satisfy the current requirement of having at least one array drive.

The problem is the cron field - there should be 5 fields and you have 4. Is there perhaps a missing space between 0 and 3?

Not as far as I know.

I had to click on it a couple of times before it responded.

Have you restarted the array in normal mode and then checked the disk contents as it should now mount.

It occurs to me that I nice little GUI enhancement might be to make the green/grey icon indicating spindown status clickable to switch just that drive to the opposite state?

Messages about the bz* files are independent of the config as they are loaded and checked before the later stages of the boot process when the 'config' folder starts coming into play.

Not the same plugin! Notice the missing 'd' at the end of the name of the warning - that is the one that is deprecated.

Did you mean this? You should have a config folder not a file. This indicates a problem reading some of the archive files off the flash drive. Normally easiest fix is simply to rewrite all the bz* type files on the flash drive. If this does not work it could mean that the flash drive is starting to fail.

Note that ‘unbalance’ is now deprecated on the 6.12.x releases and is superseded by ‘unbalanced’ (note the extra ‘d’) which is what should be used going forward.

Regarding the unreliable booting, have you checked that your BIOS battery is OK?

This is effectively a pool->pool move which is not yet supported.

I think you have to have at least a folder corresponding to the User Share name on the pool for this to be included in the size. i guess the real question is why use a pool of that size to act in a cache role? Would it not be easier to have another pool of a much smaller size acting in the cache role for the array?

That should work, although you do need to have a flash drive on the same release passed through to the VM. You then have to be careful that when installing a new release you update both VMDK and the flash drive to that release at the same time as if they are on different releases the subsequent boot will fail.

Did you delete any existing partitions so that Unraid could partition and format it?

Nerdpack is not compatible with 6.12.6 (it has been replaced by NerdTools).

You should be able to do two at the same time. just a thought - are you sure your PSU is up to handling the extra load from 2 drives?

That means there is some sort of error in the settings for that script in the User Scripts plugin. Posting a screenshot of the relevant part of Settings->User Scripts should allow us to see the error and advise the fix.

That output suggests there is some level of corruption. You ran with the -n option (the no modify flag) so nothing was fixed. To actually fix it you need to run without -n (and if it asks for it add -L). After that you can restart the array in normal mode to see if the drive now mounts. I expect it will, so you then need to look for a lost+found folder which is where the repair process puts any folders/files for which it could not find the directory entry giving the correct name and gives them cryptic names instead. Not having this folder is a good sign that the repair went perfectly. However if you DO have that folder you have to sort its contents out manually or restore any missing files from backups (which is normally easiest if your backups are good enough).

Yes - If there is something interfering with the connection to the host this may mean the drive needs replacing even though otherwise it may be perfectly healthy. If the drive passes the extended test (which checks its internals thoroughly) maybe it is worth looking at that connector again before scrapping the drive.