V5.0 Docker, Whitelist domain, writing to readonly database

just removed all v5 related from docker and the host, removed the "privileged: true" from docker_compose and did a clean docker pull.
After the pull I tried to add a domain to the whitelist, still getting the error;
https://tricorder.pi-hole.net/cufdubt8kd
I see a readonly error in the log.

On this clean install I ran the 2 sql commands;

root@pihole:/# sudo -u pihole sqlite3 /etc/pihole/gravity.db "INSERT INTO domainlist (domain) VALUES ('test.domain1');"
root@pihole:/# sudo -u www-data sqlite3 /etc/pihole/gravity.db "INSERT INTO domainlist (domain) VALUES ('test.domain2');"
Error: attempt to write a readonly database
root@pihole:/#

here's a log from after the 2 sql commands;
https://tricorder.pi-hole.net/ju0h27d9hj

I see only 1 whitelist test domain in the debug log, despite the 2 commands.
So the readonly error is really preventing it to write to the database.

Looks like gravity.db is now created with owner pihole;

root@pihole:/etc/pihole# ls -all
total 7088
drwxrwxr-x+ 3 pihole pihole    4096 May 13 07:27 .
drwxrwxr-x  1 root   root      4096 May 13 07:18 ..
-rw-r--r--+ 1 root   root        14 May 13 07:19 GitHubVersions
-rw-r--r--+ 1 root   root       596 May 13 07:18 dns-servers.conf
-rw-rw-r--+ 1 pihole pihole 5189632 May 13 07:23 gravity.db
-rw-r--r--+ 1 root   root   1136412 May 13 07:18 list.0.raw.githubusercontent.com.domains
-rw-r--r--+ 1 root   root    594672 May 13 07:18 list.1.mirror1.malwaredomains.com.domains
-rw-r--r--+ 1 root   root       521 May 13 07:18 list.2.s3.amazonaws.com.domains
-rw-r--r--+ 1 root   root     43529 May 13 07:18 list.3.s3.amazonaws.com.domains
-rw-r--r--+ 1 root   root        31 May 13 07:18 local.list
-rw-r--r--+ 1 root   root        20 May 13 07:20 localbranches
-rw-r--r--+ 1 root   root        37 May 13 07:20 localversions
drwxrwxr-x+ 2 root   root      4096 May 13 07:18 migration_backup
-rw-r--r--  1 pihole pihole       0 May 13 07:18 pihole-FTL.conf
-rw-r--r--+ 1 root   root    237568 May 13 07:27 pihole-FTL.db
-rw-rw-r--+ 1 root   root       445 May 13 07:18 setupVars.conf
-rw-rw-r--+ 1 root   root         0 May 13 07:18 setupVars.conf.update.bak

So the privileged line is probably the cause of the root ownerships.
But even though the default ownership is fixed, I still get the readonly errors.

Last thing i did is run "pihole -g -r" and restart the container. Then I tried to add something to the whitelist, still getting the error and here's a log again;
https://tricorder.pi-hole.net/l6e5z9yz2p

I now see a bunch of readonly errors in the log.

If there's something I can do, let me know!

Try again after running

sudo usermod -aG pihole www-data

Ran the usermod command inside the docker container, tried the sqlite command, here's the result;

root@pihole:/etc/pihole# sudo usermod -aG pihole www-data
root@pihole:/etc/pihole# sudo -u www-data sqlite3 /etc/pihole/gravity.db "INSERT INTO domainlist (domain) VALUES ('test.domain2');"
Error: attempt to write a readonly database
root@pihole:/etc/pihole# sudo -u pihole sqlite3 /etc/pihole/gravity.db "INSERT INTO domainlist (domain) VALUES ('test.domain1');"
Error: UNIQUE constraint failed: domainlist.domain
root@pihole:/etc/pihole#

again seeing the php errors;

-rw-r--r-- 1 www-data www-data 277 May 13 18:46 /var/log/lighttpd/error.log
   2020-05-13 20:45:14: (log.c.217) server started 
   2020-05-13 20:46:13: (mod_fastcgi.c.2543) 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 507

[✓] Your debug token is: https://tricorder.pi-hole.net/rp48kg7wti

The docker container should "just work", so this is confusing me here. Just in case he did not see the assignment, I'll ping @diginc to take a closer look at this thread, he is the docker guru!

I am using this version of the container and not seeing any issues.

