Jorgen

I think you need to add the wireguard tunnel IP range to the Lan Network variable in the Sab VPN docker. Just add it after your normal home LAN range, separated by a comma. Edit: if you’re using the defaults for wireguard, the IP range to add to Sab is 10.253.0.0/24

This is a long-standing problem that no one has been able to find the root cause of. The common workaround is to use User Scripts to restart the container on a schedule every night. There should be details on how to do this somewhere in this thread. Sent from my iPhone using Tapatalk

Sorry I won’t be able to help, my unRAID server is in storage for a month due to house renovations so I would just be guessing at things to try. Did you already try just copying the wg config file from appdata on one of the Binhex VPN dockers? Sent from my iPhone using Tapatalk

Hmm that doesn’t seem right. PIA themselves have published scripts to use with wireguard outside their app: https://www.privateinternetaccess.com/helpdesk/kb/articles/manual-connection-and-port-forwarding-scripts Sent from my iPhone using Tapatalk

I don’t have a solution for you, but many of us are using wireguard and PIA in binhex’s excellent VPN enabled containers. Maybe you could look into the script he’s using to get the required settings? Or even set up a container and copy the wg config file? Sent from my iPhone using Tapatalk

It’s static. Can’t remember what the default one is, but you can change it to whichever supported endpoint you wish and it should persist from that point. Sent from my iPhone using Tapatalk

That’s how it works when binding the network. Sent from my iPhone using Tapatalk

From a few posts up. But you’re probably better off in the long run to try to get sonarr v3 working with the seed box. Sent from my iPhone using Tapatalk

[mention]strykn [/mention] [mention]nowhere99 [/mention] did you see the pinned post at the top of this thread and followed the instructions? Edit: Sorry! The post is pinned to the delugeVPN thread, see here: https://forums.unraid.net/topic/44109-support-binhex-delugevpn/?do=findComment&comment=951973

Yes, using tar from the command line. Here’s an example: https://www.linux.org/threads/list-tar-contents-only-first-level-then-subdirectory-extract.10491/ Sent from my iPhone using Tapatalk

Sounds like your routing Sonarr et al through the DelugeVPN container network? In that case, you should NOT use the proxy settings in Sonarr. It's one or the other, not both. You should also add the SABnzbd ports to VPN_OUTPUT_PORTS environment variable. Because Sonarr running INSIDE the DelugeVPN container network, needs to be allowed to talk OUT to the SAB ports running outside the DelugeVPN network. This is explained in Q27 here https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md Of course, if you are not routing the apps through the DelugeVPN network this is not applicable.

Sonarr is supposed to remove the torrent from Deluge after it reaches the defined ratio, but I never got that to work either. AutoRemovePlus plugin is the way to go in my opinion. The most likely reason the egg isn't accepted for you is that the Python version in this container was recently updated to 3.9. If you have the 3.8 egg in the plugin folder already, simple rename it to 3.9 (see below) and restart the container: AutoRemovePlus-2.0.0-py3.9.egg If you don't have it, download the 3.8 version from here: https://forum.deluge-torrent.org/viewtopic.php?f=9&t=55733 Put the egg into the plugin folder, rename it to 3.9 and restart container.

Thanks, hardcoding "/watch" made it work again, of course. Just for my understanding though, am I misinterpreting the table on the hooks page? I'm using post_watch_folder_processing.sh

