After updating to v6, after every container version update, unable to log in using existing cookies/password

[evulhotdog]

This is a: Bug

Details

Every time that the container is updated, after trying to reauthenticate with pihole or using existing cookies it fails to log me in. I am required to clear cookies for some reason. This did not occur in v5.

If I manually remove the cookies from my browser for the ip:port of pihole, it works fine.

Related Issues

• 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: docker
• Hardware: virtual machine
• Kernel Architecture: x86/amd64
• Docker Install Info and version:
  • Software source: ghcr.io/pi-hole/pihole:2025.02.4
  • Supplimentary Software:
• Hardware architecture: x86

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pihole
  namespace: default
  labels:
    app: pihole
spec:
  replicas: 1
  selector:
    matchLabels:
      app: pihole
  template:
    metadata:
      labels:
        app: pihole
    spec:
      containers:
      - name: pihole
        image: ghcr.io/pi-hole/pihole:2025.02.4
        imagePullPolicy: Always
        securityContext:
          capabilities:
            add: ["SYS_NICE"]

        livenessProbe:
          httpGet:
            scheme: HTTP
            path: /admin/
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 30
          timeoutSeconds: 5
          failureThreshold: 3

        resources:
          requests:
            memory: 100Mi
            cpu: "10m"

        env:
        - name: TZ
          value: "America/New_York"
        - name: FTLCONF_webserver_api_password
          valueFrom:
           secretKeyRef:
             name: pihole
             key: password

        # Sets upstream DNS servers
        - name: FTLCONF_dns_upstreams
          value: 10.0.10.1

        # Disable rate limiter
        - name: FTLCONF_dns_rateLimit_count
          value: "0"
        - name: FTLCONF_dns_rateLimit_interval
          value: "0"

        # Allows more than just the local subnet to use the resolver.
        - name: FTLCONF_dns_listeningMode
          value: "all"

        ports:
        - containerPort: 80

        volumeMounts:
        - name: etc-pihole
          mountPath: /etc/pihole
        - name: etc-dnsmasq-d
          mountPath: /etc/dnsmasq.d
        - name: dshm
          mountPath: /dev/shm

      volumes:
        - name: etc-pihole
          persistentVolumeClaim:
            claimName: pvc-pihole-etc-pihole
        - name: etc-dnsmasq-d
          persistentVolumeClaim:
            claimName: pvc-pihole-etc-dnsmasq-d
# Pi-hole runs into some limit on the default image.
# https://www.reddit.com/r/pihole/comments/zgm48b/pihole_reporting_ram_shortage_when_there_is/
# Fix: https://stackoverflow.com/questions/43373463/how-to-increase-shm-size-of-a-kubernetes-container-shm-size-equivalent-of-doc
        - name: dshm
          emptyDir:
            medium: Memory
            sizeLimit: 500Mi

3. any additional info to help reproduce

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.

[PromoFaux]

@evulhotdog - will try to look at this later - though I am unable to reproduce your issue, I have seen someone else on our forums mention something similar

[rdwebdesign]

@evulhotdog

Does the issue happen if you try to set the password directly on the compose file, like this?

      env:
        TZ: "America/New_York"
        FTLCONF_webserver_api_password: "my_secret_password"

[PREngineer]

Maybe it is good to specify: I am using Brave and it tends to block scripts and some security concerns.

I have a similar issue.

When trying to log in, if I input the wrong password, it tells me that I have to change it with the command.

If I input the right password it goes back to the login page.

If I clear all website data in the Developer Console (F12) > Application. It then logs in properly.

[PromoFaux]

All - I don't suppose you happen to be using nebula-sync?

lovelaze/nebula-sync#44

[rubenvandeven]

I ran into the same issue. It turned out another service on another port at the same host issues an "SID" cookie. While pi-hole uses "sid" (lowercase) for its session ID, and cookies should be case sensitive, it still seems to cause confusion during authentication. This issue can be resolved easily if there's a way to configure/prefix the session id cookie so that is less generic.

@PREngineer @evulhotdog can you confirm that you have a similar cookie set, and that removing only that one cookie fixes the issue for you? If so, we can file an issue at pi-hole/web for a more unique name for the session cookie.

Edit: or rather, it should be filed in the pi-hole/FTL repo. I.e. here and here.

[PromoFaux]

Cookies are also per-domain. If you use the built-in hostname to access the web interface (http://pi.hole/admin) you should not get this clash.

Similar situation here: https://old.reddit.com/r/pihole/comments/1j3gtz3/pihole_ftl_v604_web_v602_and_core_v605_released/mg0npq5/

[rubenvandeven]

Yes indeed. They're not isolated per port, only per host.

I didn't know the pi.hole trick. Good one! Nevertheless, with the "bridge" network mode (as per default configuration), the IP it returns is one internal to Docker (172.27.0.2) which I cannot access on the network. But that falls outside of the scope of this issue.

The quick work around then is to a create custom hostname (Settings -> Local DNS Records) and use that to access the web admin.

[PromoFaux]

it returns is one internal to Docker (172.27.0.2)

You can also use a combination of dns.reply.host.force4, to enable. and dns.reply.host.IPv4 to set a custom IP address for pi.hole

e.g:

[evulhotdog]

I will update everyone after the next update if it continues to occur.

I will test it both with my current DNS, and pi.hole.

• I will log in both in on my own DNS (which is shared between other services on a different port)
• Update the k8s manifest
• Try logging in again to see behavior

Same for pi.hole fqdn.

[PREngineer]

I ran into the same issue. It turned out another service on another port at the same host issues an "SID" cookie. While pi-hole uses "sid" (lowercase) for its session ID, and cookies should be case sensitive, it still seems to cause confusion during authentication. This issue can be resolved easily if there's a way to configure/prefix the session id cookie so that is less generic.

@PREngineer @evulhotdog can you confirm that you have a similar cookie set, and that removing only that one cookie fixes the issue for you? If so, we can file an issue at pi-hole/web for a more unique name for the session cookie.

Edit: or rather, it should be filed in the pi-hole/FTL repo. I.e. here and here.

I can't see another cookie. The sid is a random set of characters.