itimpi

That cannot be all if it is working. I assume that what you have posted is the contents of a .page file? - If so it is missing all the HTML elements. The function being called is a Javascript function and your code shows no HTML elements that put it inside a <script> tag.

The default size of 32M should be more than enough unless an application is mis-behaving Looking at the contents of /run might give you a clue as to the culprit. Making it larger would just delay the issue occurring, not fix the problem.

You do not normally need to touch these services.

Strange - your diagnostics show that they DO exist and are on disk1. If you have an ad-blocker installed then you should whitelist your Unraid server. Alternatively try a different browser to see if that helps.

it might be worth doing: cat /etc/cron.d/root from the command line to see if there is anything scheduled to run hourly.

If it did not start a parity check this almost certainly means that a shutdown command was issued at the server for some reason. Have you eliminated any physical possibility such as someone (or a pet) momentarily pressing the power button on the server? To get persistent logs that cover a reboot sequence you need to enable the Syslog Server so that if this happens again you have something that we can look at for a possible cause.

If you are using btrfs then you may not need this plugin as it has built-in checksumming for detection of bitrot.

It depends on the Share settings whether items get moved to the array. This only happens for shares with Use Cache=Yes set. Shares such as ‘appdata’ and ‘system’ are typically set with Use Cache=Prefer which keeps them on the cache pool. Shares to Use Cache=Only or Use Cache=No are ignored for moving files after initial placement.

You WANT the regularly scheduled check to be non-correcting so that hardware issues do not inadvertently corrupt parity. When you expect to have parity errors and you think the hardware is fine, that is when you run a correcting check manually to clear the errors.

This

Fsck files are created during the boot process when attempting to fix corruption detected on the flash drive. It is possible the flash drive could be about to fail.

There is nothing wrong with pointing directly to a folder on a pool as all top level folders on any array drives or any pools are automatically part of the User Share with the same name as the folder. It has the advantage that as it is by-passing the User `share fuse support level it tends to give better performance. However since Linux is case sensitive it is important that the path has the same case as you put in the path.

Have you thought of instead of a custom script using the CA backup plugin to do the backups and also have the Parity Check Tuning plugin installed (and have the option to pause array operations if the backup is running enabled in its settings) to handle the pause/resume of array operations.

What share have you set to hold the iso file (the normal default is ‘isos’). What is the Use Cache setting for the share holding the iso files. We may be able to give better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

The diagnostics show that your docker.img file is corrupt. Since FCP is also warning about not being able to writ to the 'cache' pool that may also be corrupt. At the very least the docker.img file will need to be deleted and then recreated followed by re-installing your docker containers with settings intact via Apps->Previous Apps. I also notice that you have not set a Minimum Free Space value for the 'cache' pool. You want this to be more than the size of the largest file you expect to cache as BTRFS file systems tend to have problems if they get too full.

Yes. You then use the servers tunnel address to access it rather than its local LAN address.

This sounds like an issue that needs resolving anyway. I would never expect a reboot to mean a drive needs rebuilding if things are working as expected.

The fact that the drive appears unmountable strongly suggests that the drive is not being presented exactly the same over SATA as it was over USB. This is not an uncommon occurrence. If that is the case it will almost certainly be necessary to start with the disk outside the array, and copy the data onto the array after which the disk then can be added and formatted as Unraid likes to have it formatted.

The automatic check after an unclean shutdown is non-correcting. You normally only want to run correcting checks manually.

It looks like disk4 was assigned at some point in the past and never removed cleanly so Unraid has been emulating it.

When you split up the parity check (either using standard functionality or the plugin) the split is done on a time basis rather than a %. This makes sense anyway as the check speed is not constant (e.g. it slows down as inner tracks are reached). The plugin allows for additional factors to be taken into account such as whether mover is running to adversely affect each others performance.

Any parity operation will do both parity drives in parallel. The time is likely to be the same as the parity build which with modern large drives can be quite extensive. You may want to install the parity Check Tuning plugin if you want more control than is given by the Unraid built-in options.

Actually this will not work as expected as any such edit will not survive a reboot since that location is only in RAM and also Unraid may wipe out the edit at any time. Using User Scripts plugin takes care of this persistence issue.

No, but it is the drive you rebuild, not parity. Replacing the drive requires rewriting every sector on that drive with its new contents and during that process Unraid will be reading from all the other data drives and the parity drive to reconstruct it’s contents. There is no need to first copy the data elsewhere as the rebuild process puts back the contents. It’s a good idea, though, to keep the removed disk intact until the rebuild finishes just in case anything goes wrong during the rebuild.

You could try plugging the drive that prevented the controller initialising into a motherboard port to see if it works there. Since you only have a single parity drive you cannot recover 2 drives failing so you need to get that back to be able to recover the other one.