III_D

FWIW - downgraded binhex qbittorrentvpn to 4.3.9-2-01, and updated to unraid 6.11.5, and no crashes since.

I am no expert, and will leave it to others to look at your diags and comment on anything they find there. I know this has nothing to do with VM's, but your description of the crash behaviour sounds like what several users are reporting since upgrading to 6.11.x,. They have narrowed it down to a conflict within libtorrent libraries and the latest OS kernel, and this has helped me. If you are running a torrent docker this may apply to you. Have a look here, and especially to binhex's comments on page 6: https://forums.unraid.net/bug-reports/stable-releases/crashes-since-updating-to-v611x-r2153/?page=6&tab=comments When I turn off binhex qbittorrentvpn docker, the crashes stop. I have downgraded that docker and am watching to see if it makes a difference. III_D unraid 6.11.3 Repository: binhex/arch-qbittorrentvpn:4.3.9-2-01

FWIW - For a couple of days I have been starting binhex qbittorrentvpn docker and only leaving it on for a couple of hours, then turning it off. Since I have started doing this, I have not had an unraid crash. Before this, it would almost certainly crash <48h. Thanks to everyone for your attempts to solve this.

Others have way more knowledge than I can bring to this, but my experience with the recent behaviour: unraid 6.11.2 Intel 3770k unraid GUI becomes unresponsive except for header bar. Unsure how long after a reboot. Plex and -arr dockers seem to keep working, and accessible by clients and browser. binhex qbittorrent browser page is unresponsive. putty access maintained. powerdown -r doesn't work. Every other command-line attempt to shutdown or reboot fails. Eventually need to hard reboot. Here is the only thing I have to add that has not been mentioned in this thread, and I hope it helps give a clue to this: from command line, htop does not run at all. Hard rebooting again now... Thanks III_D

So, when I get the "This page isn't working right now", if I click the blue "REFRESH" button, it comes up right away. I guess it's not a bad work-around. Sonarr working now, I'm not sure why!

I noticed Mebrunner24 said he is having trouble connecting to the WebUI. I'm not sure if my problem is the same: If I use the Unraid webUI to open the qBittorrent page from the icon, it opens 192.xx.xx.xx:8080 but I get "This page isn't working right now". Ctrl-refresh does not fix it. Same behaviour in Chrome and Edge/Chrome. If I manually enter "http://192.xx.xx.xx:8080" it works. Also, not sure if this is connected, but I can't get Sonarr to connect to qBittorrrent. Radarr working fine with the same settings. This all started right after a recent update, where I lost my config from within qbittorrent. I don't see any errors in the log file. I tried deleting it and re-pulling it, same behaviour.

The default port in the settings is 6881, for both Host Port 1 and Host Port 2. My understanding is that this is a ubiquitous P2P port, and best avoided. With the delugeVPN docker, I believe it changed the port automatically. It doesn't look like it does it in this one. Where should I change the setting if I want to use a different port? in the Docker settings within qbittorrent, under Connection settings tab, change the incoming connections value (and/or check the box for use different port on startup) Thanks III_D

Thanks tjb! The fix for me was in this response, but I did not understand it at first, so I will clarify for others. Yes, using the SOCKS5 proxy feature within Jackett (and Sonarr, and Radarr...) DIRECTLY, ie. using the credentials for PIA within each of these dockers, was broken. It had previously caused persistent memory leaks, and more recently caused Jackett to stop working altogether due to SSL errors. The fix: within the excellent (thanks Binhex!) DelugeVPN there is a built-in Privoxy feature (ENABLE_PRIVOXY = yes). Enabling this, and then pointing each of the other dockers to use that http proxy, fixes both the SSL error and also the memory leaks. SpaceinvaderOne has a good Youtube video on how to set up Privoxy https://www.youtube.com/watch?v=2MNqonB86ec Thanks guys III_D

I'm getting the SSL error, and none of my trackers are working with Jackett. I have seen a few updates since this problem started, and none have fixed it. I couldn't get this above method to work. Deleting the proxy URL in the Jackett settings allows everyting to work, but obviously it would be better if this traffic went through a proxy... Maybe I'll try another Jackett docker.

This worked for me. Version 1.5b of installer. Kingston DataTraveler 16GB.

I have been running this Docker for a few years now. I recently reinstalled all of my Dockers using the templates. Everything worked except for this one. After pulling my hair out several times, I finally deleted the old appdata folder for binhex-delugevpn and reinstalled without the template (after screenshotting all of the old settings). Some of the settings categories have changed. Working fine now. p.s. I think Switzerland has dropped off the port-forward list. Czech is working.

How old is your power supply? I recently had a similar problem of unexplainable freezing/crashing, usually requiring hard-boots. Long story short, after trying many possible fixes without success, replacing the PSU solved the problem. Some good threads when looking to purchase a PSU: https://lime-technology.com/wiki/PSU https://lime-technology.com/forums/topic/11568-the-power-supply-thread/?tab=comments#comment-113993&searchlight=1 https://lime-technology.com/forums/topic/25307-power-supply-calculator/ Best of luck III_D

Re: DelugeVPN docker and PIA at server nl.privateinternetaccess.com FYI - I was getting a bunch of "Response code 000 from curl" errors, similar to JWMutant on page 87 of this thread. I checked my settings and OVPN files, and couldn't see anything wrong. I even replaced the PIA files. Still the same errors. Workaround: I switched to ro.privateinternetaccess.com, and switched the OVPN file to Romania. Working fine now. I think there's something going on with the PIA server in NL. I'll give it a couple of days and then try switching back to NL.

I think there were 2 mistakes made here: 1. the filesystem on a replacement drive was changed to something different than original, and 2. it was formatted. (I have lately been switching existing data drives from ReiserFS to XFS and so I have done this process several times now. When you stop the array, change the filesystem, and restart the array, there is no choice to rebuild data, it only gives an option to format "unmountable". After the format, the space on that drive is 100%.) Notice that nowhere on the replace drive process does it say to format: https://lime-technology.com/wiki/index.php/Replacing_a_Data_Drive If you assign a new (precleared or unformatted) drive into the old drive's slot and start the array, it should ask to rebuild data on the new drive. But if you have made mistake #1, I think the only option provided then is to format it. If you then make mistake #2 (inevitable), this is irreversible. This does seem like a good opportunity for a built-in warning. III_D

I was looking for a good case this week, and came across this on NCIX: http://www.ncix.com/detail/fractal-design-define-r5-atx-70-102216.htm?promoid=1918 The lowest price seen on CamelCamelCamel was CDN$102 (pic attached). The US page for those interested is US$69.99: http://www.ncixus.com/products/?sku=102216&vpn=FD-CA-DEF-R5-BK&manufacture=Fractal%20Design&promoid=1714 Might be a "Cyber Monday" deal, so it might not last long. Enjoy! III_D