[Bug] Pi-hole v6 widget returns 401 for second Pi-hole instance – invalid X-FTL-SID

[battle566]

Description

Hi everyone.

I have two identical Pi-hole v6 installations on 2 different units monitored by the same Homepage v2.1.1 instance.

Description

The Pi-hole widget works correctly for Pi-hole #1 but Pi-hole #2 consistently fails with:

API Error: Pi-Hole API Error

Environment

Homepage

Version: v2.1.1
Image: ghcr.io/gethomepage/homepage:latest
Revision: 21bf7ed

Both Pi-hole installations
Core: v6.4.3
Web: v6.6
FTL: v6.7

Both are running:
mpgirro/pihole-unbound:latest
Configuration

Working Pi-hole:

- Pi-Hole:
    href: https://pihole1.myserver.com/admin/
    icon: pi-hole.png
    server: localdocker
    container: pihole-unbound_v6
    widget:
        type: pihole
        url: https://pihole1.myserver.com
        version: 6
        key: <password> [I tested both admin password and api password; both work for me]

Failing Pi-hole:

- Pi-Hole:
    href: https://pihole2.myserver.com/admin/
    icon: pi-hole.png
    server: thinkcentre
    container: pihole-unbound_v6-2
    widget:
        type: pihole
        url: https://pihole2.myserver.com/admin/
        version: 6
        key: <password> [I tested both admin password and api password; both don't work]

The Docker container names are different, so there is no container-name collision.

What I have tested

The Pi-hole #2 API works correctly independently of Homepage.

Authentication:

curl -s -X POST "https://pihole2.myserver.com/api/auth" \
  -H "Content-Type: application/json" \
  -d '{"password":"<password>"}'

returns:

{
  "session": {
    "valid": true,
    "totp": false,
    "sid": "...",
    "csrf": "...",
    "validity": 1800,
    "message": "password correct"
  }
}

Using that SID:

curl -s \
  -H "X-FTL-SID: <valid-sid>" \
  "https://pihole2.myserver.com/api/stats/summary"

also works correctly.

Traefik → Pi-hole #2 also works:

docker exec traefik wget -qO- \
  http://pihole-unbound_v6-2/api/auth

returns the expected 401 because no authentication is supplied, confirming the request reaches Pi-hole correctly.

Pi-hole API debug output

I enabled:

debug.api = true

and inspected the Pi-hole FTL logs while Homepage was requesting the widget.

Pi-hole successfully processes requests using a valid cookie session:

Read sid="isthisevenascret" from cookie
Recognized known user: user_id 0
Processing GET /api/stats/summary
Done

However, Homepage subsequently sends a different SID through the HTTP header:

Requested API URI: 172.18.0.3 -> GET /api/stats/summary
Read sid="isthisevenascret=" from header
API Authentication: FAIL (session unknown)
API: Unauthorized (key: unauthorized)

So Pi-hole is explicitly reporting that the SID supplied by Homepage is unknown.

Additional test

I completely deleted and recreated the Homepage container to eliminate a stale in-memory session/cache:

docker rm -f homepage-proxy

and redeployed the Portainer stack.

The problem persists unchanged.

Interesting observation

If I swap the two widget configurations, the result follows the Pi-hole:

server#1 → Pi-hole #1 → works
server#2 → Pi-hole #2 → 401
server#2 → Pi-hole #1 → 401
server#1 → Pi-hole #2 → works

Therefore this does not appear to be related to the Docker container name, Docker network, Traefik routing, or the server: configuration.

It appears to be related to how Homepage handles the Pi-hole v6 API session/SID for this second Pi-hole instance.

homepage version

v2.1.1

Installation method

Docker

Configuration

service.yaml- Pi-Hole:
    href: https://pihole1.myserver.com//admin/
    icon: pi-hole.png
    server: localdocker
    container: pihole-unbound_v6
    widget:
        type: pihole
        url: https://pihole1.myserver.com/
        version: 6
        key: <password>
- Pi-Hole:
    href: https://pihole2.myserver.com/admin/
    icon: pi-hole.png
    server: thinkcentre
    container: pihole-unbound_v6-2
    widget:
        type: pihole
        url: https://pihole2.myserver.com/
        version: 6
        key: <password>

docker compose: 
services:
  dockerproxy:
    image: ghcr.io/tecnativa/docker-socket-proxy:latest
    container_name: dockerproxy
    environment:
      - CONTAINERS=1 # Allow access to viewing containers
      - SERVICES=1 # Allow access to viewing services (necessary when using Docker Swarm)
      - TASKS=1 # Allow access to viewing tasks (necessary when using Docker Swarm)
      - POST=0 # Disallow any POST operations (effectively read-only)
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro # Mounted as read-only
    healthcheck:
      test: wget --spider http://localhost:2375/version || exit 1
      interval: "30s"
      timeout: "5s"
      retries: 3
      start_period: "30s"
    networks: 
      - homepage_dockerproxy_net
    restart: unless-stopped 
  
  homepage-proxy:
    image: ghcr.io/gethomepage/homepage:latest
    container_name: homepage-proxy
    depends_on:
      dockerproxy:
        condition: service_healthy
    volumes:
      - /home/holger/homepage/config:/app/config
      - /media/holger/PortableSSD:/storage:ro
      - /media/holger/PortableSSD1:/storage1:ro
      - /home/holger/homepage/images:/app/public/images
    ports:
      - 3000:3000
    environment:
      - HOMEPAGE_ALLOWED_HOSTS=*
      - PUID:1000
      - PGID:1000
      - DNS:192.168.1.100
    labels:
        - traefik.enable=true
    networks: 
        - homepage_dockerproxy_net
        - traefik_net
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://127.0.0.1:3000"]
      interval: 30s
      timeout: 10s
      retries: 5
    restart: unless-stopped 

networks:
  homepage_dockerproxy_net:
    name: homepage_dockerproxy_net
  traefik_net:
    external: true

Container Logs

error: Error calling Pi-Hole API: 401. Data: {"error":{"key":"unauthorized","message":"Unauthorized","hint":null},"took":4.2676925659179688e-05}

Browser Logs

No response

Troubleshooting

I performed the recommended checks:

1. Checked homepage.log and Docker logs.
2. Checked the browser developer console.
3. Verified that Homepage can reach the Pi-hole instance.
4. Verified DNS resolution and connectivity from the Docker environment.
5. Tested the Pi-hole API directly with curl.
6. Tested authentication against /api/auth directly.
7. Tested an authenticated /api/stats/summary request using the returned X-FTL-SID.
8. Verified that the Pi-hole API works correctly independently of Homepage.
9. Verified the Pi-hole versions are identical on both instances.
10. Changed the Pi-hole API password on both instances.
11. Verified the Pi-hole configuration is synchronized using Nebula Sync.
12. Tested both Pi-hole configurations from both Homepage server groups. The problem follows Pi-hole ELIFECYCLE  Command failed. #2, not the Docker container name or Homepage server configuration.
13. Removed and recreated the Homepage container to eliminate a stale in-memory session as a possible cause. The problem persists.

The Pi-hole debug log provides the most relevant evidence. Pi-hole successfully accepts a valid session via cookie, but when Homepage sends its X-FTL-SID header, Pi-hole reports:

Read sid="..." from header
API Authentication: FAIL (session unknown)
API: Unauthorized (key: unauthorized)

Therefore the Pi-hole API itself is reachable and functional, but Homepage appears to be sending an X-FTL-SID that is unknown to the Pi-hole instance.

[shamoon]

LLMs sometimes miss the obvious. The support template actually points to https://gethomepage.dev/troubleshooting/#service-widget-errors , see the second item.

[battle566]

Thanks for pointing me to the right answer. I couldn't figure that one out. Strangly I have other widgets that also have the same name point to 2 different servers and it is not a problem there (e.g. portainer, traefik, watcher. any Thanks again.

[github-actions[bot]]

This discussion has been automatically closed because it was marked as answered. See our contributing guidelines for more details.