itimpi

The plugin detected there was a disk change - so the restart should have been abandoned. Need to look at why it was allowed to proceed Edit: Looking at he code a test was backward which allowed the restart to continue so it is a bug I will fix for next release.

No idea. The Parity Tuning plugin assumes that once you have started an array operation you cannot start a new different one without the current operation either completing or being abandoned. Not sure how one could create this scenario but perhaps something I need to look at if we think that is what occurred. Even then, though, it is still a mystery as the plugin will not specify a position, but merely ask the system to resume the existing operation. The only time the plugin would specify a position is in the very special case of having the option to restart an array operation set and then stopping (cleanly) the array and starting then either restarting the array or rebooting. Is it possible that has happened here? If so maybe the restart logic needs an additional check that you are about to do the same type of array operation as was in progress when the array was stopped although there is already a check that the disks are the same as they were when the array was stopped and their status has not changed, although maybe I need to revisit that logic to look for a case that is being missed.

Rather than remove the parity check plugin you can simply set it to not pause parity checks.

You appear to have a corrupt docker image. You should really push the full diagnostics zip file as then you are more likely to get useful feedback.

Yes.

It should also be in the diagnostics as well since the Mirror to Flash option is set as well as putting the serves address into the Remote Server field. Normally you only set one of those two fields.

You are likely to get better informed feedback if you attach your system’s diagnostics (with everything in the one zip file) to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

You can connect via USB for the Preclear. However doing so will make no difference to the rebuild which ignores the Preclear so the only purpose would be to stress test the drive before using it in the Unraid array.

Prec Existing contents are irrelevant. A Preclear is unnecessary (unless you want to first stress test the drive) as the rebuild process overwrites every sector on the drive so any Preclear gets overwritten anyway.

It should only say that if the Apply button WAS enabled and pressed (or if you have never started the array since the last reset). If you return to the Main tab and the drives all have blue icons then you are good to make changes and then commit the changes by starting the array.

That sounds about right for the default with the latest versions of XFS. It is possible to reduce this if one manually reformats the drive without reflink support if it really bothers you.

Did you remember to tick the “yes I want to do this” checkbox? You need to do that to enable the Apply option. If in doubt do not initially assign a parity drive as getting that wrong can lead to losing any data on it.

Never heard of any problem doing this. I believe at the top level 512 byte sectors are assumed and mapping this onto what a drive actually supports is handle automatically within the relevant drivers.

Your data should be fine. Since you have the licence key file then you can follow the procedure described here to get your drives sorted. If at any stage you have questions feel free to ask them

I suspect this is unlikely as Limetech have years of roadmap items left to do on the x64 version. Be nice to e proved wrong though.

That is not the default as the the default is to use a docker.img file located under /user/system so you changed things from the default. Using a directory is not wrong - just not the default. That location is where all the binaries for docker containers live. Its contents can easily be recreated if necessary using Apps->Previous Apps to reinstall containers using their previous settings.

It means rebuild back to the disabled disk to get everything back in sync on the basis that the disk is physically OK and it was an external factor that got it disabled in the first lace.

The appdata permissions are container specific and controlled by the individual containers so there is no default values. When you mention the 'docker' folder does that mean you have configured docker to use a folder rather than an image (which is the default)?

The setting occurs on each share and also on each pool.

You need to look at the contents of the 'emulated' disk1 to see if it looks OK as that is what will be rebuilt to a replacement disk.

This can be a symptom of file system corruption on the flash drive and the attempt to repair changing the folder entry to look like a file. If the flash drive is having issues it might explain your issues (although I could not see any direct evidence of this in the diagnostics).

It looks like many of your shares have a Minimum Free Space of 97GB set and none of your array drives have this much free so mover will not be able to do anything. Reducing this to a smaller value might be a temporary solution, but it sounds like you need to add more disk space to the array.

Have you actually logged into Unraid Connect from the current server? I would think that would get your key registered

The rebuild process works at the raw sector level and has no idea of the meaning of the contents of any sector. It therefore rebuilds a disk exactly as it was preserving hard links.

Is it being seen as a bootable drive at the BIOS level? If not check it is formatted as FAT32.