FWIW my compose file: (though you ignore the traefik labels and probably the dependency on unbound - note I am using macvlan - hence MAC address - also I'm not very good at docker, so there is probably superflous stuff in there!)

version: '3.5'
services:

  pihole:
    container_name: pihole
    depends_on:
      - unbound
    image: pihole/pihole:v5.0
    environment:
      - TZ=Europe/London
      - ServerIP=192.168.1.253
      - DNS1=192.168.1.254#53
      - DNS2=no
      - DOMAIN=mydomain.tld
      - HOST_IP=192.168.1.253
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./pihole/resolv.conf:/etc/resolv.conf
      - ./pihole/configs/pihole/:/etc/pihole/
      - ./pihole/configs/dnsmasq.d:/etc/dnsmasq.d/
      # - ./pihole/01-conf-dnsmasq.sh:/etc/cont-init.d/01-conf-dnsmasq.sh
    ports:
      - "53:53/tcp"
      - "67:67/udp" # Uncomment if you want to use Pi-Hole for DHCP
      - "53:53/udp"
    expose:
      - "80"
    mac_address: d0:ca:ab:cd:ef:fe
    networks:
      home:
        ipv4_address: 192.168.1.253
    dns:
      - 127.0.0.1
    cap_add:
      - NET_ADMIN
    restart: always
    labels:
      - traefik.enable=true
      - traefik.docker.network=home
  ##### http
    ### services
      # backend port
      - traefik.http.services.svc_PiholeGui.loadbalancer.server.port=80
    ### middleware
      # redirecting pi.hole
      - traefik.http.middlewares.mdw_RedirectPihole.redirectregex.permanent=true
      - traefik.http.middlewares.mdw_RedirectPihole.redirectregex.regex=^.*pi\.hole(.*)
      - traefik.http.middlewares.mdw_RedirectPihole.redirectregex.replacement=https://pihole.mydomain.tld$$1
      # make sure `/admin` is there
      - traefik.http.middlewares.mdw_AddAdminPath.replacepathregex.regex=^/((?i:(admin)/{0,1}|.{0})(.*))
      - traefik.http.middlewares.mdw_AddAdminPath.replacepathregex.replacement=/admin/$$3
      # pihole chain
      - traefik.http.middlewares.mdw_PiholeChain.chain.middlewares=mdw_RedirectPihole,mdw_AddAdminPath,mdw_SecureHeaders@file
    ### routers
      # pihole dashboard
      - traefik.http.routers.rou_PiholeGui.entrypoints=web-secure
      - traefik.http.routers.rou_PiholeGui.rule=Host(`pihole.mydomain.tld`,`pi.hole`)
      - traefik.http.routers.rou_PiholeGui.tls=true
      - traefik.http.routers.rou_PiholeGui.tls.options=default
      - traefik.http.routers.rou_PiholeGui.middlewares=mdw_PiholeChain
      - traefik.http.routers.rou_PiholeGui.service=svc_PiholeGui
  ##### 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(`dot.mydomain.tld`)
      - traefik.tcp.routers.rou_PiholeDot.tls=true
      - traefik.tcp.routers.rou_PiholeDot.tls.certresolver=le
      - traefik.tcp.routers.rou_PiholeDot.tls.options=default
      - traefik.tcp.routers.rou_PiholeDot.service=svc_PiholeDns

  unbound:
    container_name: unbound
    image: mvance/unbound:latest
    hostname: syn-unbound
    mac_address: d0:ca:ab:cd:ef:ff
    ports:
      - 53/tcp
      - 53/udp
    networks:
      home:
        ipv4_address: 192.168.1.254
    restart: always

networks:
  home:
    external: true

Nothing stood out to me so far. Since no one suggested it one thing worth attempting is running FTL as non-root (probably need to remove all volume data again for the switch) which we have a env var for:

- DNSMASQ_USER=pihole

can be added to your environment: section - details in readme

This has NOT been necessary for my fairly similar stock setup in docker-compose - no Portainer though.

ok add "DNSMASQ_USER=pihole" to my compose file, removed everything related to Pihole 5.0 and it makes no difference.
I'm running a reasonable up2date "Ubuntu 20.04" with "Docker version 19.03.6, build 369ce74a3c", could this be a problem?

Maybe other people running Pihole 5.0 on these versions?

ah 20.04...the latest ubuntu which is not officially 'docker supported' (as in Docker Inc) yet and untested by myself. There have been a few other negative reports coming in for 20.04.

If its not above your head could you attempt querying apparmor for any sort of denies it might be doing in pihole's container?

Apparmor has been my #1 theory for permission issues in Pi-hole docker 20.04

Another easy test to see if its to blame is disable docker's apparmor

Same problem here:

Running pihole/pihole:latest (armhf) inside OMV4 on Armbian-Stretch (Debian based). AppArmor not running.

this morning tried a lot of stuff as on uid/uid vars, privileged, aa stuff, dns_masq, etc. etc.

Tried to disable AA with these settings;

    security_opt:
      - seccomp:unconfined
      - apparmor:unconfined

After applying these settings I ran "sudo aa-status | grep FTL" and it return nothing.
While without these settings it returned "/usr/bin/pihole-FTL docker-default".

without sec.opt;

xxx@xxxx-xxx:/opt/docker$ sudo aa-status | grep FTL
   /usr/bin/pihole-FTL (119821) docker-default
xxx@xxxx-xxx:/opt/docker$

with sec.opt;

xxx@xxxx-xxx:/opt/docker$ sudo aa-status | grep FTL
xxx@xxxx-xxx:/opt/docker$

From that I conclude that the settings do what the should do; disable AppArmor for PiHole.
With or without AppArmor disabled, I always get the write to readonly database error.
Also tried dozens of combination on gid/uid, privileged, dns_masq, nothing is working...

I'm lost here..........

Thanks for trying, I'll setup a 20.04 VM tonight to try to reproduce the problem.

Is this using the docker.io package? I think most people on 20.04 are using that but there is an alternative of trying to install bionic official docker on focal, though I haven't personally tried.

To help me setup the environment can you share your package name/version? dpkg -l | grep docker

The only other long shot idea I had is disable volumes completely (comment out) to see if removing the host FS volume solves this.

YES....found something.... Don't know if i'm happy with it, but its looks like a start to solve this.
User www-data is causing the problem looking at the sql statement executed with -u www-data.
So I search a lot on "docker write permission www-data" and looks like "www-data" has "troubles" to writing to a docker volume/share directory and/or sqlite don't like to have a database on a docker volume.
So I unshared the /etc/pihole directory and everything is working as a charme.

If you search on stuff like database on docker volumes you find a load of problems.

maybe its an idea to move the database to a different directory?

For what its worth for now;

xxx@xxx-xxx:/opt/docker$ dpkg -l | grep docker
ii  docker-ce                                     5:19.03.6~3-0~ubuntu-disco                  amd64        Docker: the open-source application container engine
ii  docker-ce-cli                                 5:19.03.6~3-0~ubuntu-disco                  amd64        Docker CLI: the open-source application container engine

Solved my problem by adjusting the ACLs to default:group:rwx for the shared directory and all files inside. They were set so default:group::rx before.

@Freemann

Have a look at the ACLs of your shared /etc/pihole directory. Your directory listing shows by the + sign at the end of the permissions that ACLs are set. This might prevent docker to have write access.

I already tried that with a "chmod -R 777 /etc/pihole".
After a restart of the docker container it resets the acl.

Tried the chmod from the host on the volume and inside the docker container. Didn't fixed it for me.

Try getfacl instead.

What should i run, in which environment, on which did?

Look at the ACLs of your host environment. Try "getfacl your_path_to_the_docker_shared_folder"

chmod won't fix ACL settings.

ok, thats "a new one for me" and here the result;

xxx@xxx-xxx:/opt/docker/pihole_v5$ getfacl /opt/docker/pihole_v5
getfacl: Removing leading '/' from absolute path names
# file: opt/docker/pihole_v5
# owner: root
# group: root
user::rwx
group::r-x
group:docker:rwx                #effective:r-x
mask::r-x
other::r-x
default:user::rwx
default:group::r-x
default:group:docker:rwx
default:mask::rwx
default:other::r-x

Is this good or bad and what command should I run to fix it?

Did some fiddeling and couldn't find a working solution with ACL.
So I decided to "reset" ACL on the volume dir;
sudo setfacl -Rbn /opt/docker/pihole_v5/

This fixed it for me :slight_smile:

@juha thanks for helping!!

So the error "attempt to write a readonly database" was in my case solved by resetting the ACL with this command;
sudo setfacl -Rbn /opt/docker/pihole_v5/

Hopefully it helps others with the same problem.

Thanks all for helping!

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.