Phoenix Down

It just started working by itself recently. No changes on my part.

Nope. Had to stick with Yahoo Mail for this.

If we move to using the plug-in, we should remove any existing RAM-disk code from "/boot/config/go", right?

I just checked, and I misspoke. It has been so long that I forgot what I did. I actually have it set up as bash script that is executed daily via User Script. I seem to recall my modifications kept getting wiped out. Probably from every time Autofan updates. It's possibly less of an issue now, since the last Autofan update was in February 2023. Here is the script. You will need to substitute the path to your own modified autofan script. Once the modified script is copied over, you need to kill then restart autofan for each of your fans, so the updated version can take effect. You can find the exact commands in the system log when Autofan starts. Don't just copy mine, since the argument values are specific to your system. #!/bin/bash echo Copying modified script from '/mnt/user/Data/Scripts/autofan' to '/usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan' cp /mnt/user/Data/Scripts/autofan /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan echo Done. echo echo Starting Autofan... echo /bin/bash /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan -c /sys/devices/platform/it87.2624/hwmon/hwmon5/pwm3 -f /sys/devices/platform/it87.2624/hwmon/hwmon5/fan3_input -q echo echo Waiting 5 seconds before restarting... sleep 5 echo /bin/bash /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan -c /sys/devices/platform/it87.2624/hwmon/hwmon5/pwm3 -f /sys/devices/platform/it87.2624/hwmon/hwmon5/fan3_input -l 25 -t 35 -T 55 -m 5 /bin/bash /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan -c /sys/devices/platform/it87.2624/hwmon/hwmon5/pwm4 -f /sys/devices/platform/it87.2624/hwmon/hwmon5/fan4_input -q echo echo Waiting 5 seconds before restarting... sleep 5 echo /bin/bash /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan -c /sys/devices/platform/it87.2624/hwmon/hwmon5/pwm4 -f /sys/devices/platform/it87.2624/hwmon/hwmon5/fan4_input -l 25 -t 35 -T 55 -m 5

I know it's super late, but I just saw this. Not sure how I missed it the first time. Hopefully my fix worked for you.

I reported this issue 2 years ago, along with the fix. Sad to see it's still an issue. But I understand that developers are volunteering their own time, and they have their own lives, which should always takes priority. In any case, take a look at my post and the associated fix. I have a local fix in place, and set it up so the local fix is applied at Unraid startup (place in the go file):

Running into the same issue with Proton Mail. Anyone with any resolution?

Not sure; I did not run into this issues for any of my 8 disks. Maybe there's a hint in this thread:

Just trying to eliminate variables, see if it’s an issue with your large disk or something else.

What happens if you tried a different disk first?

Have you encrypted any other disks in your system? Were they successful?

Check the system logs (top right, left of the solid circle with a question mark). That sounds like the format was unsuccessful for some reason.

See my reply above: Did you start the array back up after you changed the disk type to "XFS Encrypted"?

Check to make sure you copy and pasted the correct checksums into the RAM disk script. Maybe you missed a digit at the end.

If your Unraid version is different than @Mainfrezzer's code example, then it's possible those files are also different. So yes, you should update the RAM DIsk code with your own checksums. Note that doing this doesn't mean the RAM Disk code won't have any issues, just that the code won't abort itself. It might or might not have any issues, but we don't know until someone tries it out whenever a few version of Unraid comes out.