pi-hole / docker-pi-hole

Pi-hole in a docker container
https://pi-hole.net
Other
8.52k stars 1.13k forks source link

Error when whitelisting domain: While executing INSERT OT IGNORE: attempt to write a readonly database Added 0 out of 1 domains #751

Closed ericlathrop closed 2 years ago

ericlathrop commented 3 years ago

Versions

Platform

Expected behavior

I went to https://.../admin/groups-domains.php?type=white, filled out a domain, and pushed the button. I expected the domain to be added to the whitelist.

Actual behavior / bug

A red error message popped up in the upper-right corner of the page with this message: While executing INSERT OT IGNORE: attempt to write a readonly database Added 0 out of 1 domains

Steps to reproduce

Steps to reproduce the behavior:

  1. Go to /admin/groups-domains.php?type=white in the web admin
  2. Enter a domain in the text box
  3. Click the "add to whitelist" button
  4. See error

Additional Context

Whitelisting the same domain with the pihole -w command worked fine.

dschaper commented 3 years ago

And can you provide the docker run commands you are using? What volume mounts do you have set up?

ericlathrop commented 3 years ago

I use Ansible to spin up the docker container, so I'm not sure of the exact command it generates, but my Ansible config looks like this:

- name: Install Pi-hole docker container
  docker_container:
    dns_servers:
      - 127.0.0.1
      - 1.1.1.1
      - 1.0.0.1
    env:
      DNS1: 1.1.1.1
      DNS2: 1.0.0.1
      TZ: "America/New_York"
      VIRTUAL_HOST: pihole.xxx.xxx
    image: pihole/pihole:v5.2.2
    labels:
      traefik.docker.network: web
      traefik.enable: "true"
      traefik.http.services.pihole.loadbalancer.server.port: "80"
      traefik.http.routers.pihole.rule: Host(`pihole.xxx.xxx`)
      traefik.http.routers.pihole.tls: "true"
      traefik.http.routers.pihole.tls.certresolver: leresolver
    name: pihole
    networks:
      - name: web
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8053:80"
    restart_policy: always
    volumes:
       - /home/pihole/pihole:/etc/pihole
       - /home/pihole/dnsmasq.d:/etc/dnsmasq.d
  notify:
    - Restart Pi-hole
dschaper commented 3 years ago

Inside the container can you list the /etc/pihole directory please? I'm checking to see if the lighttpd daemon's user has the permissions to modify the *.db files.

ericlathrop commented 3 years ago
# ls -l /etc/pihole/
total 410280
-rw-r--r-- 1 root   root          20 Jan  6 12:22 GitHubVersions
-rw-r--r-- 1 root   root         118 Nov 27 20:24 adlists.list
-rw-r--r-- 1 root   root           0 Nov 30 12:16 custom.list
-rw-r--r-- 1 root   root         618 Jan  4 16:45 dns-servers.conf
-rw-rw-r-- 1 pihole pihole   5132288 Jan  6 14:32 gravity.db
-rw-r--r-- 1 root   root     1172708 Jan  4 16:46 list.1.raw.githubusercontent.com.domains
-rw-r--r-- 1 root   root      594616 Nov 30 12:16 list.2.mirror1.malwaredomains.com.domains
-rw-r--r-- 1 root   root          37 Jan  4 16:46 local.list
-rw-r--r-- 1 root   root          20 Jan  6 16:50 localbranches
-rw-r--r-- 1 root   root          44 Jan  6 16:50 localversions
drwxr-xr-x 1 root   root          24 Nov 27 20:24 migration_backup
-rw-r--r-- 1 pihole pihole         0 Nov 27 20:24 pihole-FTL.conf
-rw-r--r-- 1 root   root   413188096 Jan  6 16:53 pihole-FTL.db
-rw-r--r-- 1 root   root         510 Jan  4 16:45 setupVars.conf
-rw-r--r-- 1 root   root         510 Jan  4 16:45 setupVars.conf.update.bak
ericlathrop commented 3 years ago

Looks like the webserver runs as www-data:

# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0    196     4 ?        Ss   Jan04   0:00 s6-svscan -t0 /var/run/s6/services
root          34  0.0  0.0    196     4 ?        S    Jan04   0:00 s6-supervise s6-fdholderd
root         736  0.0  0.0    196     4 ?        S    Jan04   0:00 s6-supervise cron
root         737  0.0  0.0    196     4 ?        S    Jan04   0:00 s6-supervise pihole-FTL
root         738  0.0  0.0    196     4 ?        S    Jan04   0:00 s6-supervise lighttpd
root         740  0.0  0.0   3732  2768 ?        Ss   Jan04   0:00 bash ./run
root         741  0.0  0.0   3732  2892 ?        Ss   Jan04   0:00 bash ./run
root         742  0.0  0.0   3732  2776 ?        Ss   Jan04   0:00 bash ./run
root         752  0.0  0.0 400824 24240 ?        Sl   Jan04   2:45 pihole-FTL no-daemon
www-data     753  0.0  0.0  14896  7388 ?        S    Jan04   0:05 lighttpd -D -f /etc/lighttpd/lighttpd.
root         754  0.0  0.0   5304  2260 ?        S    Jan04   0:00 /usr/sbin/cron -f
www-data     766  0.0  0.0 197672 21404 ?        Ss   Jan04   0:00 /usr/bin/php-cgi
www-data     769  0.0  0.0 198132 17116 ?        S    Jan04   0:00 /usr/bin/php-cgi
www-data     770  0.0  0.0 198084 17328 ?        S    Jan04   0:00 /usr/bin/php-cgi
www-data     771  0.0  0.0 198080 16924 ?        S    Jan04   0:00 /usr/bin/php-cgi
www-data     772  0.0  0.0 198132 17208 ?        S    Jan04   0:00 /usr/bin/php-cgi
root       85753  0.0  0.0   3988  3304 pts/0    Ss   16:53   0:00 bash
root       85786  0.0  0.0   7636  2720 pts/0    R+   16:54   0:00 ps aux
dschaper commented 3 years ago

Yes, and we typically have an /etc/sudoers.d/pihole file that grants www-data access to use the pihole command.

I note that your pihole-FTL.db is owned by root. Normally that is owned by pihole, matching gravity.db.

ericlathrop commented 3 years ago

FWIW I don't think I've ever personally changed owner/permissions on any of the Pihole volumes/files. I started the container as a normal user.

dschaper commented 3 years ago

Ah, appears that root is indeed running the commands inside the container, so the permissions look okay...

dschaper commented 3 years ago

I just spun up a test and I'm not able to reproduce. If the pihole cli command works then it's something in the web daemon. It basically calls pihole -w directly.

There may be something in the reverse proxy configuration, normally that would come across as a CORS violation, but that looks like the only real difference between the test setup and your setup.

ericlathrop commented 3 years ago

The AJAX request to add to the whitelist looks successful, and returns a 200: {"success":false,"message":"While executing INSERT OT IGNORE: <strong>attempt to write a readonly database<\/strong><br>Added 0 out of 1 domains","0":{"action":"add_domain"}} The Firefox dev tools don't show any CORS error.

ericlathrop commented 3 years ago

Does the web service enter a password when it sudos? If I change to www-data and run pihole -w I get a password prompt:

# sudo -u www-data bash
$ pihole -w test.google.com

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for www-data: 

I'd normally expect that either the pihole command would be setuid root, or the sudo would be passwordless.

dschaper commented 3 years ago

In the container do a cat /etc/sudoers.d/pihole and it will show exactly what is being done.

ericlathrop commented 3 years ago

That file has this line: www-data ALL=NOPASSWD: /usr/local/bin/pihole which should make it passwordless, but it doesn't seem to be working because it's still asking for a password.

dschaper commented 3 years ago

Only /usr/local/bin/pihole is passwordless.

sudo -u www-data /usr/local/bin/pihole -v

edgd1er commented 3 years ago

@ericlathrop ,

I guess this is a right access problem. I faced a similar problem with acl. (could happen also with SMB/CIFS) As a temporary solution you may add www-data to pihole group. So lightttpd with pihole group rights will be able to open a read write access to the sqlite database.

usermod -a -G pihole www-data

if ever ACL are enforce on your system, you could check rights with :getfacl *.db

ericlathrop commented 3 years ago

I ran

chown pihole.pihole pihole-FTL.db
chmod 664 pihole-FTL.db

to make the permissions match gravity.db, but still get the same error.

ericlathrop commented 3 years ago

Oh, after restarting the pihole container, the permissions changes worked, and fixed the error.

I guess the real bug is that something set the permissions incorrectly on pihole-FTL.db.

jakev383 commented 3 years ago

I'm encountering what I think is the same issue. New spin-up of pihole. Here's my docker-compose: ` pihole:

container_name: pihole
image: pihole/pihole:latest
ports:
  - "53:53"
  - "81:80"
  - "1443:443"
environment:
  - TZ:${TZ}
  - WEBPASSWORD=something
  - SERVERIP=192.168.6.6
# Volumes store your data between container upgrades
volumes:
  - ${USERDIR}/docker/pihole/etc:/etc/pihole
  - ${USERDIR}/docker/pihole/dnsmaqs.d:/etc/dnsmasq.d
restart: unless-stopped`

$USERDIR is defined as /home/pi/docker $TZ is defined as America/New_York Once the newly created container was created, I logged in and tried to add a adlist and got the error.

root@35b5911025f2:/# ls -l /etc/pihole
total 4708
-rw-r--r--+ 1 root   root         2 Jan 27 15:39 GitHubVersions
-rw-rw-r--+ 1 root   root        65 Jan 27 15:56 adlists.list
-rw-r--r--  1 root   root       716 Jan 27 15:44 custom.list
-rw-r--r--+ 1 root   root       618 Jan 27 15:56 dns-servers.conf
-rw-rw-r--+ 1 pihole pihole 3514368 Jan 27 15:56 gravity.db
-rw-r--r--+ 1 root   root   1207713 Jan 27 15:56 list.1.raw.githubusercontent.com.domains
-rw-r--r--+ 1 root   root        37 Jan 27 15:56 local.list
-rw-r--r--+ 1 root   root        20 Jan 27 16:10 localbranches
-rw-r--r--+ 1 root   root        50 Jan 27 16:10 localversions
drwxrwxr-x+ 2 root   root      4096 Jan 27 15:39 migration_backup
-rw-r--r--  1 pihole pihole       0 Jan 27 15:39 pihole-FTL.conf
-rw-r--r--+ 1 root   root     53248 Jan 27 16:10 pihole-FTL.db
-rw-rw-r--+ 1 root   root       466 Jan 27 15:56 setupVars.conf
-rw-rw-r--+ 1 root   root       466 Jan 27 15:56 setupVars.conf.update.bak

I tried running these in the container, but even after restarting the container it still gives the error: chown pihole.pihole pihole-FTL.db chmod 664 pihole-FTL.db Also verified that after restarting container the permissions:

root@35b5911025f2:/# ls -l /etc/pihole
total 4708
-rw-r--r--+ 1 root   root         2 Jan 27 15:39 GitHubVersions
-rw-rw-r--+ 1 root   root        65 Jan 27 15:56 adlists.list
-rw-r--r--  1 root   root       716 Jan 27 15:44 custom.list
-rw-r--r--+ 1 root   root       618 Jan 27 16:14 dns-servers.conf
-rw-rw-r--+ 1 pihole pihole 3514368 Jan 27 16:14 gravity.db
-rw-r--r--+ 1 root   root   1207713 Jan 27 16:14 list.1.raw.githubusercontent.com.domains
-rw-r--r--+ 1 root   root        37 Jan 27 16:14 local.list
-rw-r--r--+ 1 root   root        20 Jan 27 16:14 localbranches
-rw-r--r--+ 1 root   root        50 Jan 27 16:14 localversions
drwxrwxr-x+ 2 root   root      4096 Jan 27 15:39 migration_backup
-rw-r--r--  1 pihole pihole       0 Jan 27 15:39 pihole-FTL.conf
-rw-rw-r--+ 1 pihole pihole   53248 Jan 27 16:17 pihole-FTL.db
-rw-rw-r--+ 1 root   root       466 Jan 27 16:14 setupVars.conf
-rw-rw-r--+ 1 root   root       466 Jan 27 16:14 setupVars.conf.update.bak
jakev383 commented 3 years ago

