Pihole on docker won't show the web UI

Setup:

Docker Compose (config below) on a unix box

  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp"
      - "9080:80/tcp"
      - "9443:443/tcp"
    environment:
      - PIHOLE_DNS_=1.1.1.1;1.0.0.1;8.8.8.8;8.8.4.4
      - VIRTUAL_HOST=myhostname.local
    env_file:
      - ./.env.compose
      - ./secrets/pihole/env
    volumes:
      - ./data/pihole/pihole:/etc/pihole
      - ./data/pihole/dnsmasq:/etc/dnsmasq.d
    cap_add:
      - NET_ADMIN
      # Should nto be required
      - CAP_NET_BIND_SERVICE
      - CAP_NET_RAW
    restart: unless-stopped

ENV files set the following keys

  • WEBPASSWORD
  • ADMIN_EMAIL
  • PUID
  • PGID
  • TZ
  • UMASK_SET

My local machine has a /etc/hosts entry to map myhostname.local to it's local IP (just in case)

Expected Behaviour:

URL should load on myhostname.local:9080

Actual Behaviour:

URL does not load

Debug Token:

56eeq47h5g

Additional debug steps taken:

  1. From local, curl myhostname:9080 did not work
  2. From the host machine (running docker), curl localhost:9080 did not work
  3. Verified the ports exposed by the container using docker ps | grep pihole on the remote machine
  4. From inside the docker container (docker exec -it pihole bash), tried curl localhost and it did not work

Logs clearly state that the HTTPd did not start-up. It seems to be crapping out in the step before that (around FTL). Not sure how to debug further. Tried running this docker-compose locally and it started up correctly. What am I missing?

For what it's worth, I set this up last night and had all my traffic flowing through it fine. I made some changes and it refuses to start up now and I'm not sure what I have screwed up on my server. I have attempted to delete all the state and it didn't work.

State removal steps I used:

  • Container: docker system prune -a
  • Data: run -rf ./data/pihole

Running lighttpd -D -f /etc/lighttpd/lighttpd.conf from inside the pihole container starts up lighttpd. Based on the start.sh code for the container, it looks like the FTL script isn't completing causing the lighttpd to never come up. Not sure why FTL isn't starting up though :frowning: I'm a newbie in this area and directions to debug will help.

Docker logs that I can't debug further:

[cont-init.d] 20-start.sh: executing...
 ::: Starting docker specific checks & setup for docker pihole/pihole
