Network Issue after container creation

countryboy71 · February 27, 2023, 1:50am

Good evening everyone. Hoping someone is able to assist me as I have been scratching my head for a while on this one.

I have been trying to create a couple of containers (Sonarr & Radarr) and even though I can get them successfully deployed, I am not able to view either of their respective pages. The path comes out as;

‘0.0.0.0:8082’ (or 7878, as the case may be), instead of the expected ‘localhost:####’. I have tried creating the container manually and via compose with the following;

---
version: "2.15"
services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    environment:
      - PUID=501
      - PGID=20
      - TZ=America/Edmonton
    network_mode: 'bridge'
    volumes:
      - /Users/username/configs/sonarr:/config
      - /Volumes/Storage1/TV
    ports:
      - 8082:8082
    restart: unless-stopped

if I leave the ‘network_mode’ out of the file, it defaults to ‘configs_default’…not even sure what that is.

In ‘Connected Networks’, I am seeing ‘bridged’, along with IP’s and my ‘MAC address’, which is the same as the Portainer, which is working as expected.

For reference;

MacOS - 12.16.1 (Monterey)
Docker Desktop - 4.16.2
Composer - 2.15.1
Portainer - CE 2.17.1

ajeetraina · February 27, 2023, 5:46am

First of all, with the latest Docker Compose V2, you can skip mentioning the top-level version property. Top-level version property is defined by the specification for backward compatibility but is only informative.

It looks like the issue is with the port mapping in your Docker Compose file. When you specify the ports section like this:

ports:
  - 8082:8082

you are telling Docker to map port 8082 from the container to port 8082 on the host (your local machine). However, since you’re seeing the IP address 0.0.0.0 when you try to access the container’s web interface, it means that the container is not bound to localhost.

To fix this, you should change the port mapping to:

ports:
  - 127.0.0.1:8082:8082

This will bind the container to localhost (127.0.0.1) instead of 0.0.0.0.

Regarding the network_mode, you can remove that line as it’s not necessary for your setup. By default, Docker Compose will create a bridge network for your services, which is what you want in this case.

After making these changes, run docker-compose up -d to start the containers and try accessing their web interfaces using localhost:8082 and localhost:7878 respectively.

countryboy71 · February 27, 2023, 4:06pm

Good day and thank you for the detailed response. I tried your solution and the problem persisted. I will note that when I installed portainer as noted on their website;

docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

resulted in the desired result. I was able to load the page by using my local static IP.

Neither Sonarr or Radarr would load successfully. I figured perhaps there was an issue all the way back at the beginning of the installation of Docker-Desktop so I removed everything and have reinstalled Docker-Desktop.

There are a couple of items that I am questioning after reading some notes about it.

Should I be using VirtioFS instead of gRPC
Under ‘Resources’, the docker subnet, by default, is set outside my own;

Mine:
192.168.1.##
Docker:
192.168.65.#

In the ‘Docker Engine’ section, I read an article that says I should be defining ‘local’ in the daemon…true?

In everything I have read and watched on installing Docker/Portainer/xContainer, I don’t ever recall them having so many issues!

countryboy71 · February 27, 2023, 7:22pm

Just wanted to add a couple more thoughts.

On a whim, I deployed the ‘hello-world’ container, just to see and it works just fine.

Not sure if this is something of a concern, but I see the following when I create and deploy the Sonarr or Radarr containers but not on the Portainer or Hello-World ones; it places them in a ‘configs’ ‘Stack’

rimelek · February 28, 2023, 3:59pm

I am just jumping in the converstation so I will start from the beginning to make sure I understand the issue

Based on this I guess your problem is that you can’t access the IP:port from the web browser, right?
However I am not sure what you meant by the following:

Where that path “comes out”? I guess @ajeetraina recommended you to change the port mapping because it looked like you wanted to access the web page only from localhost.

Since you didn’t show what you meant and I don’t use sonarr, I guess sonarr shows the IP and PORT when it starts on which it is listening to the logs. If it is the case, it just means it is listening on all of the container’s IP addresses. It is important not to listen only on localhost, because that would never be available from outside the container with or without port mapping. The fact that it is listening on every IP address in the container, doesn’t mean it will be available from the outside. In case of Docker Desktop, you need port mapping, which you have of course.

Can you check if you can access the website from the container? If you don’t know how, I can give you an example later.

If your project folder is “configs”, the default, automatically created bridge network will be called “config_default”. If you define a custom network in the compose file like:

networks:
  mynetwork:

that would be created as “configs_mynetwork”.

Yes, you should. virtiofs is faster and switching to virtiofs solved a lot of issues, but I don’t think that it is related to your issue unless the service in the container could not start properly because of a filesystem issue.

That is normal. Docker Desktop uses a separate subnet in the VM.

I am not sure what you mean by that. Can you show it?

Is the screenshot from Portainer?
Do you expect to see portainer on the portainer dashboard?