strike

This message is not coming from delugevpn I don't think. What are you using to manage your containers? If you disable the vpn, can you get to the webui? What network type do you use and what is the IP of the computer you're trying to access deluge webui? Edit: This here from your log is an issue tho, the vpn is not going to work correctly if iptables is not working. Have you checked your permissions? delugevpn | modprobe: FATAL: Module ip6_tables not found in directory /lib/modules/6.18.9 delugevpn | ip6tables v1.8.11 (legacy): can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?) delugevpn | Perhaps ip6tables or your kernel needs to be upgraded.

Download a new .ovpn file from your vpn provider and try again.

I can't see any other errors in the log besides the TLS handshake error. This can usually be solved by downloading a new .ovpn file from your vpn provider. I tried to ping the most recent server you connected to in your log, and it confirmed it's down.

Need a full log, please do this: https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Try to disable "use tailscale dns" on your tailscale client on the phone. That should make it faster.

If you go to the template and toggle advanced view, do you have a specific tag set here: If you do, just set it to :latest instead of the tag and apply. You might have to check for updates again to get the latest version.

You don't need to set up proxy, the reason I asked is because if enabled it can cause connection issues if not set properly. Please post a new log, remember to redact user/pw

No, if you want it publicly accessible you have to use tailscale funnel.

But why are you messing with input/output ports then? That should only be used if the containers are behind the delugevpn container. Have you enabled host access to custom networks in settings-Docker? Do you have proxy enabled in sonarr/radarr? Please post a new log as well.

First, change your vpn password (and user if you can), as you forgot to redact them from the log. Second, set STRICT_PORT_FORWARD to no. And thrid, see Q17: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Last update to this image was 11 months ago, so no recent updates.. The reason why it doesn't work when VPN is enabled and works when it is disabled is because of the strict ip tables rules in place. If the VPN is enabled all settings like Lan network, input/output ports needs to be correct. If it's not it will not work. And like mentioned, in your log, it's was not correct. I'm telling you what needs to be set for it to work and you keep ignoring it. Or at least you haven't said you have set the correct Lan network, yet. One thing I remember now tho, you have this container on a fixed IP I think? That can sometimes work and sometimes it does not. Post your setting for deluge in sonarr/radarr.

I'll check your log after work to see if there's anything obvious. In the meantime check out the FAQ.

Aha, sorry then I misunderstood your first post. You still need to fix your Lan network tho. As mentioned all subnets that are going to access the webui must be defined in Lan networks, including the vlan subnet. And in the log from before it was not defined. Also make sure you don't use a proxy in the other containers. If it still doesn't work after doing that you should look at the faq. Theres a few things in there regarding using the VPN on other containers. I'm on my phone at work right now so I don't have the link.

Yeah, it looks better now.

That's exactly what I'm saying.. In your log from before, it says your LAN_NETWORK is defined as: 10.33.101.0/27 This is not correct if the computer your trying to access the webui from is x.x.12.0/27 Forget about sonarr,privoxy etc for now. First, fix deluge so you can get to the deluge webui. As I've said multiple times, ALL subnets you're accessing the web ui from need to be defined in LAN_NETWORK. So if the computer you're trying to get to the webui from is on x.x.12.0/27 you need to add that. Subnets are separated by commas. After doing this you still can't get to the deluge webui? What do you mean by this?

When VPN is enabled strict ip tables rules are in place and every subnet you are accessing the webui from needs to be defined in LAN_NETWORK in the container template. If it's not defined you'll be blocked. So if you're accessing the webui on a machine on the normal Lan or a different vlan it needs to be defined in the template. What is the Ip of the machine you're accessing the webui from?

I'm also running the official container, and one thing I noticed is that I have UID and GID as the variables, whereas you have APP_UID and APP_GID. Can you try changing it to UID and GID and try your test again to see if it creates the files with the proper owner?

Looks fairly standard. Then I don't know what is causing this. Maybe post in the support thread for emby to see if others can help.

Are you running some extra metadata plugin in emby or something? You need to figure out why the .nfo files are created with daemon daemon instead of nobody users. Which emby container are you running? Binhex? Official?

Do you have another app creating the .nfo files? It doesn't look like emby has created this one, as it's not nobody users. Since emby is set up with UID and GID for 99/100 (nobody users), any files emby creates should have nobody users. So maybe you have another app creating .nfo files? This look correct. Is this after pasting the settings in smb extras?

I don't know why you are renaming and moving manually when there are apps like sonarr/radarr, but anywho; Make sure the emby conatiner has UID and GID set to 99 (UID) and 100 (GID) in the template. Run docker safe permissions tool. Go to settings-SMB-SMB Extras and paste this in the box: domain master = yes preferred master = yes os level = 255 force user = nobody force group = users create mask = 0666 force create mode = 0666 directory mask = 0777 force directory mode = 0777Try again now, it should be fixed.

The vpn tunnel seems to be working, so the issue is most likely what you have defined as your LAN_NETWORK. I see you have only one subnet in there, but you mentioned that the container is running on a VLAN. You have to define both your normal LAN subnet and your VLAN subnet (and any other VLAN subnet your might be accessing the webui from), separated by a comma. If that doesn't work, you have to check your network/firewall settings.

Please do this: https://github.com/binhex/documentation/blob/master/docker/faq/help.md

I don't see any reason why you can't load the webui. I went back to your first post and saw this: "Changed the webGui port number away fro 8080 (default) - locked me out of the gui with the VPN on and off - its worse." I'm thinking maybe this could be the issue: you changing the port and changing it back. Can you change the port again to maybe 8085 or something, following the directions in Q4: https://github.com/binhex/documentation/blob/master/docker/faq/qbittorrentvpn.md

What I think you're referring to in his logs is actually normal. It's just the watchdog script checking if the connection is up/down, checking if the port has changed, and checking that DNS and iptables are working. You don't see it actually disconnect and reconnect in his log. So the vpn tunnel seems to be working fine, at least from what I can tell.