Squid

AMD Ryzen 7 1700 Eight-Core Processor Have you read https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/?tab=comments#comment-819173, in particular setting the Power Supply Idle Control to be typical? ASRockRack - X470D4U Other than that, I find it curious that you're running a Ryzen 7 1700 on a Motherboard which in it's specifications only lists that it's 2nd and 3rd gen compatible, and the 1700 is most definitely not on its supported CPU list. Doesn't necessarily mean anything, but I personally wouldn't have bought the combination...

Yeah, I'm not sure why I have it checking for that entry. I can only assume that I did that for a good reason, but I have no idea what the reason might be now that I looked at the code again... 🤔

What share are you transferring to?

Install the parity check tuning plugin, and schedule the check to run in multiple increments when there is nothing else going on (2 am for a couple of hours a day)

Are these ones you've installed without filling out a template? Try filling in the "Registry" entry when you edit the container.

God no. What docker safe new perms does is specifically exclude appdata from any changes to permissions / ownership. Docker containers may have their own unique and specific ownership / permission requirements, and messing around with them may impact your ability to run those applications (or have undesired side effects)

My first guess is that if you're running an ad blocker (or any other browser add on) to white list your server. Or, does it work if you use a different browser?

You're being bombed by messages from the video card. I'm assuming that you're passing through the card to one or more docker containers, but your nvidia plugin isn't up to date. Update it and re-select 6.8.3 (nvidia) from its drop down.

Something went wrong during the update. Remove it and reinstall from the link in the OP

Its explorer is read only. It saves the files elsewhere AFAIK if it doesnt then yeah you will have to rebuild parity

You would need to install tcl to get that script to work. Not sure if it's available in NerdPack or DevPack. Personally, I'd go with UFS Explorer, although it does cost $

Yeah, utilizing separate appdata sources adds a whole other layer of complexity to the GUI and underlying script, and when push comes to shove this is simply ~1000 lines of code acting as a front end to a single tar command. Multiple things are on the whiteboard for the plugin, namely individual storage of folders within the appdata, and multiple sources, but there is no ETA on that, and are considered to be part of the wish list.

The above. But, this plugin was designed for users who need to run a quick couple of commands on a schedule and also not have to worry about line ending formats. What people have leveraged this for exceeds it's design goal and specifications. If you know what you're doing, you will always have the most flexibility by directly running your own scripts and forgoing this plugin altogether.

Because it doesn't run from a shell. Rather its being executed from a PHP script via cron.

How did you log in to grab the diagnostics then? Looks like you did it via ssh... Does it make a difference if you try to access via the IP address? (192.168.1.25?) Try again in safe mode. If nothing else works, delete the SSH / SSL folders on the flash drive and reboot and try again.

That setting won't let you disable it.

Edit /config/share.cfg on the flash drive. Change the line similar to this shareMoverSchedule="50 23 * * *" to instead be shareMoverSchedule="#50 23 * * *" and then from a command prompt, update_cron But, it is possible that changes to the global share settings, and anything else on the Scheduler page may reset that value (same limitation as the plugin)

The command listed in the description is incorrect. SSD Trim trims all eligible devices

Gotta ask this. They stole the flash drive and left the server and associated equipment in place?

Can you post the entire syslog, or ideally the diagnostics zip file to put this all into context?

Your MCE's are actually memory issues Aug 5 07:42:21 Server16 kernel: EDAC sbridge MC0: HANDLING MCE MEMORY ERROR Aug 5 07:42:21 Server16 kernel: EDAC sbridge MC0: CPU 0: Machine Check Event: 0 Bank 5: cc12f00000010092 Aug 5 07:42:21 Server16 kernel: EDAC sbridge MC0: TSC 0 Aug 5 07:42:21 Server16 kernel: EDAC sbridge MC0: ADDR 85add2080 Aug 5 07:42:21 Server16 kernel: EDAC sbridge MC0: MISC 40404086 Aug 5 07:42:21 Server16 kernel: EDAC sbridge MC0: PROCESSOR 0:206d7 TIME 1596649337 SOCKET 0 APIC 0 Aug 5 07:42:21 Server16 kernel: EDAC MC0: 19392 CE memory read error on CPU_SrcID#0_Ha#0_Chan#2_DIMM#0 (channel:2 slot:0 page:0x85add2 offset:0x80 grain:32 syndrome:0x0 - OVERFLOW area:DRAM err_code:0001:0092 socket:0 ha:0 channel_mask:4 rank:0) Your system event log in the BIOS will hopefully pinpoint the actual stick, rather than Channel 2, dimm 0 The way most systems with ECC work AFAIK is that they will keep correcting the errors until they are unable to at which point the system will just completely stopped. Based on the number of corrections that are listed, one or more of the sticks are in very bad shape

You should post your diagnostics or verify that the settings for the appdata share allows it to write to a drive that has space on it. You're attempting to passthrough a GPU to the container, and it doesn't appear you did the entry correct

cat /var/local/emhttp/var.ini | grep mdResyncPos When it's zero its done

Did you DO NOT FORMAT THE DRIVE Also looks like you've got a bad / loose SATA connection within the system

More to the point is that the flash HAS to be formatted as FAT32 with a volume name of UNRAID. exFat will not work. And, while I can't remember 100% I seem to recall that Windows Defender might also interfere with the creation of the stick.