pi.hole is not reachable with docker

[ozgreat]

This is a: Bug?

Details

Hi after updating from v5 to v6, decided to switch from install to docker and from lighttpd to nginx.

Now it works not as I expected.

http://pi.hole/admin/ not working, as well as pi.hole:8084/admin/. But dns is working for sure cause other domains defined in Local domain section in web UI (e.g. jelly.oz) are working just fine as well as thier proxying in nginx.

Please help and thanks in advance.

Related Issues

• [X ] I have searched this repository/Pi-hole forums for existing issues and pull requests that look similar

How to reproduce the issue

1. Environment data

• Operating System: raspbian
• Hardware: RasPi 5

2. docker-compose.yml contents, docker run shell command, or paste a screenshot of any UI based configuration of containers here

services:
    nginx:
        container_name: nginx
        image: nginx:stable
        ports:
            - 80:80
        volumes:
            - ./nginx-config:/etc/nginx/conf.d
        # extra_hosts:
        # - "host.docker.internal:host-gateway"
        restart: unless-stopped

    pihole:
        container_name: pihole
        image: pihole/pihole:latest
        hostname: rpi
        ports:
            # DNS Ports
            - "53:53/tcp"
            - "53:53/udp"
            # Default HTTP Port
            - "8084:80/tcp"
            # Default HTTPs Port. FTL will generate a self-signed certificate
            - "8443:443/tcp"
            # Uncomment the below if using Pi-hole as your DHCP Server
            #- "67:67/udp"
        environment:
            # Set the appropriate timezone for your location (https://en.wikipedia.org/wiki/List_of_tz_database_time_zones), e.g:
            TZ: "Europe/Warsaw"
            # Set a password to access the web interface. Not setting one will result in a random password being assigned
            FTLCONF_webserver_api_password: "test"
            # If using Docker's default `bridge` network setting the dns listening mode should be set to 'all'
            FTLCONF_dns_listeningMode: "all"
        # Volumes store your data between container upgrades
        volumes:
            # For persisting Pi-hole's databases and common configuration file
            - "./etc-pihole:/etc/pihole"
            # Uncomment the below if you have custom dnsmasq config files that you want to persist. Not needed for most starting fresh with Pi-hole v6. If you're upgrading from v5 you and have used this directory before, you should keep it enabled for the first v6 container start to allow for a complete migration. It can be removed afterwards. Needs environment variable FTLCONF_misc_etc_dnsmasq_d: 'true'
            #- './etc-dnsmasq.d:/etc/dnsmasq.d'
        cap_add:
            # See https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
            # Required if you are using Pi-hole as your DHCP server, else not needed
            - NET_ADMIN
            # Required if you are using Pi-hole as your NTP client to be able to set the host's system time
            - SYS_TIME
            # Optional, if Pi-hole should get some more processing time
            - SYS_NICE
        restart: unless-stopped

3. any additional info to help reproduce
   nginx.conf:

server {
  listen 80;
  server_name pi.hole;

  set $pihole 192.168.0.100;

  location / {
      proxy_pass http://$pihole:80/admin/;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_hide_header X-Frame-Options;
      proxy_set_header X-Frame-Options "SAMEORIGIN";
      proxy_read_timeout 90;
    }

location /api/ {
    proxy_pass http://$pihole/api/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_hide_header X-Frame-Options;
    proxy_set_header X-Frame-Options "SAMEORIGIN";
    proxy_read_timeout 90;
}
}

  server {
    listen 80;
    #listen [::]:80;
    server_name jelly.oz;

    # use a variable to store the upstream proxy
    set $jellyfin 192.168.0.100;

    ## The default `client_max_body_size` is 1M, this might not be enough for some posters, etc.
    client_max_body_size 20M;


    # Security / XSS Mitigation Headers
    add_header X-Content-Type-Options "nosniff";

    # Permissions policy. May cause issues with some clients
    add_header Permissions-Policy "accelerometer=(), ambient-light-sensor=(), battery=(), bluetooth=(), camera=(), clipboard-read=(), display-capture=(), document-domain=(), encrypted-media=(), gamepad=(), geolocation=(), gyroscope=(), hid=(), idle-detection=(), interest-cohort=(), keyboard-map=(), local-fonts=(), magnetometer=(), microphone=(), payment=(), publickey-credentials-get=(), serial=(), sync-xhr=(), usb=(), xr-spatial-tracking=()" always;


    location / {
      proxy_pass http://$jellyfin:8096;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header X-Forwarded-Protocol $scheme;
      proxy_set_header X-Forwarded-Host $http_host;

      # Disable buffering when the nginx proxy gets very resource heavy upon streaming
      proxy_buffering off;
    }

    location /socket {
        # Proxy Jellyfin Websockets traffic
        proxy_pass http://$jellyfin:8096;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
    }
  }

These common fixes didn't work for my issue

• I have tried removing/destroying my container, and re-creating a new container
• I have tried fresh volume data by backing up and moving/removing the old volume data
• I have tried running the stock docker run example(s) in the readme (removing any customizations I added)
• I have tried a newer or older version of Docker Pi-hole (depending what version the issue started in for me)
• I have tried running without my volume data mounts to eliminate volumes as the cause

If the above debugging / fixes revealed any new information note it here.
Add any other debugging steps you've taken or theories on root cause that may help.

[istrait]

I am having the same issue on a synology server.

Discovered that it was not on the right network in Synology to be reachable. I can now get to it.

[yubiuser]

I think this is related pi-hole/FTL#2319

[AliveDevil]

Same here, with

Details

podman run \
	--rm \
	--replace \
	-d \
	--name pihole \
	--env FTLCONF_webserver_api_password='' \
	--ip 10.88.0.5 \
	--publish 80:80 \
	--publish 5353:53/udp \
	--publish 5353:53/tcp \
	--health-cmd none \
	--label io.containers.autoupdate=registry \
	--volume /etc/localtime:/etc/localtime:ro \
	--volume /root/pihole/pihole:/etc/pihole \
	--volume /root/pihole/dnsmasq:/etc/dnsmasq.d ghcr.io/pi-hole/pihole:latest

pi.hole doesn't resolve.

dns.reply.host.force4=true
dns.reply.host.IPv4=172.17.17.4
dns.piholePTR=pi.hole
dns.listeningMode=single
dns.interface=eth0

The web interface on http://hostname:80/admin does work though.

[yubiuser]

@AliveDevil pleas do not hijack other issues if your are not sure if they are really the same.

The OP uses a reverse proxy to access the web ui but you did not indicate such a setup. I moved your post to a new issue.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.