Error "attempt to write a readonly database" when adding adlist #860
Comments
|
Observing the same issue. This is the output from inside the container update: Downgraded the pi-hole docker image version to |
|
Please don't use As for the thumbs up and the additional report: Are you all on Synology? |
|
Same issue here trying to restore from teleporting: Using docker on RPi4. Pi-hole v5.3.1 Web Interface v5.5 FTL v5.8.1 docker-compose file: Front GUI reports -2 as domains on blocklist:
Saw some pihole-FTL.conf permission issues: This sympthom is also reported on #610 |
|
I am having these same issues. Has anyone had any luck? |
The advice against "latest" seems inconsistent with the guidance on Github for this package... |
|
Same issues using Pihole docker on RPi (buster). Have deleted the Docker images and volumes and pulled from fresh, same error when attempting anything. Can't write to database in any of the operations I've attempted: whitelist, adlist, groups, etc. I also have the odd "Domains on blocklist: -2" on the dashboard. I have tried pihole/pihole:lasest and pihole/pihole:v5.8.1-buster. I deleted the docker images and the mounted volumes and let them be recreated, same issue permissions issue. What is strange is that I did have pihole working in docker before, but then migrated to a SSD instead of the SDcard as my boot partition. I've had trouble ever since. Could the "readonly database" error be caused by the connection refused error on the php socket? |
|
have you tried updating the gravity lists from the ui (adress/admin/gravity.php) ? it worked for me: #751 (comment) |
|
Updating Gravity from the web UI just hangs. Updating Gravity with |
|
any news? I got the same issue on fresh install RPI4 , I change from latest to v5.8.1 but same error. |
going back to v5.7 , works |
|
Having the same issue. Ended up adding this to my container startup script to resolve: I've 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 |
|
I had the group permissions wrong on the pihole directory, which seemed to fix it. |
How did you fix? |
This seems to do the trick for me as well... looks like for whatever reason permissions on the /etc/pihole directory are wrong |
|
Why has this not yet been fixed? Devs working on other things? |
Show stopping issue is still around and not fixed. Strange for sure. I just ran into the issue here running from a container under Docker Swarm cluster. I'm going to revert back to a previous tag and see what happens. Looks like the container tags have changed from being version numbers to year.month naming now. Not sure where exactly in the progression this broke, but folks above state 5.7 version is the working one. |
To be honest, I hadn't even seen this issue thread. Reading through some of the responses, and at least some of the latter ones:
This is the reason. Looking over the release notes for I don't see this on either my Container tag version changes explained in 2021.09 release notes. |
Just going down the rabbit hole myself on this one. Its not a new issue so its no surprise you didn't see anything in the latest release notes that might affect it. Here's a few of the related threads if that helps: one, two, three, four, five. Some of them are from 2020, way before 5.7. It clearly has something to do with the persistent volumes recommended in the docker-compose quick start because when I remove them, the issue goes away. Adding them back makes this issue occur like clockwork. I can get the error to happen pretty reliably on a raspberry pi 400. Log in to web ui. Go to blacklist and try to add "github.com"
Neither of pihole and pihole-ftl logs move when I attempt to add to the blacklist. If I apply the The container's logs themselves also bear nothing particularly of interest: I don't know if I've brought anything new to the table but this is what I'm able to provide in terms of recreation so far. |
|
For those who stumble across this and are just looking for an automatic fix that works right now, I added the manual chown fix to the startup script. Here is what I'm doing: My Inside the Inside the Now do Since this clearly isn't the correct solution I won't be submitting this as a PR; the correct one probably involves s6-init or lighthttd which I don't know enough about it. But your pihole should work without manual intervention until either the official start.sh is updated or the issue is fixed. |
|
Thanks @aperullo. Appreciate the suggestion. This should fix it temporarily and feels like a reasonable workaround. However, I think you might still run into issues. In my circumstances (noted here), even if I fix at container startup, the permissions are somehow reverted while the container is running if Gravity is updated. |
|
Are these all mounted volumes? Is it something that the host machine is doing? I've seen a couple of people mention synology above |
|
This is happening for me with docker volumes, not bind mounts. |
|
I'm on a vanilla Ubuntu LTS server (can't recall exact version now). Volumes are just mounted on basic ext4 formatted disks. No similar issues with the 30+ other containers I have running. Weird thing is that ALL folder and file ownership/permissions are identical when I log into the container whether I have the volumes mounted or not. So feels strange that mounting the volumes is causing a problem. Also, pretty sure these issues are describing the same thing: |
|
I'm still not able to reproduce this locally, and I am still struggling to see what could be doing this. Some thinking out loud:
Clearly this is a real issue, as so many are reporting it -and I'd like to get to the bottom of what is causing it so that we can reliably troubleshoot in the future (Working) Permissions for And my compose file, for good measure version: '3.3'
services:
pihole:
container_name: pihole
hostname: pihole-docker
depends_on:
- unbound
image: pihole/pihole:nightly
environment:
TZ: Europe/London
ServerIP: 192.168.1.253
REV_SERVER: 'true'
REV_SERVER_DOMAIN: lan
REV_SERVER_TARGET: 192.168.0.1
REV_SERVER_CIDR: 192.168.0.0/16
SKIPGRAVITYONBOOT: 1
PIHOLE_DNS_: 192.168.1.254#5053
volumes:
- ./configs/pihole/:/etc/pihole/
- ./configs/dnsmasq.d:/etc/dnsmasq.d/
cap_add:
- NET_ADMIN
- SYS_NICE
mac_address: d0:ca:ab:cd:ef:fe
dns:
- 8.8.8.8
networks:
home:
ipv4_address: 192.168.1.253
restart: always
labels:
- traefik.enable=true
- traefik.docker.network=home
##### tcp
### services
# backend port
- traefik.tcp.services.svc_PiholeDns.loadbalancer.server.port=53
### routers
# DoT forward
- traefik.tcp.routers.rou_PiholeDot.entrypoints=dot
- traefik.tcp.routers.rou_PiholeDot.rule=HostSNI(`[mydomainforDOT]`)
- traefik.tcp.routers.rou_PiholeDot.tls=true
- traefik.tcp.routers.rou_PiholeDot.tls.certresolver=zerossl
- traefik.tcp.routers.rou_PiholeDot.tls.options=default
- traefik.tcp.routers.rou_PiholeDot.service=svc_PiholeDns
unbound:
container_name: unbound
image: klutchell/unbound
hostname: unbound-docker
# volumes:
# - ./unbound/:/etc/unbound
mac_address: d0:ca:ab:cd:ef:ff
networks:
home:
ipv4_address: 192.168.1.254
networks:
home:
external: true
|
|
Tagging in some more top minds here: @diginc , @lightswitch05 |
|
Hi all, apologies I've been uber busy so only getting round to testing the latest image (2022.02.01). However I now get the same/similar issue when trying to add/remove adlists, blacklist/whitelist updates, or any of the other actions that try to edit The original problematic files seem fine now, they are now owned by The new error only occurs when the volume is mounted. I currently have the following mounts defined in docker-compose.yml: But And when I log into the container the files look like: I have a solution/workaround by using the experimental 1. Set all 4 variables In this case, 1000 is the user ID of my main ubuntu system user, and 999 is the 'docker' group on my system. But that's just coincidence as it also works with some random values which didn't match any host or container user/group IDs. 2. Set I haven't had time to try any other combination of the UID/GID variables yet. Also, the two 'solutions' from before continue to be a workaround for this new permission problem. i.e.
Happy to help with more testing/troubleshooting if that's useful. |
|
Only way i managed to fix this is to just set my volumes on my boot drive on my truenas only problem with this is if i update my truenas scale i need to copy back the files or container stops working for some reason user permisions are only issue on actual storage volumes not boot pool |
|
I recall running into a similar problem for an unrelated project when SQLite3 utilizes write-ahead logging. Not sure if this is applicable here, but TL;DR was WAL could not be safely used over non-local filesystems. With WAL enabled, databases on NFS and CIFS mounted paths fail, with SQLite3 throwing lock or corruption errors in a very similar fashion to what we're seeing in these reports. In the end, a flag needed to get added to allow disabling of WAL for users that had NFS-mounted /home directories. |
|
I'm not sure if this particular problem was actually ever solved, but it is still occurring in my Docker Swarm deployment, with image tag 2022.04.3 (PiHole 5.10). Update: |
|
Agreed. There seems to be significant issues with anything but local
storage for the gravity.db. I'm trying to use this on Azure. Just tested
again and same issue. Basically if it's using local storage, not a problem.
The moment I map the storage (NFS) it all falls over.
[✗] Unable to create new database /etc/pihole/gravity.db_temp
Runtime error near line 191: database is locked (5)
And permissions are:
*** [ DIAGNOSING ]: Gravity Database
-rwxrwxrwx 1 root root 0 Jan 11 19:38 /etc/pihole/gravity.db
lightttpd also seems to have some major issues, suspecting permissions
relating to NFS mapping.
Is there any work planned to address? If not, I'll try to move this local.
But I'd REALLY like this to be in the cloud...
…On Tue, May 10, 2022 at 10:08 AM barry-luijten ***@***.***> wrote:
I'm not sure if this particular problem was actually ever solved, but it
is still occurring in my Docker Swarm deployment, with image tag 2022.04.3
(PiHole 5.10).
I believe the root cause of this problem lies within the fact that group
ownership inside the container does not have any meaning to the host OS
(the OS hosting the persistent volume). In other words, if the www-data
user is a member of the pihole group inside the container, but the host
user with the same uid is not a member of the host group with gid 999, it
does *not* have write access to a file that is owned by pihole:pihole
(999:999) with chmod 644.
I noticed the security settings on the gravity.db file in the /etc/pihole
directory are automatically reset while starting the container, but also
during operations. chown www-data:pihole /etc/pihole/gravity.db therefore
only works for a limited time. I found multiple scripts responsible for
doing this, like /start.sh and /etc/services.d/pihole-FTL/run, but there
are probably others too, because I tried to replace these files with
modified versions and the acls on the file kept being reset to
pihole:pihole. Annoying. I'm almost up to the point to schedule a cron job
(there is a cron daemon active in the container) to re-reset the acl to
www-data:pihole, but I hope there will be a cleaner solution.
—
Reply to this email directly, view it on GitHub
<#860 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEIZUTB4QWU6MI6K3WMJV6LVJKJY3ANCNFSM45WG7JMQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
@DesktopECHO - great insight! Is there any way to disable WAL?
…On Wed, Mar 30, 2022 at 4:15 AM DesktopECHO ***@***.***> wrote:
I recall running into a similar problem for an unrelated project when
SQLite3 utilizes write-ahead logging.
Not sure if this is applicable here, but TL;DR was WAL could not be safely
used over non-local filesystems. With WAL enabled, databases on NFS and
CIFS mounted paths fail, with SQLite3 throwing lock or corruption errors in
a very similar fashion to what we're seeing in these reports. In the end, a
flag needed to get added to allow disabling of WAL for users that had
NFS-mounted /home directories.
—
Reply to this email directly, view it on GitHub
<#860 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEIZUTEMF5Q3F3WEQCI2APLVCQZUJANCNFSM45WG7JMQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I'm getting all |
Running the It baffles my mind why it doesn't work and I need to change the group from pihole to www-data. |
Anybody coming across this, I got it working by setting only the WEB_UID to the pihole user. Other things I tried that didn't work:
|
|
This issue has been mentioned on Pi-hole Userspace. There might be relevant details there: https://discourse.pi-hole.net/t/pi-hole-says-it-is-blocking-80-of-ads-but-isnt/57870/8 |
|
Observed the same issue on a raspberry pi after performing updates/upgrade to raspbian buster and then running pihole-up. |
|
I am having similar issues. I believe the issue on my system is caused by a conflict between the UID/GID internal in the docker and the host system. I have zerotier-one installed on the host. This uses UID 999 GID 998 pihole uses UID 999 GID 999 in the docker that is using host mounted volumes. So in theory setting env variables UID and GID in the docker compose to something else like 900 for instance should solve the issue? Don't really want to lose all my data, but a momentary interruption in DNS service will be ok. Updating gravity etc. Did not reset the permissions even though the update completed fine. The entire mapped /etc directory was set as owned by zerotier-one as that corresponds to the host id 999 SO; if I shutdown the container, change the UID GID values in the env variables in docker compose, create a new user pihole UID 900 GID 900 in the host, set the permissions correctly in the host etc directory and then run the docker compose again..., Do we think this will come up ok and permissions will be good? Cheers |
FWIW, this worked for me.
On another older thread, I tried a command I don’t understand the nuances of uid and gid when it comes to host and container systems. I hope this gets easier for folks in the future. Thanks! |
|
|
|
Really appreciate all the work on this issue. I was one of the original commenters and have been using 22.02 with the Decided to eventually update my image and the same issue is still recurring. Unfortunately it hasn't gone away, as evidenced by the other comments above too. Although it does look like it is less pervasive since there are not as many comments. I'm going to keep using the workaround so it's not a big deal but just wanted to flag for @lightswitch05 and @PromoFaux as it feels like this issue was prematurely closed. |
|
This issue has been mentioned on Pi-hole Userspace. There might be relevant details there: https://discourse.pi-hole.net/t/default-pi-image-read-only-database/61049/1 |
|
I have encountered the same problem with the latest version on PI: Error, something went wrong! Pi-hole [v5.15.5] FTL [v5.21] Web Interface [v5.18.4] None of the above examples worked for me, so I did a Repair by typing: then, selecting Repair When came back, everything was fine and working correctly: https://www.screencast.com/t/XhJlWkNPotXQ I hope this will help someone in need! :) |
|
Same issue when running PiHole on truenas scale as app, one time adding a list and broken. Nice work. |
here my fix for it |
|
For me it was only the case if I did not wait for gravity to respond with success on that tab. If gravity is interuped it might lock the whole thing |
|
I also had this bug. I saw that the webroot on Pihole
fixed it. Then it is owned by the Apache user (Ubuntu 22.04 on Raspberry 4 Pi). |
|
From my end it was a permission issue with etc-pihole directory. Reproduction steps:
|
|
I had to use a windows based os to test pihole. I tested it with wsl (ubuntu) to stay as close as possible to a unix system. I had the read only problem at each container's start. Even root was not able to change owner nor the rights. The solution for me was to add in wsl.conf: options= "metadata" |
|
I had this issue too. I was trying to set the volume to the same volume as all of my other containers which are run by a certain UID/GID. I changed my paths from /srv/dev-disk-by-uuid-blahblah to this: And redeployed and this solved the issue for me. I assume there's an issue with the permissions of the other volume. |
|
For anyone who ran into Check permissions: If not: |
I'm getting this error and my permission is already 664 Edit: My docker runs as user "pihole" which is UID/GID 1003:1003 I already updated my gravity-sync config with this, and it was still going read-only So I tried updating the PiHole container with these environment variables Restarted it again and now all are showing owned by pihole:pihole. Will see if the problem persists. I havent changed the config in a long time; so not sure what's changed to start causing this issue |
Worked here! Thank you very much dude! |
and others
This is a: Run Issue
Details
When I try to add any blocklist, a red popup shows in upper right corner with the following message, and the list isn't added :
Related Issues
#751
#610
How to reproduce the issue
Go to adlist group management page
Add a new adlist (https://raw.githubusercontent.com/PolishFiltersTeam/KADhosts/master/KADhosts.txt)
Click "Add" button
docker-compose.yml contents, docker run shell command, or paste a screenshot of any UI based configuration of containers here
any additional info to help reproduce
These common fixes didn't work for my issue
docker runexample(s) in the readme (removing any customizations I added)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.
The text was updated successfully, but these errors were encountered: