Permissions incorrect on gravity.db and pihole-FTL.conf

[umpire7777777]

This is a...

• Request for a new or modified feature
• [ X] Issue trying to run the docker image
• Issue trying to build / test / develop the docker image

Description

Pi-hole builds and runs successfully. I am unable to add any whitelist or blacklist entries via the web admin page. I get this error: Error, something went wrong!
While executing: attempt to write a readonly database
Added 0 out of 1 domains

Expected Behavior

Whitelist or blacklist entry should be added to the database.

Actual Behavior

Possible Fix

Steps to Reproduce and debugging done

e.g. your docker run command, pages to visit, CLI commands you ran

1. Open Pihole admin page, login.
2. Go to whitelist page
3. Add entry to domain, click submit.

Debug steps I have tried

I know permissions are the issue. Permissions on the files are the same:
-rw-rw-r--+ 1 999 spi 4947968 May 10 03:31 gravity.db
-rw-r--r-- 1 999 spi 0 May 9 23:45 pihole-FTL.conf
All others are root:root
I'm using the persisted volumes as listed in the docs:
volumes:
- './etc-pihole/:/etc/pihole/'

Cannot determine what to add to docker-compose or what user/group changes are needed to enable this to work correctly. Stock raspberry buster install with docker-ce edition. No other users/groups have been added.

• [ X] I have tried destroying my container instance, pulling the newest image version, and re-creating a new container
• [ X] I have tried running the nearly stock docker run example in the readme (removing any customizations I added)
• I have tried running without my volume data mounts to eliminate volumes as the cause
• [ X] I have searched this repository for existing issues and pull requests that look similar

Context and extra information

Your Environment

• Docker Host Operating System and OS Version:
• Docker Version:
• Hardware architecture:
  raspeberry pi
  Linux raspberrypi 4.19.97-v7+ Can not add domains to white or black list latest as of 2023-01-21 10:00 MST #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux
  Docker version 19.03.8, build afacb8b

[jcputney]

Seeing the issue here as well, causing problems when starting the container. Getting the following error before the container stops:

