Jorgen

[mention]jwoolen [/mention] sorry don’t know what might be wrong in that case. Hopefully someone with better networking knowledge than me can chip in. Sent from my iPhone using Tapatalk

I assume the screenshots are from a browser on your local PC and you have configured the browser to use Privoxy as the proxy server? In that case the browser routes http traffic via the proxy server and VPN tunnel. However, the browser will use the OS mechanism for DNS resolution (DNS is different to http). Since your OS doesn't use the privoxy proxy it will fail the DNS leak test. The DNS servers you set in the container setting has no effect on the browser behaviour in this case. I believe they are only used by the container before the VPN tunnel is established, but maybe @binhex can confirm this? When you are using the PIA app on teh other hand, all internet traffic is routed via the VPN tunnel on an OS level, including DNS resolution. So DNS passes the leak test. So how do you get the results you want? Two options that I know of that should work (but see note below): 1. If your browser supports it, set DNS resolution to use http protocol. In Firefox this is called "Enable DNS over HTTPS" under the proxy configuration settings. I assume other browsers have something similar. 2. Enable SOCKS v5 proxy in Privoxy and set up your browser to use that. See here for details on how that works: https://stackoverflow.com/questions/33099569/how-does-sock-5-proxy-ing-of-dns-work-in-browsers Now, I just tested both methods and could not get the browser to pass the DNS leak test for either. Not sure what I'm doing wrong but I'm not that worried about it as I use the PIA app on my PC anyway. But maybe this will point you in the right direction. Please report back if you try it and get it to work for you. Actually, you might also be able to set up your OS to use Privoxy as the proxy, but I have not tested that at all. Edit: looks like I need to use FoxyProxy extension for Firefox to be able to pass the username/password when using Socks. Hopefully other browser have better support for Socks...

So is the VPN still up when the download drops to 0? I guess it must be if you can access the deluge web UI. You have tried other endpoints? Debug logs might reveal something, but I agree that this seems to be a problem outside the container, especially since the other container has the same problem. Sent from my iPhone using Tapatalk

Maybe try the WireGuard option instead of OpenVPN? It’s working very well for me, none of these cipher problems. Although your problem seems unrelated if it actually connects successfully at first. Are your trackers blocking you? Have you run out of space on any disks that deluge are using? Sent from my iPhone using Tapatalk

Did you add the VNC port to the Privoxy container? Sent from my iPhone using Tapatalk

PIA offers three connection options: 1. legacy servers via OpenVPN 2. next-gen servers via OpenVPN 3. next-gen servers via WireGuard Only 1 and 2 are currently supported by this container. And 2 is the recommended option. Support for 3 is being worked on. Sent from my iPhone using Tapatalk

WireGuard is not (yet) supported by the container. Use the next-gen open VPN files instead. Sent from my iPhone using Tapatalk

Looking very good here. Successfully acquired a port within 21 seconds of starting the new container. As far as I can see it only took one try, no re-tries. But then again I don't have debug logs on so not sure if there-tries would show?

Very happy with the next-gen testing. Had to throttle the download bandwidth in deluge because downloading an Ubuntu ISO maxed out my internet connection!

I was getting the same, but left it for a few minutes and it came good on it's own. Getting great speeds finally from an endpoint on my own continent (au-sydney)! @binhex do you need anything specific from us guinea pigs?

Port forwarding does not work with any nextgen servers. PIA does not support it (yet?) You have to use one of the supported “current gen” servers and from there it’s hit-and-miss whether you get a port or not. Changing the server endpoints and/or restarting the container normally gets it going after a while. FWIW I just connected (also from AU) to DE Berlin with a working port forward and good speeds. Sent from my iPhone using Tapatalk

Hmm, I don't actually read/write to the shares much from my Mac (Catalina), especially big files. But I just did a test and the speeds aren't as fast as I expected for me either. I'm getting 10-20MB/s write, and a bit less on reads (single large file). There are some SMB config tweaks floating around on the forum specifically for Mac transfer speeds, I will look into to this to see if it makes a difference and report back. In the mean time, have you enabled "Enhanced macOS interoperability" under Settings/SMB Settings in unraid? If not, do that and see if it helps (probably requires restart of array at least).

