itimpi

The file I am interested in knowing the contents of is the paritytuning.cron file in the plugin’s folder on the flash drive. That will have the cron settings that are specific to the plugin.

Wait for me to get the version with logging to flash support released - should help with gathering useful diagnostics. Hopefully that will either be later today or sometime tomorrow.

Agreed - a bit puzzled at the moment why you get the behaviour you see.

Nothing if that is the case - I thought you had it started earlier. Might want to check the times in the .cron file in the plugins folder are correct? Also I am not sure if the switch to Summer time can affect such scheduling putting them an hour out? Ad the moment I have not reproduced your issue. I should shortly have the extra logging option available which would help with debugging.

Yes - but if you had already started the check before the fix for the syntax error was released then the plugin would have missed the fact it was a scheduled check.

OK - sounds like the current issue is a side-effect of the fact the check started while there was a syntax error in the plugin and so there is probably not a new bug for me to fix. If you see anything similar on a new check then please let me know. can you please post (or just look at) the contents of the .cron file in the plugins folder on the flash drive. That should show the times that have been set for the plugin related tasks to run. If the pause and resume tasks do not agree with the values you have showing in settings then making a nominal change and hitting apply should cause that file to be regenerated. Having said that the message you are showing in the screen shot looks like a standard unRaid rather than one from the plugin so if you think the times in the .cron file look correct I would be interested in the syslog covering that period to see what shows up there.

was this a new check or the original check still running? The reason for asking is that if it was the original scheduled check then the plugin would not have caught the start due to the syntax error, and in such a case would assume that it must be a manual check as they do not have an event the plugin can catch so manual is then assumed by default. I wonder if it is worth me thinking about making a change to the logging so that there is a mode similar to the current ‘Testing’ mode where all log messages from the plugin are written to a log file in the plugins folder on the flash drive instead of or perhaps as well as the syslog. This would give an easier way of seeing all plug-in messages for a complete run without filling up the syslog and would give a file it is easy for someone to send to me. The original reason for using syslog was it often helps to see what the plugin was doing timewise relative to other things going on at the unRaid level. Maybe use some radio buttons or check boxes opposite the logging option in Settings to allow the destination to be specified? Logging to syslog does have the advantage of only going to RAM so avoiding unnecessary writes to the flash drive. I’ll think about that as it should be easy to do and may well help with support.

It is worth pointing out that forum support is by members rather than Limetech so you will normally only get any feedback when somebody thinks they have something to contribute.

I notice that parity has quite a few re-allocated sectors. While not a concern as long as that number remains stable it is certainly one to keep an eye on as if it keeps increasing the disk is probably on its way out.

If New permissions is not fixing your problem then the fix is by no means obvious. we probably need to see the output of a command of the form ls -l path-to-check command run from the console on one of the problem directories do we can see what the permissions actually are while this problem is occurring to have any chance of working out why this is happening.

Don’t worry - I do not think that restriction is that obvious. It is a security measure.

The ‘root’ user cannot be used to access secure or private shares.

The screenshot appears to show adding both a parity disk and another data drive at the same time. This is not allowed - they have to be done separately. The New Config tool allows you to do this in one step.

I have never has a disk that has a non-trivial number of reallocated sectors rejected by Seagate so it seems unlikely there would be a problem as long the SMART information in Seatools shows that reallocated count (and I do not see how it could fail to do so).

What version are you running? The syntax error you are seeing was should be fixed in yesterday's release (2021-03-30) that was introduced in the 2021-03-29 release the previous day. If you DO have the latest release let me know so I can work out what information might help diagnose the problem. If you do NOT have the latest release then I think you will find updating to is also fixes your other problems as the syntax error stops the plugin executing correctly.

Tools -> New Config WILL work. From your screen shot you seem to not have set the slots that had parity drives to "unassigned" (and possibly shuffled up the data drives)? I prefer to use the option to preserve current assignments as it means you have less changes to make when you return to the Main tab to correct any drive assignments to their final settings to there is less chance of making an error. It puts the array back into a state where no drives are yet committed to the array and you can make changes before starting the array to commit the changes. At this point you want to unassign the parity drive(s) from being a data drive and assign the it to the parity slot. Now when you start the array parity is rebuilt based on the current assignments. It is important that you do not assign a data drive to a parity slot as that would result in its contents being lost as they get overwritten with parity information.

The standard answer to this is to start by assigning ALL disks as data disks and then starting the array. Parity disk(s) have no file system and will always show up as unmountable. As long as the number of unmountable disks is equal to the number of parity disks you had then you have identified the parity disk. At this point make a note of the serial numbers and you can then use Tools->Jew Config to get back to the point of assigning disks to the array and this time you can set up the correct parity disk. Is that simple approach does not work ask again for advice on how to proceed.

@JokesOnYou77 If you spot any such discrepancies then please continue to point them out so they can be corrected. it is worth pointing out that the help built into the GUI should always be considered the most authorative source as that will be created by whoever is involved in the implementation.

this is what the backup option available by clicking on the Flash drive on the Main tab does. It is really only the config folder that is important as all the files that are at the root of the flash drive are fixed for any given unRaid release - all user specific settings are in the config folder.

This could mean that the built-in GPU uses RAM for buffering and that you have a RAM issue. Worth running memtest to check that passes OK.

Probably worth posting new diagnostics to see if there is the same 5 minute gap? Interesting that the original UD message I posted mentioned the network not being available - any idea what might be behind that?

There appears to be a roughly 5 minute gap in the log which finishes with ar 30 15:52:42 Unraid unassigned.devices: Cannot 'Auto Mount' Remote Shares. Network not available! It might be worth disabling that auto mount to see if that is the problem? If it is then at least we know in what area the problem lies.

I would think yes so that the diagnostics show what is happening when you are encountering the problem.

I realized that after posting the comment, but since the comment was still valid I decided to leave it One good side-effect of this last release issue is that it has prompted me to add syntax checking of the plugin's files to the scripts I use for automating deploying files and building the package so hopefully any such issue is less likely to make it into a release in the future.

Dropbox suits my style of working because of its ability to sync between multiple machines meaning I can edit on whatever one I am currently using and the changes get synced to everywhere accessing that Dropbox location without me having to take explicit action. Pushed a release that should resolve the syntax errors.