Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About b0m541

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The issue seems to have been fixed. If I check for updates, containers will no (as expected) show to be up to date, if there is not update available.
  2. Updating the one by one does not help on my end. Also if I update just 1 of the LSIO containers it will show that it has an update available immediately after updating and checking for updates.
  3. I haven't had this problem before, it occurred yesterday for the first time. No update of unRAID OS since quite a time. Running 6.7.2. Docker says that most of the containers have updates available. However, when I click on "apply update" Docker tells me that the container is already up to date and nothing is downloaded. So basically the update notifications are "false alarms". Now it is hard to know which containers really need updating without asking to update all of them, which means they are all restarted - not what I want. Any ideas what's going on and how to fix it? Thanks for spending your time on helping out!
  4. Summary: Fetching NZB from URL works only with internal docker container IP, not with real host IP Description: Some content management application M only send references to NZBs to the downloader as an URL so that the NZB must be fetched by the downloader itself. Imagine that the NZB URL points to NZBhydra2 as meta indexer X running in a docker container A on the same host H where SABnzb is also running in a docker container B. As a result M (running in docker container C on H) wants SABnzb in B to fetch the NZB from X in A. The containers A, B, C run in their vanilla setting as downloaded (Bridge mode), just the pathes were set properly. Container A is the linuxserver container with NZBhydra2. Container B is the binhex container with SABnzbd, OpenVPN and Privoxy. Observation: Depending on how X (NZBhydra2) is referenced in the URL, SABnzbd will be able to fetch the NZB or it will time out, and this can be verify using curl in the container terminal session What works: (1) internal IP of container A running NZBhydra / curl 172.17.0.x:5076 works What does not work (2) external IP of container A running NZBhydra, i.e. real IP of host H / curl "local IP":5076 -> connection refused (3) local DNS name of H / curl "local dns name":5076 -> Could not resolve host Thoughts: (1) should NOT work, since this IP may change and applications external to the container should always use the real IP address or DNS name of H, could be that OpenVPN treats the container-internal IPs as on the same network and not to be forwarded through the VPN tunnel? (2) should actually work, could this have to do with OpenVPN, sending traffic for IP of H through the VPN tunnel and nothing answering there? Why would it consider its won hosts real IP address to be on the internet and not on the own end of the tunnel? (3) reason: if using the binhex SABnzbd-VPN container, within the container local DNS names cannot be resolved because all DNS traffic is sent to the DNS server on the other end of the VPN tunnel My questions (decreasing priority): -How can I make (3) work? probably some proper setting for OpenVPN for name resolution? which? -Why does (2) not work and how can I make (2) work? -Why does (1) work and how can I prevent container-external processes to access container-internal IPs? Thank you for your tme and effort!