binhex

misconfigured LAN_NETWORK, from your log:- 2024-01-15 23:35:13.714631 [info] LAN_NETWORK defined as '192.168.0.1/24' See Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Are the other containers (sonarr etc) set with ip's in the defined LAN_NETWORK? as in 192.168.0.xxx? The other question is have you changed the ip you are using in the other containers (sonarr etc) to use <ip of your unraid server>:8118? The last thing to also check is that you are bypassing proxy for local addresses for the other containers (sonarr etc), screenshot:- this is from my server, change the ip to 192.168.0.* for your setup.

Unpack, yes, TLS is a nzbget issue and has a workaround in place.

See my previous post Sent from my 22021211RG using Tapatalk

nope, it has been this way for literally years!, i can only assume something in unraid has changed and this has resulted in an influx of users with this 'issue', have you recently upgraded unraid or switched from macvlan to ipvlan perhaps?.

This is your issue, you are specifying a static ip (192.168.0.111) for the container that is in the LAN range (192.168.0.0/24), this breaks the container, switch the docker container back to bridge.

If nothing has changed its 99% probability its VPN provider related, do the following:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md

probably corrupt database discussed a few posts back, there are no known issues with the image. Sent from my 22021211RG using Tapatalk

Q1:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

OK fair enough, i just assumed you were talking about usenet as we are in the support thread for SABnzbdVPN 🙂

So you got a DMCA notice from a usenet download?, that is highly unlikely as most if not all usenet providers use TLS encryption and therefore any downloads will not be visible to your ISP either with the VPN turned or not. The VPN is purely there to prevent your usenet provider from being able to identify your IP and therefore potentially (highly unlikely) inform your ISP or copyrights holders of your activities.

Because if the vpn fails to come up the application is not started and thus you cannot access the web ui, its a safety feature to prevent ip leakage. This is your issue, from your log:- [UNDEF] Inactivity timeout (--ping-restart), restarting see Q17:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

if its happened all of a sudden its nearly always vpn provider related, do this:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md

you might be hitting a cookies related issue, try using a different browser or using 'incognito mode', just to confirm the defaults:- Web UI Credentials Username: admin Password: crafty Looks like Crafty Developers have now switched to using a dynamically generated password if a password is not set, this can be seen in the log at /config/supervisord.log:- HELP: No default password found. Using password created by Crafty. Find it in app/config/default-creds.txt so if you then look in /config/crafty/app/config/default-creds.txt you will see the credentials to login, i shall update the readme

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

The fact that public work fine and private do not leads me to think the private tracker is most probably blocking vpn provider ip ranges due to abuse, or the tracker is blocking specific torrent client versions (check with private site). So you could try hopping around different vpn endpoints to see if you can find one that isnt blocked, or even switching vpn provider, but there is no guarantees you wont hit the same issue again.

guys, please do keep this in mind:- https://forums.unraid.net/topic/44142-support-binhex-plex-pass/?do=findComment&comment=433841 im running the plex image i built and its stable, plex pass is for people in a rush for new shiny features.

in a word, no, python 3 is used in this image and search plugins work fine for me with the latest image, so not really sure what is causing your issue, best thing to do would be start from scratch on the container.

ha there a go!, def the cause.

that is not normal, are you sue your usb key is ok?, keep in mind docker template config is stored on the usb key, so if the key is corrupt then you may start seeing weird issues such as this. try temporarily saving another change for another container, does this stick or does this also revert back?.

so you left clicked the deluge icon in unraid docker web ui and selected edit and then edited the Key 9 (LAN_NETWORK) right?, if not thats what you have to do, then click 'apply' at the bottom.

sorry i dont know what you mean, can you post some screenshots?

so what is the value of LAN_NETWORK now and what is the ip of the machine running the web browser?.

im not after the ip of the server, i was asking about the ip of the machine you are using to attempt connection to the web ui, what is it?, if its not in the range i stated above then that is your issue (highly suspect this is the case). to fix it simply add in your additional vlan's that you want to access the web ui from using a comma to separate values, for example:- LAN_NETWORK = 192.168.162.0/29,192.168.164.0/24,192.168.166.0/24 obviously the above is an example i dont know how you have defined your vlans but hopefully you get the idea.

what is the ip of the machine running the web browser that is attempting connection to the web ui? is it in the range of 192.168.162.0 - 192.168.162.7 ?