itimpi

You have not mentioned whether you recreated the docker image and then the error had occurred again.

Have you checked where any vdisks for the VM are located? According to the diagnostics it looks like they may be on disk1 or disk4 as that is where the ‘domains’ share currently has content. You also have the mover direction for that share set to be hass->array - if you want mover to transfer files to that pool it needs to be the other way around.

You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

You can use the Parity Check Tuning plugin to only run the checks in increments during what is normally idle time. This minimises impact on normal use at the expense of the the total elapsed time being longer.

the current code that checks if it is inside a timeslot after mover finishes does not look at the custom settings but only at those set on the daily/weekly option. That was why I suggested you set the daily option to correspond to the timeslot in the custom option. Having done that you can re-instate the custom option so that you do not even start increments at the weekend. I think I have a solution for an alternative way of handling the timeslot checking which will also work when using custom scheduling, but I want to make sure it is well tested before I release it.

Why not simply follow the process that is documented here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page rather than relying on ChatGPT to get it right. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

You will need to contact support.

It appears the disk is not coming online properly as it is showing errors in the syslog and no SMART information.. It looks like what we normally except if there is a problem with the power or SATA cabling, but since you mention it happening at power on are you sure your power supply is up to the task of spinning up all drives simultaneously.

The 'syslog' file in the 'logs' folder is the one that is being mirrored to the flash.

There is no standard way to safely update packages as Unraid is meant to be treated as an 'appliance'. Installing a package that has not been validated by Limetech risks breaking the system so normally you need to wait for Limetech to release a new Unraid release that includes the patches. If you can find a self-contained version of the package with no dependencies that is compatible with the Slackware base underlying Unraid you can put it into the 'extras' folder on the flash drive and it then gets installed as part of the Unraid boot process, but you do this at your own risk. Having said all that you should not need to as the release notes for the 12.4 release contain openssh: version 9.3p2 (CVE-2023-38408) so that vulnerability should already be patched.

You could try this fix from the online documentation accessible via the Manual link at the bottom of the Unraid GUI. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom. If this helps, why it should be affected by the number of RAM sticks I have no idea.

Have you tried the suggested fix of removing the Mover Tuning plugin? For some reason this plugin seems to sometimes cause these symptoms.

Nothing has changed recently in the handling around crontab. The messages you display suggest that it is nothing to do with the increment pause/resume via crontab but instead to do with a pause being triggered by mover running and then the code that detects mover has completed deciding not to resume the check because it thinks it is outside the increment window. If you not on the latest release then you could get this symptom when NOT using the custom scheduling option but as far as I know this is no longer the case. The resume code that checks for current increment window is probably not working correctly when using the Custom option because I think it only looks at the increment start/stop times for the non-custom options. It could be quite complicated to get it working for all combinations of the custom option so could you try setting the start and end times in the daily option to be the same as those you have set in the custom option and then see if it works as expected when you revert to the Custom option? I may have to rethink how I am handling pause/resume around mover running so that using the Custom option does not break the resume.

do you have your Unraid server exposed directly to the internet for inbound connections without using a VPN or something similar? If so there is a good chance you have been hacked. If you post your system’s diagnostics zip file we might be able to determine how the miner is being loaded if that is what it is.

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

You will be getting a file in the ‘log’ folder on the flash drive because you have the mirror to flash option set. To get a file written to the ‘appdata’ share you need to put the IP address of your server in as the ‘remote server’ field as mentioned in the syslog server link.

All top level folders automatically become User Shares. You probably meant to put them into a folder corresponding to a User Share Name but got it wrong?

Confirms that the disk needs replacing.

No lost+found folder is always a good sign!

The signature will be recognised but there is no automatic format. The disk will show as unmountable and you will have the option to format unmountable disks. Check it is only the one you expect before proceeding with the format.

You need to be very careful of any method that uses move at the Linux level that you do not fall foul of the behaviour described in the Caution in this section of the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. Using a Copy/Delete strategy should always give the expected results.

The hardware Id’s for passed through hardware could have changed after the OS upgrade. Delete the config/vfio.cfg file off the flash dtive, and make sure no VM is set to autostart and then reboot. You then need to redo any hardware pass-throughs before starting the VM.

Sounds as if it should be enough. However too many drives on a single cable can sometimes cause intermittent problems, as can power splitters. You might also just have one where the power is not well seated.

Looking at the logs it appears that disk1 started getting errors just after resuming a paused parity check. Since at that point all spun down drives will simultaneously be spun up are you sure your power supply can handle spinning up all drives at the same time?

If multiple drives appear to go wrong at the same time then Unraid only disables the number of drives for which you have parity.