brent3000

Behind Deluge I have Prowlarr and Flaresolvarr which is also unable to connect (which is what the ports are used for) but also if the VPN is enabled would I not need to have the ports for input set for the external containers to access Deluge? or is Deluge not considered behind the VPN? Yes this is enabled No I have not as I didnt know this was considered a proxy and didnt know the settings how to apply that as a proxy? I normally would think of something like nginx as a proxy but this I considered as just like I would connect to the WebUI using the IP it would be the same concept. Can you advise how the proxy settings should be setup when communicating with an app behind the VPN? I assumed if all the ports and containers were mapped they would flow the IP across (LIke when I access the WebUI for Prowlerr it works fine no issues, but asking to verify a site then fails.

I did set the LAN in it but tthe same errors and as mentioned, its working fine via the WebUI. Yes this is using a fixed IP on the same VLAN as the other containers trying to connect. As mentioned they can ping the container, they just cant kick off the Deluge sync (which works when the VPN is off) Sometimes work and timetimes it does not does that mean its going to be abit of a lucky dip >_< As mentioned the fact it works when the VPN is offline and it cant ping makes me think something about the VPN ports arnt sticking. As I mentioned, I did make the container some time ago and had to manually add the extra functions, is it possible they arnt applying correctly? Is there a way to validate in and out ports are being set correctly which I can test? As it can ping but it cant access it via port 8112 makes me think its the ports not opening? Both are using the same setting (Reminder both Sonarr and Radarr are NOT behind the container and are on dedicated IP's on the same VLAN

As mentioned it's been working for mo ths before hand and it must have been a recent update or something it's all stopped (it's not a new deployment) The VPN input and VPN Output ports are setup as mentioned the webui works for all the containers behind it and all the containers are on the same Vlan, which was all working fine up untill a week or so ago untill I noticed only my RSS feeds were connecting and nothing else behind the VPN was. And the strange thing is, when the VPN is turned off everything works as expected, something about the VPN being enabled stops all containers being able to communicate with the VPN app container and everything behind it (as per the logs as well the VPN out and in ports are setup and we're working before a recent update. Unless the VPN ports are setup back to front but as mentioned, it was working, other containers can't even communicate with deluge let alone anything else behind it so it's something within the whole container stopping even that working. I don't think it shows in the logs but I did also try adding the deluge ports to the VPN input and outputs to see if that is needed (even tho it's declared further up) but same results

I'm not having any issues accessing it via the web UI, my only issue is none of my containers can verify the deluge settings (My local lan is not being impacted when trying to connect to the WebUI and using the container stand alone works fine) As mentioned Everything is working Webui for all Containers behind the VPN + the Container itself, The issue I'm having is that my other containers cant connect to it (They can ping them from the other containers to the VPN container but none of the setups work to verify Deluge to the container when the VPN is enabled) As mentioned when the VPN is on, Deluge Works fine The VPN connects and shows the new external IP fine Containers behind the container work fine (WebUI etc) BUT no other containers on the same vlan can verify the Deluge settings or access any of the conatiners behind the VPN (Ping of the .4 works so the container can 'see' it but thats the only response I get, everything else times out) When the VPN is OFF As above, all WebUI's work All other containers can NOW communicate with the Deluge and verify + all other containers using its network

So I have x.x.11.0/27 called out in LAN_NETWORK When I go to Sonarr (Orr any of them) and I try and validate the torrent client it will spin and timeout. Or do I need to even add my LAN from the PC which I'm using the webui from? THat woudnt make any sense as the container will self validate and its still failing For example, DelugeVPN is .5 Sonarr is .6 Both are x.x.11.0/27 My lan (where my Computer is) is x.x.12.0/27, are you saying even this IP needs to be whitelisted? If I'm using a RevProxy? As that is also in the same /27 as the other containers Strict IP is enabled then the container's own regular sync should self validate but they have been in the same error for over 24 hours (When it self checks every 6) EDIT: Added my local IP range and same error, but I think thats not the issue or maybe its not applying the values correctly as mentioned, the containers can ping from outside to the VPN container but the container dosnt seem to receive it when sending the validation from Sonarr

All of the containers are on the same vlan, when the VPN portion is turned off it works fine the system can Ping the container but none of the request (From Sonarr etc) are processed. Turn the VPN off and everything works. Where would I define it if the containers are all running on x.x.11.0/27 where or what else do I need to define? As mentioned the strange thing is, VPN is on, none of the containers can talk (either the VPN container or the containers behind it) but from the other containers I can ping it. When the VPN is disabled, no other changes everything works (Which to me rules out the network itself being an issue right?)

Done see attached supervisord.log Command execution.txt

Not sure if there has been some changes recently but suddenly all of my systems cant connect to the VPN container when its enabled with the VPN. When the VPN is enabled and working my containers on the same vlan fail to verify the settings (Unable to connect). Yes the conatiners can ping but it wont verify the settings or connect to any other container running on that VPN. When I set VPN_ENABLED to No, everything starts working again. Did something change in a recent update or is there a new setting I haven't setup as my instance has been running for some time,

Ok so something in the system is forcing this IP to be blocked or un-accessible, the container works a treat on legit any other IP, what or how or where do I see this IP being consumed and kill that specific value without needing to re-map all my networks? None of my other apps seem to have this issue so I'm not sure if its just the way Pihole is setup to run or if there is a way to force it to run as there is no docker containers even running yet it thinks the IP is taken, I have even had the container offline for over 2 hours while working on some other tasks and still the same error. What validation or checks does this even do to verify the address is already in use? EDIT : Some more searching and the issue seems to be related to a 'stale' IP in the local-kv.db causing the issue, is there a fix of a KI about this? My current fix after almost killing my server is just to make the ip from .2 to .20 but this isnt a fix as nothing can use the .2 address now it seems (none of the other docker containers can now start on it)

So this issue came back again, is there a way to force a docker to run or flush any stale IP's? I'm not keen on always rebuilding my lan details every reboot, not sure if its something with Pihole or something greater,

Sooooo odd update, I changed my Devices variable from GPU-xxxxxxxxxxxxxxx as per the plugin, and set it to All and then reloaded the docker and it seems to be working now, Not sure if there is something strange with Plex or just using the specific GPU to call out in the variables but that seems to have fixed it for me now,

I did mention in my post that I tested it on web, android, and desktop client along with others from using my library which are also on and off transcoding, all are using CPU no HW. I have also tested different media, fully stopped media and tested other media to help validate, I only have the following '--runtime=nvidia' along with the 'NVIDIA_VISIBLE_DEVICES' which is using my GPU ID as per the plugin (which is showing correctly in Plex) 'NVIDIA_DRIVER_CAPABILITIES' set to All Do I need all of them to make it work if there has been changes or which other options should I be testing? As shown in plex dash it sees the GPU correctly, not sure if there is another variable I'm missing or something which I can use to trry and get more logs to why it dosnt use the HW Should I attempt to remove the drivers, re-install the plugin or is there a way to re-install the drivers another way?

Just going over the current thread as I have noticed that my system has since stopped using the GPU to transcode and is hitting the HW. Wanted to make sure if there was specific steps or things needed since 7.3 (As i updated recently when I now noticed the issue) but also if my plex may just have some out-dated settings? Transcode tested on both web and app all use CPU only when settings call out HW preference My diag file is attached, My docker image has the '--runtime=nvidia' along with the 'NVIDIA_VISIBLE_DEVICES' and it was working prior (not sure 100% when it stopped but it deff isnt using the GPU now) GPU is showing in the transcode page and the driver is on the 'Recommended Driver: 580.159.04 (best-available)' Not sure if there is more I need to do on the docker template since an update/changes as I see there are comments with other variables being listed but others saying the --runtime option should be suitable, glados-diagnostics-20260616-2318.zip

Ok so the drive seemed to clear correctly it seems, Will clear the error and keep a pulse check on it UUID: --- Scrub started: Thu Jun 4 15:08:33 2026 Status: finished Duration: 0:30:45 Total to scrub: 1.59TiB Rate: 903.94MiB/s Error summary: no errors found

will do, so its first fix if it happens again is replace the Sata cables yes? Drive itself isn't showing signs of failing?

@JorgeB they are in the original post (under the image) https://forums.unraid.net/applications/core/interface/file/attachment.php?id=381921&key=8a90b67e160ce9fe935e3e1f456ddeaa @itimpi It seems to show the same info as there was Read/Write errors but I'm not sure if its due to a drive about to die or something else as it was just one of the drives as shown in the first screenshot Below is the expansion of the read/write errors, The numbers havent changed since they appeared but I'm not sure if I need to run something to validate if the data is still ok (as they are mirrored) Do I just click the reset button and move on unless it comes up again or is the drive on the way out or something else caused this one drive to throw errors, glados-diagnostics-20260603-1229.zip

I did some more digging and I found this suggestion that it may be a stale address or something just stuck in the system and wont release the IP, the comments seem to be related 'due to a stale IP allocation in Docker's network database.' /etc/rc.d/rc.docker stop cp /var/lib/docker/network/files/local-kv.db \ /var/lib/docker/network/files/local-kv.db.bak rm /var/lib/docker/network/files/local-kv.db /etc/rc.d/rc.docker startI had to also re-create my docker networks following this, This ended up resolving my issue but I wanted to know what may have been the cause of this or what would be the issue which would have prevented one single container from reloading post reboot but also what would be a good way to avoid this in the future?

I recently recived an error notification on one of my pool drives (which is an SSD) and I'm not sure what to make of this if it was a once off or if something else may be an actual issue (Normally if its an SSD drive about to die they just drop off) Where would I be able to see the cause of this issue or what may have caused it or how to clear the notice and fix the issue? glados-diagnostics-20260603-1229.zip (The CRC error I believe was fixed when I replaced the cable some time ago I dont believe that's recently changed)

I've had an issue rrecently where one single docker (out of all of the ones I need its PiHole which runs most of my things) for some reason wont start when its assigned a specific IP following a recent reboot docker: Error response from daemon: failed to set up container networking: Address already in use When I change the IP it boots just fine and has no issues but for some reason I cant allocate it the same IP its had for years now, I have tried, Turning off Docker and turning it On All other containers are stopped and nothing is using that IP No ping response from the network showing if something else has taken the IP within the network docker network inspect -v br0.101 shows nothing else is using the IP's running The container has been working fine until a recent reboot to update my server and now just this one container wont start on the custom port. All other dockers appear to be working fine, When I change it to another random IP it comes online however I have alot of things mapped to this IP so I would rather fix the issue than just change the port as something is taking this port or blocking docker from starting using this IP. Is there a way to force it to start knowing the IP is available? Edit more testing So did some testing and it seems no docker wants to use the address which I have allocated to Pihole on the network, so something is blocking any container using the specific IP. What would be blocking one specific IP from being used?

Just installed this and had this issue, so still mapping to 80 in the template so needed to manually change it over,

Hi Team, Not sure if its just my system but based on the screenshots of others there seems to be something wrong with the background on mine, is there a setting that is meant to make this not hurt my eyes while using 😵‍💫 Ive tried in-private mode and normal to see if the cache is an issue and it still loads the same

For reference if anyone needs it, [BUG] Adding additional network interfaces causes access issues · Issue #610 · linuxserver/docker-swag Issue fell back on the Docker network motions, when using a vlan docker doesn't respect any port mapping requests and will default to this IP due to how Docker handled networks. This is why the ports failed to work on the Docker network along with why the system preferred the vlan it was allocated. Final workaround was mapping all ports from the 1443 to the 443 the container used by default as the VLan it was allocated does not use the port redirects.

Hi Team, Looking to get some guidance or advise on my setup, TLDR : Looking to see how I can route my DNS to a Nginx Rev Proxy while its running on a docker network The Setup, Following a number of guides (The Ultimate Guide to SWAG on Unraid: Beginner to Advanced - Uncast Show to Installing and Configuring NGINX Proxy Manager on Unraid and a lot more which have a similar concept) the end goal is setup a docker network 'proxy' and have selected containers running within it by name or call out the specific IP for containers outside of the docker network. The Goal Using my Pihole setup I'm looking to have local DNS reference the SWAG container directly so when I'm within the network it will route locally vs going out to Cloudflare then needing to route me back in to my local network. This will avoid me needing everything (even my internal only apps) to have records in CF to use the FQDN vs the IP The Issue All the guides seem to suggest and recommend having a docker network for the Nginx system to live in and any apps which are being thrown in should also live on that network for ease of use within the setup etc. When I try to route Cloudflare/Internet DNS traffic is works no issues as my router sees a 443 request and it converts it to the local xxxx port that Nginx is using (no problem here). The issue comes in when locally I try and do a similar process, using PiHole for example, it only allows like A and CNAME records are designed for, pointing at a specific host and not allowing ports to be changed etc. When I do this the Docker network (which is seen by the browser and the local LAN is actually the raw IP of the Unraid server (so any attempt to access [docker].<my-Domain-name>.com will hit the 443 port on the unraid server NOT the Nginx port (which is mapped from the public from 443->xxxx as mapped in the docker template, as per most of the above videos) doing this mapping locally when I try to access the FQDN I land at the unraid dash login which is listening on 443 as the main server. Attempted fix's Solution - Externally map to the container IP and allow the F/W to re-map and for any local traffic route to an IPv4 address attached to the same SWAG docker. Solution Issues - When I map either the proxy or the vlan to the Docker ( Using "&& docker network connect <name of vlan OR name of docker network> swag" along with even setting the gw_priority but no matter which network was loaded into the template or added it still failed and preferred the vlan) all the other functions seem to break and my WAN routing causes anything which was working to then stop. This is even when the listening port is setup for just the port or even <docker ip>:443 for example. I'm not sure if swag just isnt built to work with two interfaces correctly or if there is another section of the config I need to change to let the system use both as it seems to always fall back to the vlan as all of my prior working seem to break when adding the network settings above. So I'm hoping someone may have a workaround for this, or know why adding the extra network to the Docker seems to break things (I recall reading that networks are added in a specific priority and not sure how I can change it within the template that one network is taken above another for preference) Or should I just forget everything about the videos about building this 'proxy' network and just move it to a separate vlan and call it a day? I have seem issues posted over previous platforms and the fix seems to be just change the default unraid ports and let it flow, but I'm hoping there may be another way to make this work when trying to use the Rev proxy on the same box where the Pihole is without breaking the other way things work.Need some help with Pi-hole local DNS and Nginx Proxy Manager : r/unRAID Just to clear up some possible questions, Everything works fine using Cloudflare, port forwarding etc both internal and external when the system is mapped to the 'proxy' network, once I add another network everything stops working and I get an error trying to load the apps Both networks show when I inspect the docker container and are issued IP's The app can ping containers in the proxy and vlan with no issues (by Name for proxy based and by IP for the vlan base) Using Unraid 7.2.0 SWAG 5.6.0 by Linux Server Hope someone can see my issue or point me to some guidance,

Sorry to bring this one back up, but does anyone know if there is a way to map these to an IP based network as a bridge vs giving them an actual IP? TLDR I'm at the state Adam is above, they are connected and in use, but I'm looking to use selected apps in a network managed IP Vlan and then wanting some of the back-end (Statless,Database etc) to be on their own Network layer. When I connect a bridged docker to a ipvlan its issued an IP and I'm trying to avoid having them consume the same IP's else I would just built another vlan and track more at the network side. THoughts on how this can be done before I need to start a new thread and reference this chain

Ok more progress, my router had a combined policy and it was using NAT for both v4 and v6 my system is now showing the correct IP, more testing inbound, still cant load it directly using the IP in the address bar as it has a connection problem when it loads the ipv6 directly. I would assume if it has an IPv6 assigned I can access it from the web UI without a port or is that not the case typically?