Failed to set capabilities on file `/usr/bin/pihole-FTL' (Operation not supported)

What capabilities is it trying to set? What should I be setting here? I've tried setting only NET_ADMIN and that did not work either.

Some side notes upfront:
Avoid using pihole:latest for production use.
It's good for evalution and to get you started, but binding to a specific version will spare you from unintended upgrades by just restarting your container or rebooting your machine.
Port 443 isn't stritcly required by Pi-hole anymore, especially if you stick with Pi-hole's default NULL blocking mode (recommended).

As for your issue, there's nothing in your config that stands out, but then you are not showing us your whole configuration.

Just a guess:
Get rid of that .local domain portion and see if that would fix your issue.

local ist the domain name reserved for the mDNS protocol and shouldn't be used with DNS.
If you go by the specs, a query for *.local should never make it to any DNS server, but go to the mDNS multicast address:

Any DNS query for a name ending with ".local." MUST be sent to the
mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6
equivalent FF02::FB).

Even if it's not related to your issue, it's still good to avoid it.

EDIT:
In addition, there seems to have been a problem with some recent Docker version itself when binding to port 53, see Docker unable to bind to port 53 - #14 by goo3r

Avoid using pihole:latest for production use.

Fair point. I use latest when I'm starting off and figuring out the config. Once I set it up (usually in the first day), I switch it to a hard version. Thanks for the call out.

Port 443 isn't stritcly required by Pi-hole anymore, especially if you stick with Pi-hole's default NULL blocking mode (recommended).

Nice. I'll take the 443 out after going through the blockingmode docs

Get rid of that .local domain portion and see if that would fix your issue.
I have tried going to the local IP directly (curl 192.168.x.x:9080) and running a curl localhost:9080 from the machine and neither of those worked

Based on the logs and some of the code in start.sh, lighttpd never started up explaining why the curl calls fail (from my machine, from the box running the container and from inside the container). All of its seems to be tied with FTL (which I don't understand)

In addition, there seems to have been a problem with some recent Docker version itself when binding to port 53, see Docker unable to bind to port 53 - #14 by goo3r

I'm running an older version of Docker (and not on Windows)

$ docker --version
Docker version 19.03.8, build afacb8b7f0

Ran netstat to find nothing listening in on :53. I'm trying to find out why :frowning:

I just replaced :53 with :9053 in my docker compose to check if my system is blocking my attempts to start on port 53. The container did not boot correctly.

I'm trying out different image versions to see if this is a problem with the current build on the master branch. I was on latest earlier, I tried buster and I'm now trying stretch.

snippet of the latest debug logs

*** [ DIAGNOSING ]: Ports in use
[53] is in use by pihole-FTL
[53] is in use by pihole-FTL
[4711] is in use by pihole-FTL

[...]

*** [ DIAGNOSING ]: Pi-hole processes
[✗] lighttpd daemon is inactive
[✗] pihole-FTL daemon is inactive

*** [ DIAGNOSING ]: Pi-hole-FTL full status
[i] systemctl:  command not found

Can't get the full Pi-home status because buster does not come with systemctl :frowning: Might be something worth fixing for debugging. IIRC, stretch is an older version and might have systemctl so I'l trying that out now.

Update: Buster didn't help. I'll go back to an older release and try it out to see if there's been an issue.

It's probably my setup because it was working fine last night and I'm not sure what I changed in the morning. :confused: I'm not sure how I can fix it. I've tried deleting the container and the associated state but it isn't helping :frowning:

Did you try removing .local from your environment yet?

I don't think it's related to the latest image version.
We'd have received far more support request if it were.

Yes. Here are the virtual hosts I've tried

  1. redactedhost.local
  2. redactedhost
  3. pi.hole

Every one of the tests was run with the following command: docker stop pihole && rm -rf data/pihole/ && docker-compose up -d

The docker configuration is

  pihole:
    container_name: pihole
    image: pihole/pihole:v5.7-stretch
    ports:
      - "9053:53/tcp"
      - "9053:53/udp"
      - "9080:80/tcp"
    environment:
      - VIRTUAL_HOST=pi.hole
    env_file:
      - ./.env.compose
      - ./secrets/pihole/env
    volumes:
      - ./data/pihole/pihole:/etc/pihole
      - ./data/pihole/dnsmasq:/etc/dnsmasq.d
    restart: unless-stopped

And the env files have the following keys:

  • WEBPASSWORD=redacted
  • ADMIN_EMAIL=redacted@redacted.redacted
  • PUID=500
  • PGID=1000
  • TZ=Asia/Kolkata
  • UMASK_SET=022
    (other containers in my compose file use these variables. Next up, I'll try removing them to see if it helps). I doubt it does because it was working last night with the same setup.

Absolutely. Plus this image worked last night. It's definitely something wrong with the host machine but I can't figure out what since I've changed the image and also deleted ./data/pihole to reset it's state. :frowning:

Any idea what this means from the docker logs?

$ docker logs -f pihole
[...]
[cont-init.d] 20-start.sh: executing...
 ::: Starting docker specific checks & setup for docker pihole/pihole
Failed to set capabilities on file `/usr/bin/pihole-FTL' (Operation not supported)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file

I noticed a very similar issue when mounting /usr/bin on a NFS. I'm running everything inside the docker container and nothing is mounted to /usr/bin :disappointed:

Update: Forgot to link the "very similar issue"

On further reading, I noticed that there's a few capabilities that docker restricts but none of them seemed to be used in the FTL command that's failing. I unrestricted the security options just in case by adding the following lines to my docker-compose.yml

security_opt:
  - seccomp:unconfined

It did not help me. The search goes on. The container works fine on my macbook but not on the server I'm running on. It runs inside a container at all times. It used to work fine on my server and then it stopped. Running docker system prune -a did not help. LMK if anyone has other ideas.

It's not necessary to set those extra options, the stock image will run just fine in a stock Docker environment.

The Failed to set capabilities message you quoted may hint at a problem when binding the port, which in return would make your issue appear similar to Docker unable to bind to port 53 as linked above.

Did you check with Docker for an updated release?

A docker release is not available for my environment yet :disappointed: Shouldn't my attempt to bind ports to 9053 instead of a potentially restricted 53 help?

Excerpt from my docker-compose.yml:

      - "9053:53/tcp"
      - "9053:53/udp"

Upgraded to the latest docker. Either the upgrade fixed it or the latest version did :man_shrugging:

Went from Docker version 19.03.8, build afacb8b7f0 to Docker version 20.10.5, build 55c4c88

Just found the real reason this wouldn't work. The machine's /etc/resolv.conf had the following entries

nameserver 192.168.x.x
nameserver 1.1.1.1

options single-request

The first entry is the local address of the machine itself. This came about because there's something on the machine that's fetching the DNS entries from the router and setting it in the conf. The router requires the config for all the hosts to use the correct DNS. Since this machine is one of the hosts (it runs things other than pihole), it gets this DNS that is causing an issue. Manually editing the nameserver line out before starting pihole fixes the problem.

I probably have to automate this in my deployment process meaning that the start script makes sure it removes the namespace before starting pihole and enables it after.

Update: A cursory reading tells me the dhclient automatically updates /etc/resolv.conf. If I edit the file before I start pihole, it will come up. dhclient will then update the conf so all requests from the machine go through pihole (which runs inside a container on the machine).

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.