I did some more testing - I tried removing the persistent volumes and the problem went away. Added them back, and encountered the issue. Moved the persistent maps one dir up (pi's homedir at /home/pi) then the problem went away as well. For now I've left it there since I need the functionality but it would be nice to understand why moving it to /home/pi/docker causes the failure in the container.

fermulator commented 3 years ago

duplicate of #610 ?

radicand commented 3 years ago

I'm encountering this in a Kubernetes setup using a nfs mount (no squash, etc) as well. If I chgrp /etc/pihole and /etc/pihole/* to group writable and group = www-data, then everything works. On pod restart the permissions get reset again however. What baffles me is that the www-data user is part of the pihole group, so it should work in theory, but it just doesn't in practice.

grizo commented 3 years ago

have a similar issue as @radicand while finally getting around to learning k8s and having nfs as pv. observation in the container when adding an adlist and tailing various logs:

==> lighttpd/access.log <==
1613366915|192.168.0.60|POST /admin/scripts/pi-hole/php/groups.php HTTP/1.1|200|157

==> lighttpd/error.log <==
2021-02-15 05:28:35: (mod_fastcgi.c.421) FastCGI-stderr: PHP Warning:  SQLite3Stmt::execute(): Unable to execute statement: attempt to write a readonly database in /var/www/html/admin/scripts/pi-hole/php/groups.php on line 954
^C
root@pihole-6995fcdb6f-lcxlv:/var/log# ls -al lighttpd/
total 32
drwxr-x--- 1 www-data www-data  4096 Feb 15 05:25 .
drwxr-xr-x 1 root     root      4096 Feb 15 05:25 ..
-rw-r--r-- 1 www-data www-data 13004 Feb 15 05:28 access.log
-rw-r--r-- 1 www-data www-data  2935 Feb 15 05:28 error.log
root@pihole-6995fcdb6f-lcxlv:/var/log# sudo ps aux|grep lighttpd
root         510  0.0  0.0    192     4 ?        S    05:25   0:00 s6-supervise lighttpd
www-data     525  0.0  0.1  11036  5856 ?        S    05:25   0:00 lighttpd -D -f /etc/lighttpd/lighttpd.conf
root         675  0.0  0.0   2824   680 pts/0    S+   05:29   0:00 grep lighttpd
root@pihole-6995fcdb6f-lcxlv:/var/log# ls -al /etc/pihole/
total 4792
drwxrwxr-x 3 nobody nogroup    4096 Feb 15 05:29 .
drwxr-xr-x 1 root   root       4096 Feb 15 05:25 ..
-rw-r--r-- 1 nobody nogroup      18 Feb 15 05:25 GitHubVersions
-rw------- 1 nobody nogroup       0 Feb 15 05:24 custom.list
-rw-r--r-- 1 nobody nogroup     618 Feb 15 05:25 dns-servers.conf
-rw-rw-r-- 1 nobody nogroup 3575808 Feb 15 05:25 gravity.db
-rw-r--r-- 1 nobody nogroup 1230793 Feb 15 05:25 list.1.raw.githubusercontent.com.domains
-rw-r--r-- 1 nobody nogroup      48 Feb 15 05:25 local.list
-rw-r--r-- 1 nobody nogroup      13 Feb 15 05:25 localbranches
-rw-r--r-- 1 nobody nogroup      23 Feb 15 05:25 localversions
drwxr-xr-x 2 nobody nogroup    4096 Feb 15 05:25 migration_backup
-rw-r--r-- 1 nobody nogroup       0 Feb 15 05:24 pihole-FTL.conf
-rw-r--r-- 1 nobody nogroup   53248 Feb 15 05:29 pihole-FTL.db
-rw-r--r-- 1 nobody nogroup     261 Feb 15 05:25 setupVars.conf
-rw-r--r-- 1 nobody nogroup       0 Feb 15 05:25 setupVars.conf.update.bak

k8s yaml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pihole-config
  labels:
    type: nfs
spec:
  capacity:
    storage: 512Mi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
    path: /var/nfs/k8s/pihole/config
    server: 192.168.0.3

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pihole-config
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 512Mi

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pihole-dnsmasq
  labels:
    type: nfs
spec:
  capacity:
    storage: 32Mi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
    path: /var/nfs/k8s/pihole/dnsmasq
    server: 192.168.0.3

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pihole-dnsmasq
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 32Mi

---

apiVersion: v1
kind: Service
metadata:
  name: pihole-ui
  labels:
    app: pihole
  annotations:
    metallb.universe.tf/allow-shared-ip: pihole-svc
spec:
  type: LoadBalancer
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: http
  selector:
    app: pihole

---

apiVersion: v1
kind: Service
metadata:
  name: pihole-dns-udp
  labels:
    app: pihole
  annotations:
    metallb.universe.tf/allow-shared-ip: pihole-svc
spec:
  type: LoadBalancer
  ports:
    - name: udp
      protocol: UDP
      port: 53
  selector:
    app: pihole

---

apiVersion: v1
kind: Service
metadata:
  name: pihole-dns-tcp
  labels:
    app: pihole
  annotations:
    metallb.universe.tf/allow-shared-ip: pihole-svc
spec:
  type: LoadBalancer
  ports:
    - name: tcp
      protocol: TCP
      port: 53
  selector:
    app: pihole

---

kind: Deployment
apiVersion: apps/v1
metadata:
  name: pihole
  labels:
    app: pihole
spec:
  replicas: 1
  selector:
    matchLabels:
      app: pihole
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: pihole
    spec:
      containers:
        - name: pihole
          image: pihole/pihole:v5.6
          volumeMounts:
          - mountPath: '/etc/pihole/'
            name: pihole-config
          - mountPath: '/etc/dnsmasq.d/'
            name: pihole-dnsmasq
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
            - name: dns
              containerPort: 53
              protocol: TCP
            - name: dns-udp
              containerPort: 53
              protocol: UDP
          env:
            - name: WEB_PORT
              value: '80'
            - name: WEBPASSWORD
              valueFrom:
                secretKeyRef:
                  name: pihole-secret
                  key: password
            - name: VIRTUAL_HOST
              value: pi.hole
            - name: DNS1
              value: 208.67.222.222
            - name: DNS2
              value: 9.9.9.9
            - name: IPv6
              value: 'false'
      volumes:
        - name: pihole-config
          persistentVolumeClaim:
            claimName: pihole-config
        - name: pihole-dnsmasq
          persistentVolumeClaim:
            claimName: pihole-dnsmasq
grizo commented 3 years ago

@radicand have this working with pihole/pihole:v5.7 and the following updated nfs export options: rw,no_subtree_check,no_root_squash

have been able to add adlists and whitelist so far with out issues. as well as perform an update gravity.

ericlathrop commented 3 years ago

I had fixed the permissions back on 1/8/2021, but when I went to edit the whitelist yesterday, the permissions were wrong again. Some unknown process must be chowning them periodically. FWIW, I made pihole users/groups, and have the docker volumes under /home/pihole/... so nothing else on my server should be messing with the permissions.

isaacrlevin commented 3 years ago

Currently no workarounds in this thread resolve the issue. I have tried so many different variations of perm changes and none make the error go away. Even tried without a reboot

scott-ainsworth commented 3 years ago

I also have this issue--but, on one of my two pihole installations. Both are running the same version of pihole, the docker-compose.yaml files are identical, and file and folder permissions are too. As far as I can tell, the two installations are indentical except for three things:

Whitelisting using the web interface fails on the PC and succeeds on the Raspberry Pi. pihole -w works on both.

The failure logs FastCGI-stderr: PHP Warning: SQLite3Stmt::execute(): Unable to execute statement: attempt to write a readonly database in /var/www/html/admin/scripts/pi-hole/php/groups.php on line 671 in lighttpd/error.log, which is an attempt update gravity.db.

At this time, I don't believe this is a problem with permissions on gravity.db itself. Why? Because changing permissions to 0666 (-rw-rw-rw-) does not fix it.

So, it looks like an environmental problem with the operating system or Docker. Right now I have no good next steps and would welcome others' insights.

beankylla commented 3 years ago

Hello,

I have the same issue. Also running docker in ubuntu 20.04

The "fix" until then for me is: access the pihole docker bash Run the command to fix the file rights

That fixes it for some time and then it "breaks" again.

No clue as to why. I can provide any documentation / logs needed.

Kind regards,

ANFADEV commented 3 years ago

I Solved the problem by updating the gravity lists from the ui (adress/admin/gravity.php) now i'm able to enable/disable my blocklist entries again

Before that i run:

sudo stat -c "%U:%G %a %n" /etc/pihole/* | column -t

and the results were correct:

root:root      644  /etc/pihole/adlists.list
root:root      644  /etc/pihole/custom.list
pihole:pihole  644  /etc/pihole/dhcp.leases
root:root      644  /etc/pihole/dns-servers.conf
root:root      644  /etc/pihole/GitHubVersions
pihole:pihole  664  /etc/pihole/gravity.db
root:root      644  /etc/pihole/install.log
root:root      644  /etc/pihole/list.1.raw.githubusercontent.com.domains
root:root      644  /etc/pihole/list.1.raw.githubusercontent.com.domains.sha1
root:root      644  /etc/pihole/list.2.raw.githubusercontent.com.domains.sha1
root:root      644  /etc/pihole/list.3.raw.githubusercontent.com.domains
root:root      644  /etc/pihole/list.3.raw.githubusercontent.com.domains.sha1
root:root      644  /etc/pihole/localbranches
root:root      644  /etc/pihole/local.list
root:root      644  /etc/pihole/localversions
root:root      644  /etc/pihole/logrotate
pihole:pihole  644  /etc/pihole/macvendor.db
root:root      755  /etc/pihole/migration_backup
pihole:root    664  /etc/pihole/pihole-FTL.conf
pihole:pihole  644  /etc/pihole/pihole-FTL.db
root:root      644  /etc/pihole/setupVars.conf

i run it again after the fix, and no change found even in permissions

I thought this might help

ANFADEV commented 3 years ago

Not running on docker though, but still it might help someone

davewatson91 commented 3 years ago

for those having issues: I ran the below and got it going. sudo chown 999:999 /etc/pihole -R

buxtronix commented 3 years ago

I resolved this by running chmod 777 /etc/pihole/ inside the container (i'm sure there's a more secure way of fixing this).

It seems that the PHP process is unable to write journal files in the directory. strace showed this:

openat(AT_FDCWD, "/etc/pihole/gravity.db-journal", O_RDWR|O_CREAT|O_LARGEFILE|O_CLOEXEC, 0666) = -1 EACCES (Permission denied)
danteali commented 3 years ago

Same issue. Using this workaround in my container startup script: docker exec pihole chown -R www-data:pihole /etc/pihole

I'm updating from v4.1.1 using a fresh install to new server folders. No permission issues on previous version.

And no idea what root cause is since I can run pihole without any mounted volumes and everything works fine but when I mount volumes it has the permission issues. Even though /etc/pihole/* looks identical from an ownership/group/permission perspective with or without mounted volumes.

Loriden commented 3 years ago

Same issue. Using this workaround in my container startup script: docker exec pihole chown -R www-data:pihole /etc/pihole

I'm updating from v4.1.1 using a fresh install to new server folders. No permission issues on previous version.

And no idea what root cause is since I can run pihole without any mounted volumes and everything works fine but when I mount volumes it has the permission issues. Even though /etc/pihole/* looks identical from an ownership/group/permission perspective with or without mounted volumes.

This worked for me - updated docker image using pihole:latest and compose....up -d, using templated compose file. Came from 4.4 to 5.6

shred86 commented 2 years ago

Noticing this issue on v5.6. I don’t know when it started happening but I tried adding a domain to the whitelist and this error popped up. I’ve attempted some of the recommendations in this thread but no luck. Running PiHole in a Docker container on a Debian host. I’m using Docker volumes for persistent storage which hasn’t ever been an issue in the past (I’ve added stuff to the whitelist in the past).

ChitoseRaame commented 2 years ago

Same issue. My device is Raspberry Pi 4B, the newly installed Debian 11, there is also a problem that the database cannot be added. This also affects the import configuration.

$ uname -a Linux [HostName] 5.10.0-9-arm64 #1 SMP Debian 5.10.70-1 (2021-09-30) aarch64 GNU/Linux

I used a temporary method to fix it:

docker exec pihole chmod -R 777 /etc/pihole

But I guess this isn't a good idea...

I'm sorry, my native language is not English.

PromoFaux commented 2 years ago

Closing to continue the discussion in #860 (which is now pinned while we attempt to look into it)

vamichael commented 2 years ago

sudo chown 999:999 /etc/pihole -R

Thanks!

madhu-GG commented 11 months ago

I can confirm that it is a permission issue with etc-pihole directory.

Reproduction steps:

This fixes any problems with adding domains or reading the black list.