itimpi

You can do any manual pause/resume that you like and the plugin will not care. With the scheduled ones there is a specific task kicked of at the scheduled time to attempt the required action. If the action is not appropriate (e.g. pause an already paused check) then that task simply exits taking no action. Note that you can use the temperature related pause/resume in addition. If this is active then a ‘monitor’ task is run reasonably frequently to see if a temperature related pause/resume is appropriate. That way if you are having temperature related issues you could get pause/resumes happening within the time period for the scheduled pause/resume, or if you have started the check manually at any time.

Yes. That is assuming the drive you now want to use for parity is already plugged in and sitting in the Unassigned section. When you remove the old parity drive is up to you - it can be done at any time.

Just realised you said you had removed a drive, and this cannot be done without invalidating parity.

Obviously when accessing over the network via a SMB share I do not see the owner/permissions but I do see all the files and have read/write access. This is probably because being FAT32 there is not full support for linux permissions. the big security change was to stop any file on the flash drive being allowed to have ‘execute’ permission. The other change was that the flash drive no longer defaults to being shared on the network.

If you only have parity1 then you can tick the option to say parity is already valid after assigning the disks before you start the array as parity1 is not sensitive to disk order. If you have parity2 then disk order DOES matter and you would need to rebuild parity.

Just stop the array; assign the replacement drive; and then start the array to commit the new assignment and begin rebuilding parity on the new drive.

I never have any problems accessing the contents of the flash drive over the network so there has to be some other factor at play.

Nobody will look at that wall of files. The diagnostics are a single zip file (containing those files), so please post that instead as the zip is MUCH easier to work with.

Maybe it is worth pointing out that the GUI code is open source so anyone is entitled to make changes and then submit them as a pull request to see if Limetech will accept it for inclusion into the standard UnRaid release.

The steps are documented here, but maybe a link from the bit about adding pools is worth adding.

Have you got the ‘destructive mode’ activated in the UD settings?

Perhaps you did not successfully run the New Config step? If so that would have explained your symptoms.

If you misspelt a share name (or got its case wrong) then you would end up writing to RAM rather than physical storage. you might want to get a ls -d /mnt/user/* when you have this problem to ensure that every folder showing there corresponds to a share you have set up and thus a folder on at least one of your drives.

If the Parity Check Tuning plugin ‘misbehaves’ for any reason all it will do is fail to pause/resume the parity check as it should and it therefore simply leaves UnRaid running the check. As such the plugin will not create errors during the check. Regardless you might want to pick up the release I pushed today as it should stop any plugin originated warnings/errors being displayed in the GUI and/or syslog.

Looks like the previous update may have messed up setting cron settings correctly. I have just pushed an update that corrects this and as far as I can see eliminates all plugin related warning/error messages from GUI and syslog. Please report if anything still seems to be wrong after updating to today’s release.

You need to make sure any path starts with a / to avoid it being a relative path.

You should provide your diagnostics zip file so we can see in detail what you did and what is currently happening. A screen shot of the Main tab might also be a good idea if you think there is some discrepancy.

Not quite - you need the Use Cache: prefer setting for this to happen. it is worth pointing out that clicking on the text for that setting will bring up the help text which gives more detail on how each setting works, and how it interacts with mover. There is then even more detail in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI.

That is what I would expect as long as the check was started as a scheduled one. Not sure where you are located but I assume somewhere far east or Australia if it is already 12 noon? If you go to config/plugins/parity.check.tuning on the flash drive what files do you see as that may give a clue as to what type of check the plugin thinks is running. The contents of the .cron file might also be useful to check that the scheduled entries for pause ant resume appear to be correct. BTW: If you want to run one increment a day then the 'daily' frequency option is easier to use and less error prone that the 'custom' one although I admit your 'custom' entry looks OK.

You seem to have some sort of fundamental issue if the docker and libvirt services are failing to start. i would suggest you post your system’s diagnostics zip file (obtained via Tools -> Diagnostics) so we can get a better idea of what is going on and give informed feedback.

Was the share name one that anonymised would show as F———-s? If so according to the diagnostics it appears to exist on disk2 so it might be worth checking that disk explicitly to see if the files are there.

UnRaid only creates the folder for a share on a drive when it first writes a file to that drive. there is nothing stopping you manually creating the folder corresponding to the share name on the drive and if you do so UnRaid will automatically consider it as part of the share.

it should be safe to make the changes on a live system as even if you get them wrong you are only likely to affect the FTP component., and since that location is only in RAM a reboot would always revert back to the standard Released file. Just make sure you backup any changes you make such as copy the changed file to /boot (the flash drive) if you intend to reboot and not lose your changes. The change could well end up being quite trivial once you have worked out exactly what is needed - it is just a case of someone investing the effort to get it right.

The error message is from the plugin (which I am currently doing some correcting work on) but it should not be the cause of the parity check failing. In fact I thought that particular error message was already fixed in the latest version of the plugin so what version do you have?

I believe it is actually a bug in 6.10.0 rc1 that the setting does not default to Enabled.