Unable to load configuration after fresh install or upgrade to v6

[evulhotdog]

This is a: Run Issue (running Pi-hole container failing)

Details

When upgrading from 2024.07.0 or running a clean install, pihole is unable to save changes or run properly due to not being able to obtain exclusive mode on a config file.

From a clean install, I'm able to get it running, then I try to save a config and it fails to reload and all services cease to function.

2025-02-18 22:45:57.650 EST [137M] ERROR: Cannot open config file /etc/pihole/pihole.toml in exclusive mode (r): Bad file descriptor
2025-02-18 22:45:57.661 EST [141M] ERROR: Cannot open config file /etc/pihole/pihole.toml in exclusive mode (r): Bad file descriptor
2025-02-18 22:45:57.671 EST [145M] ERROR: Cannot open config file /etc/pihole/pihole.toml in exclusive mode (r): Bad file descriptor

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: Ubuntu
• Hardware: Virtual Machine running k3s
• Kernel Architecture: amd64
• Docker Install Info and version:
  • Software source: ghcr.io/pi-hole/pihole:2024.07.0
  • Supplimentary Software: k3s
• 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.1
        imagePullPolicy: Always

        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

        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

4. any additional info to help reproduce
   The dirs and files are all owned by pihole (1000:1000) so it does not appear to be a permissions issue.

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.

[djgaven588]

Experiencing the same issue with an upgrade to v6.

My volumes are all bound from network locations (ntfs4). Permissions are read, write, and execute, but I doubt it can get an exclusive lock on a config file (why would it even need to do that?).

volumes:
  serveretc:
    driver_opts:
      type: nfs4
      o: addr=192.168.0.8
      device: :/mnt/Stornado2/ServerData/PiHole/etc
  serverdnsmasq:
    driver_opts:
      type: nfs4
      o: addr=192.168.0.8
      device: :/mnt/Stornado2/ServerData/PiHole/etc-dnsmasq.d

[evulhotdog]

@djgaven588 I am also mounting them via NFS, and from past experience, I don't think NFS supports file locking in the same way that other standard mounted filesystems do, so it feels like we're on the right path.

[vincentDcmps]

same issue with nfs volume, when I remove volume everything works correctly