SeeGee

I have personally verified that both the Asus Hyper M.2 X16 (V2) and (Gen4) cards work on a Supermicro X10DRU-i Motherboard. Just be aware that the Gen 4 version is 2.6 cm taller, and thus wouldn't fit in my chassis using the slot I wanted.

In the README.md file on Github, it says: "If there are multiple ovpn files then please delete the ones you don't want to use (normally filename follows location of the endpoint) leaving just a single ovpn file and the certificates referenced in the ovpn file (certificates will normally have a crt and/or pem extension)." What happens if there are multiple config files? Will it choose at random/round Robin? I use your qbittorrentvpn container, and I somehow recall a mention in this container that it would choose one randomly. The reason why I ask, is that I would like to randomize the servers I connect to.

Binhex just answered this a couple of posts up: see Q2 for how to confirm the vpn tunnel is working:- https://github.com/binhex/documentation/blob/master/docker/faq/delugevpn.md

I am experiencing a similar error using a different VPN Provider... When I start the container, I get this warning, but when i checked the credentials conf, perms are set to 600. Obviously doesn't affect functionality, but I'd rather have it happy. 2020-02-19 16:08:52,946 DEBG 'start-script' stdout output: Wed Feb 19 16:08:52 2020 WARNING: file 'credentials.conf' is group or others accessible And I also get the AEAD Decrypt error: cipher final failed, but not right away... it only seems to happen after the container has been running for a few hours. It shows up sporadically. I'm pretty certain that the connection is successful, because the logs say: [info] Successfully retrieved external IP address xxx.yyy.zzz.111 which is NOT my actual external IP To verify the VPN was working, I dumped that IP into a geo-location lookup, and it returned a location far, far, from home. One non-standard change I made within the qbittorrent Web UI: I changed the Network Interface under Advanced Settings from default (i think that was eth0) to tun0 under the impression that this guarantees a killswitch of sorts... Zero traffic allowed without the VPN being active. Correct?

I'm running an older SandyBridge i7-2600, and I am unable to get Quick Sync enabled. I have verified that it is in fact ENABLED in the bios. My motherboard is an odd one (MSI-P67A-GD65) that has no onboard HDMI ports of any kind (Even though every cpu it supports appears to have an iGPU on it) but the bios explicitly has an option to enable/disable Quick Sync. This lack of HDMI port makes it impossible to try the dummy-dongle trick. When i run modprobe i915, it executes without any output, the module loads, but I get no /dev/dri. Is there a way to force this? I know my cpu is old, and it's quicksync support is crappy, but it's one of those things... If you can configure the software to use it, why not? (unRAID 6.8.2)

While I was looking into this, I saw several mentions that this does work with firefox, but I do not use firefox primarily, so I am unable to help you. This is one place that made this claim:

Getting Chrome to send magnet links to qBittorrent WebUI: I was in the middle of posting a question, when I answered my own question... I thought I should share: [qbittorrent v4.2] In the qBittorrent WebUI, under the Tools section, there is the option to "Register to handle Magnet Links...". At first, this did NOT work properly. It would create a handler in Chrome on the client without issue, but that handler would not work, and constantly returned a 404:Not Found error every time I clicked a magnet link on said client. My first thought seeing a 404 error is that the handler was not using the 8080 port properly (when viewing the handler in Chrome settings, it did not reflect the Port, just the IP/URL of the server.) so I assumed that the 404 error was caused by Chrome attempting to connect to the unraid server on the wrong port, not getting a response, and thus, spits out a 404 error. Made sense to me. I spent a lot of time trying to manipulate the settings in Chrome to rectify this problem... I discovered that it was actually an authentication issue. Adding the handler from the WebUI actually does include the port used by the WebUI, it's just that Chrome does not reflect that when viewing the handler settings... What I needed to do was to add the IP of my client PC to the Whitelist in qBittorrent! It can be found under Options > Web UI > Authentication > (Enable)Bypass authentication for clients in whitelisted IP subnets. If you only want to add specific clients access to the webui, simply specify the IP or hostname of those pcs. If you want to allow all pcs on an entire subnet, enter 192.168.1.0/24 Do remember that enabling this option bypasses any authentication for those IPs you specify, so anyone using that IP will have god access to your qBittorrent WebUI.

This is exactly what I needed to know. Thank you!

Your Xeon will be fine. I'm embarrassed to say what I'm running on. Lol