Hi.
I've got a warning in "Pi-hole diagnosis".
When trying to delete that i get the following error message:
Error, something went wrong!
While executing message statement: attempt to write a readonly database
The entry itself is:
2021-12-23 14:28:17 DNSMASQ_WARN Warning in
dnsmasqcore:
reducing DNS packet size for nameserver 172.18.0.1 to 1280
Versions: * Docker Tag 2021.12
From inside the container, what is the output of
ls -lh /etc/pihole
?
root@pihole-bonsi:/etc/pihole# ls -lh
total 220M
-rw-r--r-- 1 root root 15 Dec 23 18:37 GitHubVersions
-rw-r--r-- 1 root root 65 Aug 18 08:34 adlists.list
-rw-r--r-- 1 root root 1.9K Oct 4 14:52 custom.list
-rw-r--r-- 1 root root 651 Dec 23 14:22 dns-servers.conf
-rw-rw-r-- 1 pihole pihole 93M Dec 23 18:00 gravity.db
-rw-rw-r-- 1 pihole pihole 93M Dec 23 16:00 gravity_old.db
-rw-r--r-- 1 root root 80 Oct 27 14:47 list.1.gitlab.com.domains.sha1
-rw-r--r-- 1 root root 95 Aug 18 08:34 list.1.raw.githubusercontent.com.domains.sha1
-rw-r--r-- 1 root root 96 Aug 18 08:33 list.11.raw.githubusercontent.com.domains.sha1
-rw-r--r-- 1 root root 96 Aug 18 08:34 list.12.raw.githubusercontent.com.domains.sha1
-rw-r--r-- 1 root root 96 Aug 18 08:34 list.13.raw.githubusercontent.com.domains.sha1
-rw-r--r-- 1 root root 96 Oct 30 17:12 list.16.raw.githubusercontent.com.domains.sha1
-rw-r--r-- 1 root root 96 Oct 24 04:37 list.18.raw.githubusercontent.com.domains.sha1
-rw-r--r-- 1 root root 84 Oct 30 17:16 list.24.v.firebog.net.domains.sha1
-rw-r--r-- 1 root root 81 Aug 18 08:34 list.27.sysctl.org.domains.sha1
-rw-r--r-- 1 root root 96 Oct 30 17:12 list.29.raw.githubusercontent.com.domains.sha1
-rw-r--r-- 1 root root 96 Oct 24 04:37 list.30.raw.githubusercontent.com.domains.sha1
-rw-r--r-- 1 root root 96 Aug 18 08:33 list.31.raw.githubusercontent.com.domains.sha1
-rw-r--r-- 1 root root 96 Aug 18 08:33 list.32.raw.githubusercontent.com.domains.sha1
-rw-r--r-- 1 root root 96 Aug 18 08:33 list.33.raw.githubusercontent.com.domains.sha1
-rw-r--r-- 1 root root 33M Dec 23 18:00 list.34.raw.githubusercontent.com.domains
-rw-r--r-- 1 root root 96 Dec 23 06:00 list.34.raw.githubusercontent.com.domains.sha1
-rw-r--r-- 1 root root 90 Oct 27 14:47 list.4.hostfiles.frogeye.fr.domains.sha1
-rw-r--r-- 1 root root 84 Oct 30 17:12 list.7.raw.github.com.domains.sha1
-rw-r--r-- 1 root root 95 Oct 1 05:00 list.8.raw.githubusercontent.com.domains.sha1
-rw-r--r-- 1 root root 65 Dec 23 18:00 local.list
-rw-r--r-- 1 root root 20 Dec 23 19:50 localbranches
-rw-r--r-- 1 root root 37 Dec 23 19:50 localversions
drwxr-xr-x 2 root root 4.0K Aug 18 08:33 migration_backup
-rw-r--r-- 1 pihole pihole 34 Dec 23 14:22 pihole-FTL.conf
-rw-rw-r-- 1 root root 1.6M Dec 23 19:50 pihole-FTL.db
---------- 1 root root 0 Sep 16 09:13 seda1FBwH
---------- 1 root root 0 Sep 18 00:13 sedngJcoC
-rw-r--r-- 1 root root 406 Dec 23 16:28 setupVars.conf
-rw-r--r-- 1 root root 404 Dec 23 14:22 setupVars.conf.update.bak
This file should be owned by pihole:pihole not root:root.
Ok, thanks^^.
Fixed that; after restarting the container it still belongs to pihole.
Because I deleted the database an hour ago i've got no error in the log to delete. Will have to wait for a diagnosis-entry to appear.
First of all: Merry Christmas!
Could you please describe how do you fixed that?
Because I have the same error on my PiHole Docker.
Thanks in advance!
Best,
Christian
Sure:) (If pihole is the name of your docker container, if it isn't, youi'll have to replace pihole with the actual name)
docker exec pihole chown -v pihole:pihole /etc/pihole/pihole-FTL.db
This fixed that and i can confirm that i now can delete log-entries.
Thank you very much!
I changed the permission successfully and can confirm that it´s works.
Have a nice day!
Best,
Christian
Did have the same error, fixed with #16.
I do suggest to give more details in the error message (suggesting, not demanding! 
)
Thanks for the suggestion. The error you've seen is generated by the SQLite3 database engine, not some code we write or maintain. We could try catching and transcribing it but that would have to be done in many places. Not sure if it would improve the overall situation as sticking to the database engine's standard (= well-known) error messages seems beneficial, too.
Thanks, this solved it for me. To prevent this from happening in the future, see here: