binhex

Overview: Support for Docker image arch-bitmagnet in the binhex repo. Application: bitmagnet - https://github.com/bitmagnet-io/bitmagnet Docker Hub: https://hub.docker.com/r/binhex/arch-bitmagnet/ GitHub: https://github.com/binhex/arch-bitmagnet Documentation: https://github.com/binhex/documentation If you appreciate my work, then please consider buying me a beer 😁 For other Docker support threads and requests, news and Docker template support for the binhex repository please use the "General" thread here

assuming you have sabnbdvpn setup and qbittorrentvpn running (for example - both in default 'bridge' mode) you would then point your arrs at http://<your unraid server ip>:<the port for sab/qbit> does this not work?.

not sure how this is configured but i would suspect this is your issue, switch back to the default, which is 'bridge' and i suspect things will work as expected.

two concerns with this approach:- 1. you will have no incoming port assigned and thus torrenting will be slow 2. you are going to be routing usenet and torrent traffic over a single vpn tunnel, this will result in lower speeds if you are torrenting and performing usenet downloads at the same time.

Please see Q5 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md

This is a bug in tigervnc, for now I've rolled it back to the previous version and rebuilt the image, so please do a pull to pick up the fixed image

i think the container is listening on 8090, the issue you are seeing is that the template has not been changed to reflect the change in port, so either ignore the web ui link and simply go to http://<your nserver ip>:8090 and then bookmark it in your web browser, or left click the container, select 'edit' click on 'advanced view' top right and change the port for 'WebUI:' to 8090

Ahh Use Proxy, right!, no you do not need that switched on and it probably would cause issues. that depends, if you are using a web browser and pointing it at privoxy then nope, it will use whatever name server is defined on your machine which will most likely be your isp's name servers, if you are talking about applications running inside of the vpn network, then yes, it is fully secure.

you mean VPN_ENABLED right?, if so then you are correct.

The log shows a successful start so nothing obviously wrong, please see Q4 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md and ensure this is not the issue (commonly is).

spin up another container is the only option in that scenario.

What makes you think that?, remember your external ip address as seen once a vpn tunnel is established and the ip address of the vpn endpoint are NOT the same thing.

your previous logs show a failure to establish a vpn tunnel, if this i the case then you will not be able to get to the web ui, it will load ONLY once all checks pass to protect against ip leakage, so if you can view the web ui then the vpn tunnel is running. This sounds like to me like you are probably using an underpowered router which simply cannot cope with bittorrent traffic, try reducing the number of active connections in deluge and also make sure you throttle upload rates in deluge, you should be setting it to a max of 85% of your total bandwidth otherwise peers will max your upload rate out and you will not have any bandwidth left to maintain normal connectivity, i.e. name resolution.

if you can get to the deluge web ui then the vpn tunnel is established, so that is a step forward, have you tried downloading something?.

another possibility is DNS issues, i see you have a custom list there and look to be using PIA NS '209.222.18.222' i have had issues with PIA name servers before, so i would recommend removing that from the value for key NAME_SERVERS.

from your log:- 2024-08-26 20:57:27 [UNDEF] Inactivity timeout (--ping-restart), restarting Please see Q17 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Please see Q24 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

try starting the container from the unraid terminal, so type `docker start <name of container>' and see what the error says, my money is that its a port conflict.

That all looks fine to me, the only thing that comes to mind is the permissions.json file, check the line endings, you may have to have it set to LF (line feed) not CRLF, i use this image myself and have a minecraft world setup with operators with no issue, so im confident the image is fine. Sorry i got no idea on this, i would love to run raytracing but i don't have the hardware for it, a quick google search landed me here:-

go to unraid webui/docker click on toggle to 'advanced view' top right, click on 'force update' for the container.

Please see Q32 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

All fixed up guys, it was my error, i had forgotten about the use of the RELEASEAG from my upstream python script to construct the name of the zip, i needed to do some bash manipulation, in any case its all good, please pull down the image at your next convenience.

ok i have added in some additional code to ensure the path exists and to hard set the path for the password file, please can you pull down latest (force update).

ok yep you are running the newly built image with the password fix (although break for you), hmm, so do you have a generated password file in the following location:- /config/nicotineplus/home/.config/tigervnc/passwd if not then it could be permissions related, let me know before we proceed any further.

ok can you attach /config/supervisord.log, that will at least confirm the version you are using.