itimpi

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.

On your server the relevant code will be at /usr/local/emhttp/webGui/FTP.Page in a running system. The GUI code is also available online at https://github.com/limetech/webgui/tree/master/plugins/dynamix so if you can make enhancements to FTP.Page that enhances it without breaking anything then you can submit a pull request to get it included in the standard Unraid release and I would expect the pull request is likely to be to be accepted. by Limetech.

It is really your decision as to how long increments should be, and therefore what the elapsed time should be as the number of increments can be approximately derived from the time the check would take if no increments were involved and dividing by increment length. I say approximately as any other disk activity going on at the same time as a check can slow it down thus potentially increasing the number of increments. I see you are using the ‘custom’ option to get the increment schedule you want rather than the default of daily.. Would you see any good reason to add other repeat intervals to avoid using the ‘custom’ option? I had avoided doing this as I wanted to keep the GUI simple and daily seemed what the vast majority of users would want. I then and added the ‘custom’ option to cater for special needs (and it helps me with testing). The check will not reset to 0 as the plugin does not start the parity check itself, but merely pauses and resumes one started by the system. I am not sure what the behaviour will be if both pause and start time are identical as it will depend on exactly the order the pause and resume get executed as to whether a check is left running or paused. I think I will add a check to the GUI that the Pause and Resume times are not identical as it could mean that behaviour is unpredictable, and I cannot think offhand of a Use Case where it makes sense (but you are welcome to suggest one). I am not sure I tested this but it should be treated as a manual check because it was not initiated by a cron entry. I will add a check for that to my test checklist though to make sure it is. For reference Automatic checks are the sort that are started automatically by the system after an unclean shutdown is detected and if any other type of check gets flagged as Automatic this is a bug in the plugin that would need investigating and correcting.