2020-05-10T18:59:47.035459786Z /bash_functions.sh: line 338:   331 Bus error               (core dumped) sudo -u ${DNSMASQ_USER:-root} pihole-FTL test
2020-05-10T18:59:47.036414549Z ::: Testing pihole-FTL DNS: [cont-init.d] 20-start.sh: exited 1.
2020-05-10T18:59:47.042732477Z [cont-finish.d] executing container finish scripts...
2020-05-10T18:59:47.043636876Z [cont-finish.d] done.
2020-05-10T18:59:47.043885380Z [s6-finish] waiting for services.
2020-05-10T18:59:47.248144826Z [s6-finish] sending all processes the TERM signal.
^[[A^[[A2020-05-10T18:59:50.254077627Z [s6-finish] sending all processes the KILL signal and exiting.

[Panderine]

Same issue. Chowning all files to 999:999 doesn't seem to help. I believe is an issue with the webgui user and those files within docker.

EDIT: Ok this is indeed a file permission problem. I have /etc/pihole binded to host. Don't know why pihole-FTL.db gets reowned to root:root when I restart the container. It's supposed to be owned by pihole:pihole or at least www-data.

Also @jcputney, @umpire7777777 are you bind mounting /etc/pihole to host and using setfacl by any chance?

[Panderine]

the issue is, at least in my case, related to acl permissions to the /etc/pihole/pihole-FTL.db file and dirs. Tried mounting to different dir and worked without issues. Will report back how I fixed it with setfacl once I figure it out.

[Panderine]

ok fixed it giving permissions to each of the nodes with setfacl to rwx both user and group.

[umpire7777777]

@Panderine I'm only mounting this volume:
volumes:
- './etc-pihole/:/etc/pihole/'
I used and didn't use setfacl (tried both ways). Current config I am NOT using setfacl.
As a workaround, I added pi to the www-data group and www-data to the pi group.
The permissions still look the same on the files (999 spi) but it works now.

[Haarolean]

I think #328 is the real root cause of the problem.

[fermulator]

following an upgrade from v4.4 to v5.latest,

when i first stumbled over this, permissions were ALL OVER the place:

# ls -al
total 3275988
drwxrwxr-x+ 3 pihole pihole       4096 Jan 23 15:09 .
drwxr-xr-x  1 root   root         4096 Jan 23 15:08 ..
-rw-r--r--+ 1   1000 root           20 Jan 23 15:08 GitHubVersions
-rw-rw-r--+ 1 root   root            0 Jan 23 14:15 black.list
-rw-r--r--  1 root   root            0 Jan 23 15:08 custom.list
-rw-r--r--+ 1   1000 root          618 Jan 23 15:08 dns-servers.conf
-rw-rw-r--+ 1 pihole pihole    5001216 Jan 23 15:08 gravity.db
-rw-rw-r--+ 1 root   root      3116055 Jan 23 14:15 gravity.list
-rw-r--r--+ 1 root   root      1200087 Jan 23 15:08 list.1.raw.githubusercontent.com.domains
-rw-r--r--+ 1 root   root       412404 Jan 23 15:08 list.3.sysctl.org.domains
-rw-rwx---+ 1   1000 root        43616 Feb 22  2020 list.4.s3.amazonaws.com.domains
-rw-r--r--+ 1 root   root        43529 Jan 23 15:08 list.5.s3.amazonaws.com.domains
-rw-rwxr--+ 1   1000 root      3116087 Jan 23 14:15 list.preEventHorizon
-rw-r--r--+ 1   1000 root           37 Jan 23 15:08 local.list
-rw-r--r--+ 1   1000 root           20 Jan 23 15:20 localbranches
-rw-r--r--+ 1   1000 root           44 Jan 23 15:20 localversions
drwxrwxr-x+ 2 root   root         4096 Jan 23 15:08 migration_backup
-rw-r--r--+ 1 pihole pihole          0 Feb 22  2020 pihole-FTL.conf
-rw-rwxr--+ 1 root   root   3269869568 Jan 23 15:09 pihole-FTL.db
-rw-rwxr--+ 1 root   root        16928 Jan 23 15:09 pihole-FTL.db-journal
-rw-rwxr--+ 1 root   root     71725056 Feb 23  2020 pihole-FTL.db.bak
-rw-rwxr--+ 1   1000 root          616 Jan 23 15:08 setupVars.conf
-rw-rwxr--+ 1   1000 root          671 Jan 23 15:08 setupVars.conf.update.bak

I run pihole with mounted volume to local bind like this:

    volumes:
      - '/srv/pihole/etc/pihole/:/etc/pihole/'
      - '/srv/pihole/etc/dnsmasq.d/:/etc/dnsmasq.d/'
      - '/srv/pihole/etc/lighttpd/:/etc/lighttpd/'

inspection of the docker container reveals:

# id pihole
uid=999(pihole) gid=999(pihole) groups=999(pihole)

# id www-data
uid=33(www-data) gid=33(www-data) groups=33(www-data),999(pihole)

so:

• pihole user (999) is only a group of itself 999
• www-data user (33) is a group of both itself 33 and pihole 999

however, EVEN THOUGH, after chmod -R 999:999 ... the web UI still refused to operate -- some files do indeed only have USER rw, and GROUP only r ...

so you can do either:

sudo chown -R www-data:pihole /etc/pihole

OR

sudo chown -R pihole:pihole /etc/pihole
sudo chmod -R g+rw,u+rw /etc/pihole

[fermulator]

it also looks like after gravity is updated, the permissions get borked again :(

-rw-rw-r--+ 1      999 docker    5001216 Jan 24 04:27 gravity.db

and the GROUP MOD workaround I proposed above DOES NOT WORK - annoying ... www-data has to be USER OWNER of the DB to work ... but permissions keep change it to root or pihole

[fermulator]

sigh, some recent updates (last month-ish) - since then the workaround is no longer working

[ShadowZero3000]

I struggled with this for a while today, on a setup with kubernetes on an NFS persistentvolume. The only thing that finally changed things to make it work was to chown pihole:www-data /etc/pihole
Not the gravity.db in particular, but to make the directory itself accessible to the webserver.
I can't quite put my finger on the why here, but it worked for me.

[isaacrlevin]

@ShadowZero3000 your fix does not work on latest of the image FYI

[fermulator]

to slightly compete with my own comment 20 days ago .. recently I ran another cycle of docker update out of frustration (unable to change settings in the web UI due to permissions), and my "workaround" in my update script worked; sharing:

fermulator@docker:/srv/pihole$ cat upgrade.sh 
docker pull pihole/pihole:latest
docker rm -f pihole
docker-compose up -d pihole

# https://github.com/pi-hole/docker-pi-hole/issues/610
echo "WORKAROUND: chown for pihole /etc, requires sudo"
sudo chown -R 33:999 ./etc

^ this is run from relative path (same dir as docker-compose.yml)
, I didn't change anything here, so that is confusing; (perhaps the pihole version had a regression and was since fixed)

[jakev383]

I noticed yesterday that I could not add DNS entries again. Went through a few recreates with the container trying to get it to work.
Later I did get it to work, which was good. A half hour or so later I noticed one of the adlists I use is no longer public so I tried to remove it and was given the "attempt to write to a read only database" error. Looking at the permissions from the docker host side, I noticed a few entries which were different:

$ ls -lh pihole/etc-pihole/
total 5.9M
-rw-rw-r--+ 1 www-data spi   65 Apr 14 08:50 adlists.list
-rw-r--r--  1 www-data spi    0 Apr 14 08:43 custom.list
-rw-r--r--+ 1 www-data spi  618 Apr 14 08:58 dns-servers.conf
-rw-r--r--+ 1 www-data spi   16 Apr 14 08:51 GitHubVersions
-rw-rw-r--+ 1      999 spi 4.3M Apr 14 08:58 gravity.db
-rw-r--r--+ 1 www-data spi 1.5M Apr 14 08:58 list.1.raw.githubusercontent.com.domains
-rw-r--r--+ 1 www-data spi   20 Apr 14 08:58 localbranches
-rw-r--r--+ 1 www-data spi   41 Apr 14 08:58 local.list
-rw-r--r--+ 1 www-data spi   40 Apr 14 08:58 localversions
drwxrwxr-x+ 2 www-data spi 4.0K Apr 14 08:43 migration_backup
-rw-r--r--  1      999 spi    0 Apr 14 08:43 pihole-FTL.conf
-rw-r--r--+ 1 www-data spi  52K Apr 14 08:58 pihole-FTL.db
-rw-rw-r--+ 1 www-data spi  261 Apr 14 08:58 setupVars.conf
-rw-rw-r--+ 1 www-data spi  261 Apr 14 08:58 setupVars.conf.update.bak

From that system:

$ grep data /etc/passwd
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
$ grep spi /etc/group
spi:x:999:pi

I changed the permissions as @fermulator did, but used names instead of numerical:

$ sudo chown -R www-data:spi *
pi@nextcloudpi:~/docker/pihole/etc-pihole $ ls -lh
total 6.1M
-rw-rw-r--+ 1 www-data spi   65 Apr 14 08:50 adlists.list
-rw-r--r--  1 www-data spi  843 Apr 14 09:10 custom.list
-rw-r--r--+ 1 www-data spi  618 Apr 14 08:58 dns-servers.conf
-rw-r--r--+ 1 www-data spi   16 Apr 14 08:58 GitHubVersions
-rw-rw-r--+ 1 www-data spi 4.5M Apr 14 09:25 gravity.db
-rw-r--r--+ 1 www-data spi 1.5M Apr 14 09:25 list.1.raw.githubusercontent.com.domains
-rw-r--r--+ 1 www-data spi  521 Apr 14 09:25 list.3.s3.amazonaws.com.domains
-rw-r--r--+ 1 www-data spi  43K Apr 14 09:25 list.4.s3.amazonaws.com.domains
-rw-r--r--+ 1 www-data spi   20 Apr 14 09:20 localbranches
-rw-r--r--+ 1 www-data spi   41 Apr 14 09:25 local.list
-rw-r--r--+ 1 www-data spi   40 Apr 14 09:20 localversions
drwxrwxr-x+ 2 www-data spi 4.0K Apr 14 08:43 migration_backup
-rw-r--r--  1 www-data spi    0 Apr 14 08:43 pihole-FTL.conf
-rw-r--r--+ 1 www-data spi  52K Apr 14 09:29 pihole-FTL.db
-rw-rw-r--+ 1 www-data spi  497 Apr 14 09:08 setupVars.conf
-rw-rw-r--+ 1 www-data spi  261 Apr 14 08:58 setupVars.conf.update.bak

I was then able to delete the adlist I no longer wanted. For fun, I ran piholg -g within the container, and then checked the permissions from the docker host again:

$ ls -lh
total 6.1M
-rw-rw-r--+ 1 www-data spi   65 Apr 14 08:50 adlists.list
-rw-r--r--  1 www-data spi  843 Apr 14 09:10 custom.list
-rw-r--r--+ 1 www-data spi  618 Apr 14 08:58 dns-servers.conf
-rw-r--r--+ 1 www-data spi   16 Apr 14 08:58 GitHubVersions
-rw-rw-r--+ 1      999 spi 4.5M Apr 14 09:29 gravity.db
-rw-r--r--+ 1 www-data spi 1.5M Apr 14 09:29 list.1.raw.githubusercontent.com.domains
-rw-r--r--+ 1 www-data spi  521 Apr 14 09:25 list.3.s3.amazonaws.com.domains
-rw-r--r--+ 1 www-data spi  43K Apr 14 09:25 list.4.s3.amazonaws.com.domains
-rw-r--r--+ 1 www-data spi   20 Apr 14 09:30 localbranches
-rw-r--r--+ 1 www-data spi   41 Apr 14 09:29 local.list
-rw-r--r--+ 1 www-data spi   40 Apr 14 09:30 localversions
drwxrwxr-x+ 2 www-data spi 4.0K Apr 14 08:43 migration_backup
-rw-r--r--  1 www-data spi    0 Apr 14 08:43 pihole-FTL.conf
-rw-r--r--+ 1 www-data spi  52K Apr 14 09:30 pihole-FTL.db
-rw-rw-r--+ 1 www-data spi  497 Apr 14 09:08 setupVars.conf
-rw-rw-r--+ 1 www-data spi  261 Apr 14 08:58 setupVars.conf.update.bak

And subsequently it would not let me delete the adlist again. Changing the permissions back in the docker host corrected this.
It looks like when tasks run periodically it sets the permissions to 999 as the owner (999 is user pihole in the container), but lighttpd does not have permissions to modify files owned by user pihole.

[TWhidden]

going from v4 to v5 - ran into this myself. Only way after hours of fiddling, was to just use a docker volume. For any others that are curious...

docker volume create pihole && \
docker volume create dnsmasq && \
docker run -d \
    --name pihole \
    -p 53:53/tcp -p 53:53/udp \
    -p 80:80 \
    -v pihole:/etc/pihole/ \
    -v dnsmasq:/etc/dnsmasq.d/ \
    -e ServerIP=10.64.128.6 \
    -e WEBPASSWORD=yourpasshere \
    -e PIHOLE_DNS_='68.105.28.16;68.105.29.16' \
    --net qnapeth1static \
    --ip 10.64.128.6 \
    --restart=always \
    --cap-add=NET_ADMIN \
    pihole/pihole:latest

In my case, on a QNAP - you can adjust as needed. This finally let me in.

[Trottel]

I have a similar problem, but the strange thing is that the gravity.db file is owned by the openmediavault-webgui user with UID and GID 999 and the pihole user doesn't exist at all. I'm using a docker-compose installation on OpenMediaVault 5 with Traefik proxy.

# ls -lh
total 7,1M
-rw-rw-r--+ 1 root                  openmediavault-config   65 srp 27 22:20 adlists.list
-rw-r--r--  1 root                  root                     0 srp 27 22:14 custom.list
-rw-r--r--+ 1 root                  root                   618 srp 27 22:22 dns-servers.conf
-rw-r--r--+ 1 root                  openmediavault-config   20 srp 27 22:22 GitHubVersions
-rw-rw-r--+ 1 openmediavault-webgui openmediavault-config 5,2M srp 27 22:22 gravity.db
-rw-r--r--+ 1 root                  openmediavault-config 1,8M srp 27 22:22 list.1.raw.githubusercontent.com.domains
-rw-rw-r--+ 1 root                  openmediavault-config   95 srp 27 22:14 list.1.raw.githubusercontent.com.domains.sha1
-rw-r--r--+ 1 root                  openmediavault-config   20 srp 27 22:30 localbranches
-rw-r--r--+ 1 root                  openmediavault-config   47 srp 27 22:22 local.list
-rw-r--r--+ 1 root                  openmediavault-config   44 srp 27 22:30 localversions
drwxrwsr-x+ 1 root                  openmediavault-config   24 srp 27 22:14 migration_backup
-rw-r--r--  1 openmediavault-webgui openmediavault-config    0 srp 27 22:14 pihole-FTL.conf
-rw-r--r--+ 1 root                  openmediavault-config  52K srp 27 22:33 pihole-FTL.db
-rw-rw-r--+ 1 root                  root                   323 srp 27 22:22 setupVars.conf
-rw-rw-r--+ 1 root                  openmediavault-config  323 srp 27 22:22 setupVars.conf.update.bak

# id openmediavault-webgui
uid=999(openmediavault-webgui) gid=996(openmediavault-webgui) groups=996(openmediavault-webgui),999(openmediavault-config),998(openmediavault-engined)

# groups pihole
groups: „pihole“: user doesn't exist

[dschaper]

The permissions you show are on the host. ls -lahn will show the UID, which happens to map to the openmediavault user. The pihole user exists inside the container so you wont see that username on the host system, the host doesn't know anything about the name.

Files are really done using the numeric UID/GID, the human readable username is just human readable. If you check /etc/passwd or /etc/group on the host system you'll see what the host has set for ID to name mappings.

If you want to affect the UID/GID in the container then you'll need to use the environment variables to do that.

docker run -it --rm --entrypoint /bin/bash pihole/pihole:latest

root@4fca16941bcf:/# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
pihole:x:999:999::/home/pihole:/usr/sbin/nologin

[Trottel]

Thanks for the explanation. Unfortunately, it doesn't change the fact that I can't add any whitelist or blacklist entries or update Gravity.

[C4mp3r-Grey]

The hint by @TWhidden was fine for me on a RPi4:
Created two volumes 'pihole' and 'dnsmasq' and reconfigured the container in Portainer accordingly solved the issue for me.

@Trottel: Did you try?

going from v4 to v5 - ran into this myself. Only way after hours of fiddling, was to just use a docker volume. For any others that are curious...

docker volume create pihole && \
docker volume create dnsmasq && \
docker run -d \
 [...]
    -v pihole:/etc/pihole/ \
    -v dnsmasq:/etc/dnsmasq.d/ \

[asyba]

any news? I got the same issue on fresh install RPI4 , I change from latest to v5.8.1 but same error.
"While executing: attempt to write a readonly database"

[asyba]

any news? I got the same issue on fresh install RPI4 , I change from latest to v5.8.1 but same error.
"While executing: attempt to write a readonly database"

going back to v5.7 , works

[Trottel]

For me version 5.7 doesn't work either :(

[Trottel]

The hint by @TWhidden was fine for me on a RPi4:
Created two volumes 'pihole' and 'dnsmasq' and reconfigured the container in Portainer accordingly solved the issue for me.

@Trottel: Did you try?

going from v4 to v5 - ran into this myself. Only way after hours of fiddling, was to just use a docker volume. For any others that are curious...

docker volume create pihole && \
docker volume create dnsmasq && \
docker run -d \
 [...]
    -v pihole:/etc/pihole/ \
    -v dnsmasq:/etc/dnsmasq.d/ \

@C4mp3r-Grey: I'm using this docker-compose file:

version: "3.9"
services:
  pihole:
    container_name: pihole
    hostname: pihole-omv
    image: pihole/pihole:latest
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
      - NET_RAW
      - NET_BIND_SERVICE
    networks:
      traefik_proxy:
        ipv4_address: 192.168.101.253
    dns:
      - 127.0.0.1
      - 1.1.1.1
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp"
      - "1180:80/tcp"
      - "1443:443/tcp"
    security_opt:
      - no-new-privileges:true # Neither false doesn't work
    volumes:
      - $DIR_DOCKER/pihole/pihole:/etc/pihole
      - $DIR_DOCKER/pihole/dnsmasq.d:/etc/dnsmasq.d
    environment:
      - TZ=$TZ
      - ServerIP=192.168.2.101 # (My Docker Host IP)
      - PROXY_LOCATION=pihole
      - VIRTUAL_HOST=pihole.$DOMAINNAME
      - VIRTUAL_PORT=80
      - IPv6=False
      - WEBPASSWORD=$PIHOLE_PASSWORD
      - PIHOLE_DNS_=127.0.0.1;1.1.1.1
    labels:
      - "traefik.enable=true"
      ## HTTP Routers
      - "traefik.http.routers.pihole-rtr.entrypoints=https"
      - "traefik.http.routers.pihole-rtr.rule=Host(`pihole.$DOMAINNAME`)"
      ## Middlewares
      - "traefik.http.routers.pihole-rtr.middlewares=chain-no-auth@file"
      ## HTTP Services
      - "traefik.http.routers.pihole-rtr.service=pihole-svc"
      - "traefik.http.services.pihole-svc.loadbalancer.server.port=80"

networks:
  traefik_proxy:
    external: true

[Trottel]

I finally figured it out! It was my mistake.

I need to use the following docker-compose file:

version: "3.9"
services:
  pihole:
    container_name: pihole
    hostname: pihole-omv
    image: pihole/pihole:latest
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
      - NET_RAW
      - NET_BIND_SERVICE
    networks:
      traefik_proxy:
        ipv4_address: 192.168.101.253
    dns:
      - 127.0.0.1
      - 1.1.1.1
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp"
      - "1180:80/tcp"
      - "1443:443/tcp"
    security_opt:
      - no-new-privileges:false # With "true" I can't update Gravity!
    volumes:
      - pihole:/etc/pihole
      - dnsmasq:/etc/dnsmasq.d
    environment:
      - TZ=$TZ
      - ServerIP=192.168.2.101 # (My Docker Host IP)
      - PROXY_LOCATION=pihole
      - VIRTUAL_HOST=pihole.$DOMAINNAME
      - VIRTUAL_PORT=80
      - IPv6=False
      - WEBPASSWORD=$PIHOLE_PASSWORD
      - PIHOLE_DNS_=127.0.0.1;1.1.1.1
    labels:
      - "traefik.enable=true"
      ## HTTP Routers
      - "traefik.http.routers.pihole-rtr.entrypoints=https"
      - "traefik.http.routers.pihole-rtr.rule=Host(`pihole.$DOMAINNAME`)"
      ## Middlewares
      - "traefik.http.routers.pihole-rtr.middlewares=chain-no-auth@file"
      ## HTTP Services
      - "traefik.http.routers.pihole-rtr.service=pihole-svc"
      - "traefik.http.services.pihole-svc.loadbalancer.server.port=80"

volumes:
  pihole:
  dnsmasq:

networks:
  traefik_proxy:
    external: true

One question. It is possible to manually create volume in a specific location, e.g. "/srv/disk-Data/Configs/marapavelka/docker/pihole/pihole"?

[asyba]

@Trottel thanks!
using this on my template, works I think, need to do more testing, but results are good

security_opt:
      - no-new-privileges:false # With "true" I can't update Gravity!

volumes:
      - pihole:/etc/pihole
      - dnsmasq:/etc/dnsmasq.d

volumes:
  pihole:
  dnsmasq:

[asyba]

this are some debug log that are strange, not sure if are normal and can be ignore?

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] tc.tradetracker.net is 0.0.0.0 via localhost (127.0.0.1)
[✗] Failed to resolve tc.tradetracker.net via Pi-hole (192.168.1.114)
[✓] doubleclick.com is 172.217.162.238 via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Pi-hole processes
[✗] lighttpd daemon is inactive
[✗] pihole-FTL daemon is inactive

*** [ DIAGNOSING ]: Dashboard and block page
[✗] Block page X-Header: X-Header does not match or could not be retrieved.
HTTP/1.1 200 OK
Content-type: text/html; charset=UTF-8
Expires: Fri, 10 Sep 2021 03:59:25 GMT
Cache-Control: max-age=0
Date: Fri, 10 Sep 2021 03:59:25 GMT
Server: lighttpd/1.4.53

[danteali]

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.

[ppastur]

I also have the same issue. If I build the container without the volume bind mount it works fine other than persistence. The moment I bind /etc/pihole the web UI complains about permissions.
I tried the workaround mentioned in this thread (docker exec pihole chown -R www-data:pihole /etc/pihole) it all just works.

I note that @danteali runs this command in the container start up script. I don’t have the knowledge or experience to understand how to do that so I run it manually. I would love it if someone could help me understand how to automate that work around. Obviously understanding the problem and fixing it is a better option for me but I’ll settle for the work around

[dschaper]

@PromoFaux Can we add that chown to the start script?

[danteali]

@ppastur It's not complex, I just have a simple 2 line script which runs the docker run command for pihole and the chown command on the next line.

@dschaper While this would help some of us I'm not convinced it's a great idea globally. I don't know what other implications it might have.
But mainly I'm reluctant since (for me anyway) the permissions issue reoccurs while the container is running if Gravity is updated (e.g. adding new blocklists). And I have to re-run the chown command to fix it again.

It's not like I'm making a lot of changes to pihole once it's set up so the problem doesn't really bother me on a day-to-day basis. And I can work around it with chown whenever I need to.

[PromoFaux]

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