itimpi

You should boot in Safe mode to disable plugins being loaded and then see if the dashboard loads. If it does you then know you have a plugin installed that is incompatible with the 6.12.x releases and you can start looking into which one it is.

The CRC errors (which indicate connection issues) never reset. You can only make sure they do not keep increasing.

Yes - you write a simple script to delete the file(s) and then restart Plex. You then schedule this in User Scripts to run when you want,

You can install the User scripts plugin which should make this easy to achieve.

There have been reports that this can happen if you have a device (e.g. android phone) left with a bowser window open to the server. Also been mentioned in conjunction with Edge browser with option to sleep tabs activated. I do not get this issue myself so not sure if either of those are legitimate causes but worth checking out.

You might want to try running du -sh /var/log/* in case the logs of concern are in a directory.

There seems to be rc1 available if you switch to the Next branch. As to when it will reach Stable status will probably depend on whether rc1 fixes enough issues (without producing new ones) to justify this happening.

No. The parity check tuning plugin never initiates a parity check from the beginning, it relies on Unraid to do that and the plugin then handles pause/resume. The only time the plugin initiates anything is when there was an array operation in progress at the time of the shutdown AND you have set the option to restart operations from point reached AND the shutdown was a clean shutdown. Even then whether it is correcting or non-correcting will depend on what it was before the shutdown. Starting a correcting parity check after an unclean shutdown looks like new behaviour at the Unraid level. I am sure this check used to be non-correcting so not sure if this is a bug or is by design.

Spotted nothing obvious in the diagnostics and it looks like the GUI should be available on 192.168.1.16. have you tried clearing your browser’s cache? Have you tried booting in Safe Mode in case you have a plugin causing problems?

It looks as several of your drives (parity, disk2, disk3, disk4) have dropped offline. Do they have anything in common? You should shut down the server and carefully check the power and SATA cables to the drives.

Have you checked to see if you have a lost+found share? That is where the repair process puts any files or folders for which it could not find the name but with cryptic names. However if you have such content you can only sort it out by manual examination.

I am not sure that is how your settings are being interpreted 😊. It might be worth looking at the entry that has been generated in /etc/cron.d/root to see what is actually set.

That is nothing to do with the plugin as it never initiates the parity checks. It must be a bug in the core Unraid system that does not handle correctly your settings. To be honest, I cannot see what you are trying to achieve. Why would you want to start a parity check every day during some months, and not at all during other months.

That suggest the flash drive is not being found correctly in the later stages of the boot sequence. It could mean the flash drive is failing, but often simply rewriting its contents can fix such issues.

Just go into Settings->Scheduler and set it to be non-correcting. I would not worry if that is the default or not. you are correct that if there are no hardware issues there is not much you can do except run a correcting check. What you do not want, however, is to run a correcting with a drive playing up which can then lead to parity getting corrupted/made invalid thus prejudicing later recovery

I don’t think the recommendation has changed 😊. As to whether the default setting has changed I am not sure :😒

You need to run without the -n option or nothing will be done. On restarting in normal mode the drive should then mount.

This is a feature of the parity check plugin (which is not a standard part of Unraid). Have you tried switching off its features to see if it has any effect on parity checks completing? In particular the option to shutdown the server if drives get hotter than the limits you specify as you imply you have encountered that.

The cumulative check was added some time ago in the 6.11.x series of releases The parity check tuning plugin will warn you when you go the settings page that you should use either it’s version of running in increments or the one now built into Unraid. The plugin’s version is more comprehensive and flexible so I would think going with it is the better approach

It is Minimum Free Space setting when you click on a share on the Shares tab.

It is worth pointing out that the only reason a SMART test cannot be run is because the drive cannot even be accessed for any reason. If the drive is still online it can be run on a drive marked as disabled.

You can set it to run at any time you like without causing issues except perhaps for some minimal performance impact that is not likely to be noticeable. Just be aware that transferring files to the main array can take considerably longer than the initial writing of them to the cache so bear this in mind when deciding on a time to run mover.

I would suggest searching the boot drive as indicated using 'Freya_Backup' as the search string as that looks unlikely to give many false positives.

Don't see much point in this. You can always manually stop the restarted one and then continue from there.

That shows the entry to run the monitor task every 6 minutes is still there, so I m not sure why it has stopped being run. It is late here so I need to sleep on it and hope some inspiration strikes