I haven’t looked at your diagnostics yet, but I think you need to give us a bit more info about the scenario. - What version of Mac OS are you using? - How are you connecting to the unRAID server? WiFi or ethernet? Are you sure your network is ok? - Have you tested if you are getting the same or better speeds from a different computer/OS? - How are you mounting the share on the Mac? I assume via SMB? - What exactly are you doing when you see those speeds? E.g. copying one 10GB file from your Mac to the unRAID share, or copying lots of small file from unRAID to the Mac? Sent from my iPhone using Tapatalk

Are you using iCloud to sync photos from your phone? In that case you can do what I do. I have Mac VM on unRAID that runs for a few hours per week (scheduled start and stops). On the VM I run Photos that syncs with iCloud. The storage is a disk image on the unRAID array. So any new photos/videos on my iPhone are immediately synced to iCloud, then synced to unRAID once a week. I also run TimeMachine to a separate unRAID disk, which is probably overkill. But I’ve lost irreplaceable photos in the past from phones dying and really don’t want it happening again. In the unlikely scenario that my phone dies AND apple somehow loses all my iCloud storage at the same time, I’m now only losing maximum one week of recent photos. Which I’m ok with. Sent from my iPhone using Tapatalk

Probably the simplest solution is to use binhex privoxy docker to create the VPN tunnel and then configure Jackett to use it as a proxy. Sent from my iPhone using Tapatalk

I had problems with rarbg when using binhex-privoxy as proxy for sonarr. Maybe worth a try to disable the proxy for a test, if you are using one? Sent from my iPhone using Tapatalk

No, you can change CPU assignments, but the XML contains other custom bits that gets wiped out when changing CPUs via the unRAID GUI. So you have two options: 1. Edit the CPU assignment directly in the xml (swap to advanced view in unRAID) Or 2. Make a copy of the original xml, then edit CPU assignment in the GUI, save, switch to XML view and paste in all the bits that got removed from the original xml (from memory it’s the ovmf path and the block of custom arguments at the end of the xml) Either way you need to understand a bit about the xml structure, and it helps using a text editor that lets you compare two text files. Sent from my iPhone using Tapatalk

I think the commonly accepted workaround is to restart the docker once a day. Using CA User Scripts to automate it. No one has ever been able to pinpoint the root cause, and it doesn’t affect everyone. Sent from my iPhone using Tapatalk

See Q4 here: https://github.com/binhex/documentation/blob/master/docker/faq/delugevpn.md Sent from my iPhone using Tapatalk

I think the Controller Hostname/IP setting should be set to the custom:br0 IP of the docker container. It should be the IP that the other devices need to use to connect to the controller. But I’m not sure you need to set that at all when using a custom network. Sent from my iPhone using Tapatalk

See Q4 here: https://github.com/binhex/documentation/blob/master/docker/faq/delugevpn.md Alternatively you can enable the plugin then stop/start the backend server from within the deluge UI. I forget where to find it exactly, it’s in the deluge menu somewhere. Sent from my iPhone using Tapatalk

You would have to change the application port from the Radarr UI under settings/general: Then map the host port to the new application port, but you need to do that on the VPN container when you are using it’s network (not the Radarr container). I don't believe the container port mapping is actually used at all when using the network from another container. Here's an example to illustrate. If you are using two Radarr containers, you need to add two custom port mappings to the VPN container.

The preset you select in the GUI is only used for the file you manually load and process via the GUI. The docker setting controls which preset is used by the automated watch folder. The two are very separate and setting one does not influence the other.

You couldn’t have, smb support was introduced in 11.12. You probably used AFP to backup to a network share? That works for all Mac OS versions, but is deprecated and shouldn’t be used. Sounds like the best way for you to get this working is to update to High Sierra. I understand you probably want the backups working before upgrading so I’m not sure what to suggest. Maybe set up time machine to an external HDD temporarily? Sent from my iPhone using Tapatalk

I don’t know if this is actually how it works, but it’s how I think about it. And I have no problems running this docker on bridge mode. When running UniFi in a docker in bridge mode, the docker IP is something on the bridge network, e.g. 172.x.x.x. I think the unifi app detects it’s own IP and broadcasts it out to all APs that are listening. This is how auto-adopt works. But of course, the AP can’t talk back to unifi on 172.x.x.x. It needs to use the unRAID host IP. The controller override settings in unifi neatly fixes this problem by broadcasting an IP that the AP’s can actually reach. So in summary, bridge mode works well but you HAVE TO set the controller override options correctly. Again, this is how I think about it, I don’t know for sure that it’s how it works behind the scenes. Sent from my iPhone using Tapatalk