itimpi

Ok. While appdata is on the array you will need to remember to stop the docker containers to get decent parity check speeds.

That sounds more typical Where do you have your docker.img file located? Ideally for performance reasons you want it on the cache drive as accessing the cache drive does not affect parity check/build speeds. Also if practical you also want any docker mapped drives to be located there for the same reason, in particular the ‘appdata’ share.

10MB/sec sounds very slow but your screen shot suggests something may be writing to disk2 which could easily slow it down to that sort of speed. Writes during a parity check severely degrade its speed. Provide the diagnostics if you want to see if anyone can suggest anything else.

Turn off the Automount in UD. the scripts will be ones run via the User Scripts plugin (which is the first thing I normally install from the Apps tab).

I see from your signature that you like to run an Unraid build of a similar age to the case

The easiest way to achieve this is to not have the mounting handled by UD but have do it via a User Script set to run on array start. For completeness you may want a complementary script to handle unmounting on array stopping.

Anything on the host that is not under /mnt or /boot is automatically in RAM.

Parity may well not have been perfect as a red ‘x’ means a write has failed. the steps you went through are the general case were you make no assumptions about the state of parity. As you were virtually certain that your parity was almost perfect you could have done: stop array use Tools >>> New Config selecting the option to retail all current assignments, On Main tab tick the ‘parity is correct’ checkbox and then start array at this point I would recommend doing a correcting parity check just in case the parity was not as perfect as you thought. I would expect at least one correction to correspond to the original red ‘x’, and this is most likely to happen near the beginning. If you include the recommended parity check in the above steps the total elapsed time is not much different. The difference is that if you were right about the parity being valid then you have more chance of recovering if an array data disk fails during the process.

Just delete the file. UnRAID does not install things in the traditional sense so there will be nothing elsewhere on the USB stick to worry about. To get rid of any remnants of the file from RAM just reboot the server (Unraid always unpacks a ‘clean’ copy into RAM from the archives on the USB stick on every reboot).

No. The parity check always runs flat out according to what your hardware supports. Having said that 6 days sounds too long so not sure what is causing that.

That looks fine - although I would move the comment to just before the line that actually starts emhttp to avoid confusion. You could add some calls to ‘logger’ to add lines to syslog to prove that the file executes and exactly when.

No. Process for updating a MB is determined by the MB manufacturer.

You have far more shares than I would expect to see All top level folders are treated as User Shares, but I suspect that you have accidentally copied a whole series of folders to the top level of one or more drives so these are being treated as User Shares. As the names are anonymised in the diagnostics it is hard to confirm this. You also have both a ‘backups’ and a ‘Backups’ folder on your disks. This will cause problems as Linux is case sensitive while the share system is not. It is possible this has happened because you misconfigured a plugin or docker container.

I do not think we know this to be the case ! Limetech could be trying feverishly to identify the cause and therefore how to fix it and we would not necessarily know about it.

The only other way will be to produce your own customised container so you control updates - but you indicated that you do not want to do this either so I think you are stuck