[[Support] binhex - SABnzbdVPN]

On 2/27/2021 at 1:52 AM, SubRetro said:

So I was able to resolve my issue after a bit of testing.

 

1. I tried the ignore proxy option work around. Didn't work.

2. I tried removing the docker and its imagine and pull back down comparing the config I had. Didn't work.

3. I tried updating ovpn conf file and didnt' work.

 

What I did find that worked was I shut off the docker, removed the ovpn conf file and started the docker up so I can clearly get the expected log message - 

"[crit] No OpenVPN config file located in /config/openvpn/ (ovpn extension), please download from your VPN provider and then restart this container, exiting... "

 

Then based upon the following error message I was getting.

 

2021-02-27 02:05:55,578 DEBG 'start-script' stdout output:
[info] Starting OpenVPN (non daemonised)...

2021-02-27 02:05:55,583 DEBG 'start-script' stdout output:
Options error: Maximum number of 'remote' options (64) exceeded

Use --help for more information.

 

I noticed in my ovpn conf file that there was several entries such as.

*****EXAMPLE******

remote.vpnpiatunnel.com TCP 1111

remote.vpnpiatunnel.com TCP 1111

remote.vpnpiatunnel.com TCP 1111

remote.vpnpiatunnel.com UDP 1234

remote.vpnpiatunnel.com TCP 1111

 

So I removed the duplicate entries for the TCP line items and kept the UDP. Ultimately resulting in this.

 

remote.vpnpiatunnel.com TCP 1111

remote.vpnpiatunnel.com UDP 1234

 

I saved and copied the file over to the proper directory for the docker and started it back up. Now I get expected behavior in the logs and get the end results once the VPN communication gets established. 

 

 SABnzbd process is listening on port 8080

 

Now I am able to get into the WebUI and my reinstalled docker already had all of its config settings in tack as well. I ran verification tests to my nzb providers and made sure my other dockers such as sonarr/raddar were able to verify test connectivity to sabnzbd and to go through the download request process.

 

As of result of all this I have no idea why my conf file had multiple entries. If it was there before and whatever change/requirement was made in this docker update that occurred must of tightened up some requirements and saw that this was an issue in the conf file. Not a deal breaker but when you start to understand the order of behavior with this docker and your setup it certainly helps to walk through the process to better troubleshoot.

 

Thanks for taking the time to read this and hope this might help someone down the line. Thanks.

 

 

 

This solved my issue. Thank you!

[Functional Multi-Controller USB PCI-e Adapter]

On 3/7/2018 at 8:52 PM, Starlord said:

I can 100% confirm that this card does not support AMD's x399 chipset due to lack of thunderbolt support. No intel systems to test it on. I just returned it and picked up the PEXUSB3S44V to test and so far haven't even been able to get unraid to boot when devices are plugged into it. Very interested in this thread.

 

First post here on the forums, but with my long USB battle I wanted to post up my results.

I can 100% confirm that the Sonnet Allegro Pro card is the only one I have gotten to work on my X399/1920X build. I fumbled with the PEXUS Startech units and could pass them through to my VMs, but the drivers would either crash or the controller would fail to start correctly. They also had issues powering multiple HIDs when a hub was used.

I now have a dedicated controller passed to each of my three LAN gaming VMs with the Sonnet card. Each USB port has a hub plugged into the end to allow players to have their HIDs and their headsets connected. Audio is perfect and hot swap sure is nice to have now. Especially since a lot of the HIDs were of the same make/model and webGUI USB passthrough was very buggy for me.