Root-owned files in pihole/etc/pihole

[causalmask]

My backup jobs have been failing since I pulled the most recent version of the container. It seems to be due to the presence of root-owned files in pihole directories that I have mapped to local directories. I don't run my backup jobs as root, so the job fails when attempting to read files that are only readable by root.

The reason I bring this up is because pihole is currently the only container of the tens of containers I am running where this is an issue. I'm guessing it has to do with the recent addition of logrotate to the container, and I'm not sure of an easy workaround. For now, I'm excluding certain pihole files from my backup job, but would prefer to be able to backup the entire config directory as I do with my other containers.

Any workarounds or changes to the container to improve this situation would be greatly appreciated.

[rdwebdesign]

Please post your compose file, specially the volumes you used.

[yubiuser]

The logrotate has been included in the container also in v5 (and maybe even before). We actually reduced the amount of files owned by someone else than pihole

Only the logrotate should be owned by root on a fresh container

ff52ea330131:/# ls -lha /etc/pihole/
total 16M
drwxr-xr-x 7 pihole pihole 4.0K Mar  8 19:06 .
drwxr-xr-x 1 root   root   4.0K Mar  7 20:02 ..
-rw-r----- 1 pihole pihole   65 Feb 19 19:44 adlists.list
-rw-r----- 1 pihole pihole   44 Mar  8 19:06 cli_pw
drwxr-xr-x 2 pihole pihole 4.0K Feb 25 08:20 config_backups
-rw-r----- 1 pihole pihole    0 Feb 19 19:42 dhcp.leases
-rw-r----- 1 pihole pihole 5.1K Feb 24 19:49 dnsmasq.conf
-rw-r----- 1 pihole pihole 7.4M Feb 28 12:33 gravity.db
drwxr-xr-x 2 pihole pihole 4.0K Feb 28 12:33 gravity_backups
-rw-r----- 1 pihole pihole 7.4M Feb 28 12:33 gravity_old.db
drwxr-xr-x 2 pihole pihole 4.0K Feb 19 19:42 hosts
drwxr-xr-x 2 pihole pihole 4.0K Feb 28 12:33 listsCache
-rw-r----- 1 root   root    421 Mar  8 19:06 logrotate
drwxr-xr-x 2 pihole pihole 4.0K Feb 19 19:42 migration_backup
-rw-r----- 1 pihole pihole  88K Mar  7 21:46 pihole-FTL.db
-rw-r----- 1 pihole pihole  32K Mar  8 19:06 pihole-FTL.db-shm
-rw-r----- 1 pihole pihole 8.1K Mar  8 19:06 pihole-FTL.db-wal
-rw-r----- 1 pihole pihole  54K Feb 25 08:20 pihole.toml
-rw------- 1 pihole pihole  713 Feb 19 19:42 tls.crt
-rw-rw---- 1 pihole pihole 1001 Feb 19 19:42 tls.pem
-rw------- 1 pihole pihole  733 Feb 19 19:42 tls_ca.crt
-rw-r--r-- 1 pihole pihole  397 Mar  8 19:06 versions

UID and GID of pihole both default to 1000 which should usually match the UID/GID of the first user on the host system

docker-pi-hole/src/Dockerfile

Lines 14 to 15 in 78aee9e

	ARG PIHOLE_UID=1000
	ARG PIHOLE_GID=1000

[causalmask]

The logrotate has been included in the container also in v5 (and maybe even before). We actually reduced the amount of files owned by someone else than pihole

I'm just referring to the "What's Changed" for 2025.02.0:
https://github.com/pi-hole/docker-pi-hole/releases/tag/2025.02.0

It appears that is when the root-owned logrotate file started to be injected into the directory. I noticed that file was owned by root first, but I've subsequently run into other files/dirs owned by root as well. Currently, the full list is:

• etc/pihole/logrotate
• etc/pihole/gravity_backups (dir)
• etc/pihole/gravity_old.db
• etc/pihole/listsCache (dir)

I had no root-owned files in these dirs before updating from 2024.07.0.

I am passing the following in the environment section in my compose file (though I see they're already the default):

PIHOLE_UID: 1000
PIHOLE_GID: 1000

My volumes are mapped to local dirs so I can back them up, like this:

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

[causalmask]

A couple days ago, the other root-owned files (besides logrotate) switched back to being owned by the user. But then today one of them switched back to being root-owned (etc/pihole/gravity_old.db). I accept that logrotate is root owned, but what could be causing the other files to be switching owners periodically?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.