binhex

attached log is for krusader, try again.

where in the above does it say its disconnecting?, that log is simply confirming what the current assigned incoming port is.

Two thoughts spring to mind, firstly the security issue with unraid, is this running in 'host' mode perhaps with tailscale enabled?, if so then that is one possibility, he states his container is up to date so the CVE with qbittorrent (affects qbittorrent less than v5.0.1) shouldn't be the issue here but worth ensuring you guys are up to date.

I shall do the same then, obviously that won't stop existing users from still pulling from Docker Hub, but hey at least new users will be pulling from GHCR. EDIT - Completed.

My last comment on this as it looks like we have a workaround via cli for now, a question that i don't have an answer to yet - Is a no-op pull counted as a pull by Docker Hub?, as in docker image sha on disk matches docker hub image sha, no changes required, if so then if a user clicks on 'check for updates' then unless they have less than 10 containers then this will hit the limit causing subsequent checks to fail, even if there are no updates pending. I am seriously considering switching the registry over to ghcr for all my templates (i push to docker hub, ghcr and redhat quay) but i don't want to do this unless i have to.

Ahh yeah you are qutie right, the dir is symlinked over to your USB Key (/boot), makes sense.

I'm surprised that is persistent, i assume that must be writing your credentials to some location on your USB key then. @SpencerJ Any thoughts on possible inclusion of Docker Hub login via the web ui?, it would be a nice edition and would completely circumvent the issue (100 pulls per hour for authenticated users). EDIT - looks like the authentication token is stored in '/root/.docker/config.json', so for me at least it will not be persistent, so 'go' file is required, output from docker after authenticating:- 'WARNING! Your password will be stored unencrypted in /root/.docker/config.json.'

most probably cookie related, it can really mess stuff up, try viewing the two containers in two different browsers.

Just in case anybody missed the memo, the unauthenticated pulls could affect some users, especially if wiping their docker image and then attempting to pull down more than 10 images in a single hour ( a strong possibility) whilst not being authenticated:- No Pull Charges or Limits for Paid Users: Effective immediately, all paid subscriptions will benefit from unlimited pull consumption and unlimited pull rates (within fair use). This change ensures that teams relying on Docker Hub can work without disruptions and enjoy full operational flexibility. Updated Pull Rate Limits for Free/Unauthenticated Users: Unauthenticated users will be limited to 10 pulls per hour. Free authenticated users will have an increased rate of 100 pulls per hour. For those automating processes or requiring a smoother experience, we recommend using Personal or Organizational Access Tokens (PAT & OAT) for seamless integration. Storage Charges Delayed Indefinitely: We have indefinitely postponed the introduction of storage-based billing. Instead, we are developing new management tools to help you actively monitor and control your storage usage. Should storage charges be revisited in the future, we promise to provide at least six months notice so you can plan and adjust accordingly.

did you add the port you forwarded on your router to the nicotine container? if not then that will be the issue, you need to edit the container, click add and add the port with your assigned port number.

I get your logic here, but i would start with stopping all containers running through privoxyvpn then restart privoxyvpn and then start the containers again (dont try to just stop provixoyvpn, unraid goes into a hissy fit).

No that env var has nothing to do with port forwarding/incoming port, Please see Q31 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

ok so that is a successful start, i suspect LAN_NETWORK is wrong, what is the ip address of the machine you are using to attempt connection to the web ui of sabnzbd?

nope, that is not true, the sabnzbd image has not been rebuilt so it wouldn't of picked up the bug, and just to be clear if the image build was triggered right now it would not hit the same bug as all the vpn images use a shared intermediate image, which is where the bug was (and has since been fixed). most probably vpn provider related, but this will identify it:- I will need to see a log to help further, please see the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md#unraid-users

yep as suspected, LAN_NETWORK is wrong, see Please see Q4 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md from your log:- LAN_NETWORK defined as '192.168.1.0/24'

no issues there, you get assigned an ip, and qbittorrent is up and running, what is the ip address of the machine you are using to attempt connection to the web ui?

nope, that is normal behaviour. I will need to see a log to help further, please see the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md#unraid-users

ok new image has been built, please pull down. EDIT - My new friend is \K flag for grep ;-), ain't regex a bitch.

ive spotted the issue, just running tests on a fix.

You sure you got that the right way around?. If you have told SABnzbd to download to your array (which by the sound of the above you have), then the array free space will be what's shown. If you want to show free space on the cache drive then you will need to set the host path for downloads (i.e. /mnt/user/Downloads) to point at the cache drive, I would strongly advise you do this, unpacking files on the array will seriously bog down your entire server, not only that but it would mean you don't need to use mover to 'move from Array to Cache' (assuming that statement is correct).

Very odd message you got there!, it looks like docker has failed to download one of the image layers and thus you are ending up with a corrupt image, try the following:- 1. Go to unraid web ui 2. Go to docker tab and left click and select 'remove' for the plexpass container, ensuring the 'also remove image' tickbox is ticked 3. Click on 'add container' at the bottom of the docker page and select user 'user templates' and select the binhex-plexpass template, then simply click apply. Step 3 should pull down the image again and create a container for you, hopefully this time around it downloads successfully, if it still fails then i would start looking at your docker storage and ensuring it's not corrupt, also check for memory issues with your server.

that is a visual bug in unraid https://forums.unraid.net/bug-reports/stable-releases/docker-page-missing-ip-addresses-r3237/

Super cool news!!, congrats @SpaceInvaderOne

Pull down the latest image, it should be fixed

This is not strictly true, you can either run it outside or inside of the vpn, the trick is getting the VPN_OUTPUT_PORT correct, i run reader on the default bridge and prowlarr is inside a shared vpn network, here is the magic, from my setup:- Keep in mind prowlarr communicates with reader, thus the port is defined for VPN_OUTPUT_PORTS