Hi Djoss, I've been running this container for a looooong time without any problems, using the automatic watch folder workflow and a post_watch_folder_processing script to stop the container after processing if the watch folder is empty. Sometime during the last few months (maybe longer) the script has stopped working as intended, with this in the log: [autovideoconverter] Conversion ended successfully. [autovideoconverter] Removed /watch/moviename.mkv'. [autovideoconverter] Watch folder '/watch' processing terminated. [autovideoconverter] Executing post watch folder processing hook... post-watch folder processing: Watch folder = /watch/BDMV watch folder not empty, won't shut down [autovideoconverter] Post watch folder processing hook exited with 0 [autovideoconverter] Change detected in watch folder '/watch'. [autovideoconverter] Processing watch folder '/watch'... [autovideoconverter] Watch folder '/watch' processing terminated. Here's the script: #!/bin/sh # # This is an example of a post watch folder processing hook. This script is # always invoked with /bin/sh (shebang ignored). # # The argument of the script is the path to the watch folder. # WATCH_FOLDER=$1 echo "post-watch folder processing: Watch folder = $WATCH_FOLDER" if [ -d "/$WATCH_FOLDER" ] && [ -z "$(ls -A "$WATCH_FOLDER")" ] then echo "watch folder empty, shutting down" killall -sigterm ghb else echo "watch folder not empty, won't shut down" fi I don't understand where /watch/BDMV is coming from? Are you able to shed some light on this for me, please? Has the argument value changed recently? Is Handbrake adding a temporary BDMV folder during processing? Or have I added another watch folder somehow without realising? In the container settings, the watch folder is set to /mnt/user/Media/Handbrake_hotfolder/watch/ Thanks in advance Jorgen Edit: I only have one watch folder defined in the container settings, and no optical drives passed through. Full run command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker create --name='HandBrake' --net='bridge' -e TZ="Australia/Sydney" -e HOST_OS="Unraid" -e 'AUTOMATED_CONVERSION_PRESET'='My Presets/Mathias_MKV_720p30_v2' -e 'AUTOMATED_CONVERSION_FORMAT'='mkv' -e 'AUTOMATED_CONVERSION_KEEP_SOURCE'='0' -e 'AUTOMATED_CONVERSION_OUTPUT_SUBDIR'='' -e 'AUTOMATED_CONVERSION_OUTPUT_DIR'='/output' -e 'AUTOMATED_CONVERSION_NON_VIDEO_FILE_ACTION'='ignore' -e 'DISPLAY_WIDTH'='1280' -e 'DISPLAY_HEIGHT'='768' -e 'USER_ID'='99' -e 'GROUP_ID'='100' -e 'APP_NICENESS'='15' -e 'UMASK'='000' -e 'X11VNC_EXTRA_OPTS'='' -e 'AUTOMATED_CONVERSION_SOURCE_STABLE_TIME'='5' -e 'AUTOMATED_CONVERSION_SOURCE_MIN_DURATION'='10' -e 'SECURE_CONNECTION'='0' -e 'AUTOMATED_CONVERSION_CHECK_INTERVAL'='5' -e 'AUTOMATED_CONVERSION_MAX_WATCH_FOLDERS'='5' -e 'AUTOMATED_CONVERSION_NO_GUI_PROGRESS'='0' -e 'AUTOMATED_CONVERSION_NON_VIDEO_FILE_EXTENSIONS'='jpg jpeg bmp png gif txt nfo' -e 'AUTOMATED_CONVERSION_HANDBRAKE_CUSTOM_ARGS'='' -e 'AUTOMATED_CONVERSION_INSTALL_PKGS'='' -e 'AUTOMATED_CONVERSION_VIDEO_FILE_EXTENSIONS'='' -e 'AUTOMATED_CONVERSION_OVERWRITE_OUTPUT'='0' -p '7803:5800/tcp' -p '7903:5900/tcp' -v '/mnt/user/Media':'/storage':'ro' -v '/mnt/user0/Media/Handbrake_hotfolder/output/':'/output':'rw' -v '/mnt/user/Media/Handbrake_hotfolder/watch/':'/watch':'rw' -v '/mnt/cache/appdata/HandBrake':'/config':'rw' --device='/dev/dri' --cap-add=SYS_NICE --log-opt max-size=50m --log-opt max-file=1 'jlesage/handbrake'

ok, there was a bug in the container updates yesterday in regards to wireguard. Try forcing an update now and see if it fixes it, binhex pushed a fix a few hours ago.

In Jackett proxy config you should use the 172.17.x.x IP of the DelugeVPN container. I think this also assumes that both Jackett and DelugeVPN containers are using the same docker network, which is bridge by default:

No terminal command required, it's shown on the docker page in unraid: One thing to keep in mind if you go down this route (pun intended) is that the docker IP is dynamcially assigned and could change on restart of containers or the unraid server. If things always start in the same order it probably won't, but just be aware of it if things suddenly stops working again.

Ah, interesting. Could you share a screenshot of the Jacket proxy settings? Is that a 172.x.x.x IP?

Sorry mate, I re-read you initial post and I think I misunderstood your setup. I thought you were binding the *arr apps to the delugeVPN network, but you are actually just using the proxy, right? In that case I pointed you in the wrong direction and can't really help as I don't know how NzbGetVPN works.

Well, it does work for Sonarr and Radarr, I think Binhex assumed Jackett would work the same, but it's obviously a special case from all the posts here. I don't know what to do about it either, apart from moving Jackett into the VPN network, maybe Binhex can weigh in at some point to clarify if there are other options. Edit: wgstarks has the solution, see posts below

That looks exactly like my setup which works. The only thing I can think of is there might be invisible characters or spaces in the Extra Parameters. Remove the orphaned image, reinstall Jackett from previous apps in CA and edit the Extra Parameters field by typing in the "--net..." line manually instead of copy/paste. After it's downloaded and unpacked, copy the full run command and paste it here if the container still fails to start. Which version of unraid are you on?

Looking back at other posts about Jackett and proxy, I think the easiest would be to not use it via proxy and instead bind it's network to the DelugeVPN container. See Q24 here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md It will have its own quirks to work through though, read the other FAQ entries around network binding. Sent from my iPhone using Tapatalk

Yeah that looks like a successful start and all settings seems to be ok. Are you sure the LAN_NETWORK range is correct? If it is, maybe it's a problem on the web browser end, try disabling ad blockers, clear the cache and/or try accessing deluge from a private window or different browser?

There's a fix coming for this, see https://github.com/binhex/arch-delugevpn/issues/258 Although, if you want to run NzbGet through a VPN tunnel, an alternative is to use the normal binhex NzbGet container and bind it's network to the DelugeVPN container. See Q24 here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Yes, you need to get Jackett working first. I don't use jacket via Proxy, so I'm just guessing here, but could you try using the IP of unraid, instead of "tower" for Proxy URL?