Squid

The results *should* have been in that window (I'm assuming, only ever ran the checks via the command line). --rebuild-tree though can take quite awhile to run (hours), and are not part of a diagnostics

Hehe

https://forums.unraid.net/topic/57181-real-docker-faq/#comment-564345

IIRC, I've had to do that for years.

Custom Tab plugin.

You would have "mapped" the host path of /mnt/ to some container path (since it's binhex, probably /media). So after its all up and running you navigate to the root, then media, then you'll see all the individual drives, and user. user is the unRaid shares.

And just to rule it out, have you tried a different cable / port on the switch or mobo. Bad ethernet ports / cables *can* under certain circumstances take down an entire network

Can you do this? https://medium.com/redbubble/running-a-docker-container-as-a-non-root-user-7d2e00f8ee15

No, thank YOU. Not quite sure why sonarr wouldn't be working. The plugin is one that I do test every month or so, and have never had an issue with everything working as if nothing happened...

Look in your motherboard manual on the update procedure Sent from my NSA monitored device

Maybe you also need a BIOS update. Yours is Nov, 2018 and I would think that on a Ryzen board there have been later updates

Unless I'm missing something, for whatever reason the containers were in a "new" state so you ran a backup. If you don't have any previous backup sets saved, then you just backed up the "new" state. You would need to restore one of the prior backup sets.

I would try reseating the cabling to the drives & HBA

Have you disabled C States in the BIOS?

They weren't lost. Just that they never moved from temp. I simply moved them manually and restarted the container and everything worked fine after that Sent from my NSA monitored device

Minor issue If you change the number of workers (lower them) after transcoding has begun, the system will still continue on its merry way (and reflect the new number of workers after the current job is finished), but will no longer move the files back to their final resting place but leave them in the temp directory

You've got to run the https://wiki.unraid.net/Check_Disk_Filesystems on the cache drive

I replied in your sonar thresd Sent from my NSA monitored device

Post the diagnostics Sent from my NSA monitored device

Odds on you're winding up downloading into the image itself. Hitting Container Size on the docker page will show (under the writeable column)

Presumably you're looking to place the .opvn within /boot/openvpn on the flash drive. Kinda a misnomer as /boot is the flash drive

Because the errors were being corrected Reason why you have ECC memory is so that the system will catch those errors and alert you so that you can replace the memory sticks.

You should be going to port 8787 based on the docker run command you posted https://forums.unraid.net/topic/57181-real-docker-faq/#comment-564345

Sep 29 08:17:21 unraid-green kernel: mce: [Hardware Error]: Machine check events logged Sep 29 08:17:21 unraid-green kernel: EDAC sbridge MC0: HANDLING MCE MEMORY ERROR Sep 29 08:17:21 unraid-green kernel: EDAC sbridge MC0: CPU 0: Machine Check Event: 0 Bank 7: 8c00004000010092 Sep 29 08:17:21 unraid-green kernel: EDAC sbridge MC0: TSC 2c0d42b11d812 Sep 29 08:17:21 unraid-green kernel: EDAC sbridge MC0: ADDR 103a25a900 Sep 29 08:17:21 unraid-green kernel: EDAC sbridge MC0: MISC 440403486 Sep 29 08:17:21 unraid-green kernel: EDAC sbridge MC0: PROCESSOR 0:306e4 TIME 1569770241 SOCKET 0 APIC 0 Sep 29 08:17:21 unraid-green kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#0_DIMM#1 (channel:0 slot:1 page:0x103a25a offset:0x900 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0092 socket:0 ha:0 channel_mask:1 rank:5) Bad RAM

Always appreciated