Imposible to add more domains to whitelist or blocklist.

[i5Js]

Hello,

I'm unable to add more domains to adlist or whitelist files using the pihole web interface. I've filled before with some domains to the values template, and I'm always get the message: "read-only filesystem". It's strange because If I let without any domain the values template, it works fine, I can add or remove domains.

Regards

[MoJo2600]

Yes, i think i know what happens. Adlist, whitelist, etc. are stored in a configmap inside the cluster. If you define them in values.yaml those are mounted to the container. configmap mounts by default are read only in kubernetes.
On the other hand, if you do not define any of those inside the values.yaml, the helm chart will create and mount a configmap. A local file inside the pihole container is used. But this file is not persistent. It will be deleted when the container is deleted.
So the kubernetes helm way to do it properly is to update values.yaml with your new adlist and then update the deployment.

[i5Js]

Hi
Thanks for your answer, understood! I've followed the second way and the file is persistent, since it's created inside a volume which is in my NFS share, so the changes remain even if the pod is restarted.

BTW, I'm not sure it's what you're saying, I've made a test with my classic version of pihole, using a custom config map for those values and it's working fine

Regards

[MoJo2600]

Ok sounds good... but for the second part, i would be very interested in your configuration because i have no idea how this should work. But maybe there is something new to learn :)

Regards

[i5Js]

Sure, what do you need? Config map or helm values?

[MoJo2600]

The configmap definition and how the configmap is mounted into the pod would be great.

[i5Js]

Config map:

cat pihole_configMap.yml 
---
apiVersion: v1
kind: ConfigMap
metadata:
   name: pihole-env
   namespace: dns-home
data:
   02-lan: |
    addn-hosts=/etc/pihole/lan.list

   adlist : |
        https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts 
        https://mirror1.malwaredomains.com/files/justdomains 
        http://sysctl.org/cameleon/hosts 
        https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist 
        https://s3.amazonaws.com/lists.disconnect.me/simple_tracking.txt 
        https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt 
        https://hosts-file.net/ad_servers.txt 
        https://raw.githubusercontent.com/CHEF-KOCH/Audio-fingerprint-pages/master/AudioFp.txt 
        https://raw.githubusercontent.com/CHEF-KOCH/BarbBlock-filter-list/master/HOSTS.txt 
        https://raw.githubusercontent.com/CHEF-KOCH/Canvas-fingerprinting-pages/master/Canvas.txt 
        https://raw.githubusercontent.com/CHEF-KOCH/Canvas-Font-Fingerprinting-pages/master/Canvas.txt 
        https://raw.githubusercontent.com/CHEF-KOCH/WebRTC-tracking/master/WebRTC.txt 
        https://raw.githubusercontent.com/CHEF-KOCH/CKs-FilterList/master/HOSTS/Ads-tracker.txt 
        https://raw.githubusercontent.com/CHEF-KOCH/CKs-FilterList/master/HOSTS/coinminer.txt 
        https://raw.githubusercontent.com/CHEF-KOCH/CKs-FilterList/master/HOSTS/Malware.txt 
        https://raw.githubusercontent.com/CHEF-KOCH/CKs-FilterList/master/filters/nsablocklist.txt 
        https://raw.githubusercontent.com/CHEF-KOCH/CKs-FilterList/master/uMatrix/CK's-uMatrix-FilterList.txt 
        http://phishing.mailscanner.info/phishing.bad.sites.conf 
        https://ransomwaretracker.abuse.ch/downloads/RW_DOMBL.txt 
        https://ransomwaretracker.abuse.ch/downloads/CW_C2_DOMBL.txt 
        https://ransomwaretracker.abuse.ch/downloads/LY_C2_DOMBL.txt 
        https://ransomwaretracker.abuse.ch/downloads/TC_C2_DOMBL.txt 
        https://ransomwaretracker.abuse.ch/downloads/TL_C2_DOMBL.txt 
        https://gitlab.com/quidsup/notrack-blocklists/raw/master/notrack-blocklist.txt 
        https://gitlab.com/quidsup/notrack-blocklists/raw/master/notrack-malware.txt 
        https://zerodot1.gitlab.io/CoinBlockerLists/list.txt 
        https://zerodot1.gitlab.io/CoinBlockerLists/list_browser.txt 
        https://zerodot1.gitlab.io/CoinBlockerLists/list_optional.txt 
        https://raw.githubusercontent.com/crazy-max/WindowsSpyBlocker/master/data/hosts/spy.txt 
        https://raw.githubusercontent.com/w13d/adblockListABP-PiHole/master/Spotify.txt 
        https://smokingwheels.github.io/Pi-hole/allhosts

   reglist: |
      ^(.+[-.])??adse?rv(er?|ice)?s?[0-9][-.]
      ^analytics?[-.]
      ^banners?[-.]
      ^count(ers?)?[0-9][-.] ^pixels?[-.]
      ^beacons?[0-9][-.]
      ^stat(s|istics)?[0-9][-.]
      ^telemetry[-.]
      ^track(ers?|ing)?[0-9]*[-.]
      ^traff(ic)?[-.]
      ^adim(age|g)s?[0-9][-.]
      ^adtrack(er|ing)?[0-9][-.]
      ^advert(s|is(ing|ements?))?[0-9][-_.]
      ^aff(iliat(es?|ion))?[-.]
      ^(.+[-.])??m?ad[sxv]?[0-9][-.]
      (^r[[:digit:]]+(.|-+)[[:alnum:]]+-+[[:alnum:]]+-+[[:alnum:]]+.)(googlevideo|gvt1).com$

Deployment

volumeMounts:
          - name: custom-adlist
            mountPath: "/etc/pihole/adlists.list"
            subPath: "adlists.list"
          - name: reglist
            mountPath: "/etc/pihole/regex.list"
            subPath: "regex.list"
          - name: custom-lan-list
            mountPath: "/etc/pihole/lan.list"
            subPath: "lan.list"
          - name: custom-02-lan
            mountPath: "/etc/dnsmasq.d/02-lan.conf"
            subPath: "02-lan.conf"
          - name: pihole-local-storage
            mountPath: "/etc/pihole"
            subPath: "pihole/pihole_etc"
          - name: pihole-local-storage
            mountPath: "/etc/dnsmasq.d"
            subPath: "pihole/pihole_dnsmasq.d"
      volumes:
      - name: pihole-local-storage
        persistentVolumeClaim:
          claimName: dns-storage-disk
      - name: reglist
        configMap:
          name: pihole-env
          items:
          - key: reglist
            path: regex.list
      - name: custom-adlist
        configMap:
          name: pihole-env
          items:
          - key: adlist
            path: adlists.list

Hope it’s helps

[Gory19]

I have a similar problem with Pihole v5.0. When I add a domain to the blocklist, I get the message "While executing: attempt to write a readonly database". How can I solve it?

[MoJo2600]

I believe this is due the change from separate files to a gravity database in pihole 5. We need to change the deployment to a stateful set to enable a writable database. I reopened issue #19 . I how I will find some time to implement this change.

[MoJo2600]

@Gory19 I tried it today on my cluster. But it was working for me. Do you have persistence enabled?

[i5Js]

@MoJo2600 I've same issue, and I have persistence enabled.

[MoJo2600]

Hm... then i don't get it. If I go to Blacklist and then add the entry it gets saved.

...
        volumeMounts:
        - mountPath: /etc/pihole
          name: config
...
      volumes:
      - name: config
        persistentVolumeClaim:
          claimName: pihole
...

This Is everything that is configured by helm.

[i5Js]

The issue, on my case, comes when you try to add a new domain into a whitelist, my mounts:
Mounts:
/etc/addn-hosts from custom-dnsmasq (rw,path="addn-hosts")
/etc/dnsmasq.d/02-custom.conf from custom-dnsmasq (rw,path="02-custom.conf")
/etc/pihole from config (rw)

[MoJo2600]

Which version of the chart are you running? Are you on pihole 5?

[Gory19]

@Gory19 I tried it today on my cluster. But it was working for me. Do you have persistence enabled?

Yes, I have persistence enabled.

[i5Js]

@MoJo2600 Chart: pihole-1.7.6

[MoJo2600]

I had a look at it today and I'm not sure what is going on. Since pihole 5 introduced the gravity database, everything you define in the files will be imported to the database during start. If you have persistence enabled, the database is stored in the persisted volume. You should be able to change everything and it should stay there, even if you restart the container.
Maybe you could execute a kubectl get all -o yaml --namespace $PIHOLENAMESPACE and give me a link to the resulting json file? Then i could compare it with my deployment?

[Gory19]

I had a look at it today and I'm not sure what is going on. Since pihole 5 introduced the gravity database, everything you define in the files will be imported to the database during start. If you have persistence enabled, the database is stored in the persisted volume. You should be able to change everything and it should stay there, even if you restart the container.
Maybe you could execute a kubectl get all -o yaml --namespace $PIHOLENAMESPACE and give me a link to the resulting json file? Then i could compare it with my deployment?

Here's to you:
https://pastebin.com/Mg1C4H16

[i5Js]

Mine

https://pastebin.com/rLbQRAjc

[Stackclash]

I'm having the same issue. I'm getting the error:

While executing: attempt to write a readonly database

This happens when trying to add a domain to the whitelist or blacklist via the UI.

[MoJo2600]

I had a look at the configuration, but can't see a difference. I think is has to do with the PVC/PV but right now I'm just guessing. The access mode of your pvc is set to RWO? Are you able to create a file inside the container in the folder /etc/pihole and how are the file access rights set in this folder? The whole folder is mounted to the PV so you should be able to create files there and all files should be readable from the container.

[i5Js]

Hi,

I’ve created a file at /etc/pihole without any problem. The permissions are root:root.

I’m checking the contents, and all the files are root:root exert gravity.db which is pihole:pihole... perhaps this is the key of everything

[MoJo2600]

Hm... checked my cluster and it is as follows:

root@pihole-9db5f45c9-cxrsd:/etc/pihole# ls -la | grep db
-rw-rw-r-- 1 pihole pihole  41885696 Jun  9 06:30 gravity.db
-rw-r--r-- 1 root   root   354758656 Jun  9 08:53 pihole-FTL.db

But to be sure. You use the GUI to add a domain to black/whitelist and the GUI shows you an error? Not like it is on my cluster: Adding Domain?

[i5Js]

Same here @MoJo2600 and yes, I’m using the GUI.

I’ve changed the permissions but same results.

[MoJo2600]

There is a issue open at pihole.

There seem to be two solutions on the pihole side right now. One is, that the webserver has the wrong rights, but I don't see how this could be the issue here, because our configuration should be the same.
The second thing is, that a restart would help as pihole seems to repair itself during startup.

I will try and do a complete fresh deployment of pihole and see if the error is there when i do this. Maybe if someone of you would like to try if the problem goes away after a reboot? You could kill the pod and see if it is still the same after restart. At least we would know that this is a pihole issue and not an issue with the chart.

[i5Js]

I’ve already done, no success.

Mine is an upgrade from v4, I’ll try to make a fresh installation...

[i5Js]

I’ve also tried pihole -r, also without success.

[MoJo2600]

I tried it right now with this minimal values.yaml on the current master commit and it is still working for me:

persistentVolumeClaim:
  enabled: true
  storageClass: glusterfs-storage

adminPassword: pihole

serviceTCP:
  loadBalancerIP: 192.168.178.251
  annotations:
    metallb.universe.tf/allow-shared-ip: pihole2-svc
  type: LoadBalancer

serviceUDP:
  loadBalancerIP: 192.168.178.251
  annotations:
    metallb.universe.tf/allow-shared-ip: pihole2-svc
  type: LoadBalancer

helm install -f values2.yaml pihole2 mojo2600/pihole

The only differences I see are, that you are using cloudflare, but i don't see how this would cause an issue and that you are using nfs and I use glusterfs. And mine is a fresh install not an upgrade.

But right now I'm out if ideas what the issue could be.

[MoJo2600]

I even tried an upgrade from 4.4 to 5.0. Works without issues (at least for me :/). I added to the blacklist and whitelist on 4.4, upgraded to 5 and the old entries were there and i was able to add new domains.

[i5Js]

Can you make a test? Add some domains in the value file and try again, I think the problem could be there. Regards.

…

On 9 Jun 2020, at 17:07, Christian Erhardt ***@***.***> wrote: I even tried an upgrade from 4.4 to 5.0. Works without issues. I added to the blacklist and whitelist on 4.4, upgraded to 5 and the old entries were there and i was able to add new domains. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIFKG4ZECOO6P6O35NUJVLRVZF4VANCNFSM4L5R7Q4Q>.

[MoJo2600]

I tried it, but it is still working.

I created a values file with whitelist and blacklist entries. Then i deployed version 1.7.4 with PiHole 4.4. I am not able to add something to blacklist and whitelist. But I expected this, because the mounted configmap for the whitelist/blacklist file is read-only. Prior to 5.0 you have to update the configmap and restart the container.
Then i upgraded this deployment to 1.7.7 with pi-hole 5.0. The entries got converted to the new gravity database and now I'm able to add entries to the whitelist/blacklist, because it is now using the gravity database, which is writable in my case.

The new values.yaml:

persistentVolumeClaim:
  enabled: true
  storageClass: glusterfs-storage

adminPassword: pihole

whitelist:
    - steam.com

blacklist:
    - foo.bar 

serviceTCP:
  loadBalancerIP: 192.168.178.251
  annotations:
    metallb.universe.tf/allow-shared-ip: pihole2-svc
  type: LoadBalancer

serviceUDP:
  loadBalancerIP: 192.168.178.251
  annotations:
    metallb.universe.tf/allow-shared-ip: pihole2-svc
  type: LoadBalancer

My commands for testing:

helm install -f values.yaml --version 1.7.4 pihole2 mojo2600/pihole <- update of whitelist/blacklist not possible
helm upgrade -f values.yaml pihole2 mojo2600/pihole <- update of whitelist/blacklist works

[r1cebank]

One sec, you mean you did it OUTSIDE, meaning you changed it in the host mounted directory for the PV?

[i5Js]

Exactly...

[MoJo2600]

Then I did read it right in another post. They were doing something similar. Could maybe someone check the acls of the file on the host machine? Maybe this will show something?

[r1cebank]

i tried using the acl solution in the post, didn’t help much.

[i5Js]

I'm going to make a new test: empty pv with new files then change the owners and lets see. I'll be back. :)

[i5Js]

My test:
** Create a folder, dns, where will host the pv, and changed the ownership to www-data
** Installed from scratch, the folder's ownership changed from www-data to pihole. First attempt, didn't work.
** Changed the ownership of dns to www-data, new attempt, didn't work.
** Changed the ownership of gravity.db to www-data, new attempt, works.
** Changed the ownership of dns to other user but gravity.db remains on www-data, new attempt, didn't work.
** Changed the ownership of dns to www-data, new attempt, works.

So my conclusions, the folder which mount the PV and gravity.db needs to be owned www-data:www-data.

Happy blocking!

[Gory19]

My test:
** Create a folder, dns, where will host the pv, and changed the ownership to www-data
** Installed from scratch, the folder's ownership changed from www-data to pihole. First attempt, didn't work.
** Changed the ownsership of dns to www-data, new attempt, didn't work.
** Changed the ownsership of gravity.db to www-data, new attempt, works.
** Changed the ownsership of dns to other user but gravity.db remains on www-data, new attempt, didn't work.
** Changed the ownsership of dns to www-data, new attempt, works.

So my conclusions, the folder which mount the PV and gravity.db needs to be owned www-data:www-data.

Happy blocking!

OMG IT’S WORKS ! I love you :D

[i5Js]

It was personal :D

[r1cebank]

Yes, I can confirm the above method works, I am using nfs-provisioner with k3s, had to change the ownership for gravity.db and the data folder to be owned www-data for it to work. Thank you @i5Js

[MoJo2600]

Okay, but are there any ideas how we could fix this already during setup? Should we create a pull request on the docker repository? Or is there anything to prevent this somehow?

[i5Js]

For me has no sense. I mean, why with a pv is necessary change the permissions, because with the internal storage is not needed. And why, if www-data belongs to pihole group, you can’t write into the db. I don’t understand it Obtener Outlook para iOS<https://aka.ms/o0ukef>

…

________________________________ De: Christian Erhardt <[email protected]> Enviado: Thursday, June 18, 2020 8:45:51 AM Para: MoJo2600/pihole-kubernetes <[email protected]> Cc: i5Js <[email protected]>; Mention <[email protected]> Asunto: Re: [MoJo2600/pihole-kubernetes] Imposible to add more domains to whitelist or blocklist. (#39) Okay, but are there any ideas how we could fix this already during setup? Should we create a pull request on the docker repository? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#39 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAIFKG26QGWWUTE2YIJRGC3RXGZZ7ANCNFSM4L5R7Q4Q>.

[11jwolfe2]

When running the helm install command and watching the log I can see this. Is there a way to fix it?

chown: changing ownership of '/etc/pihole/pihole-FTL.conf': Operation not permitted
chown: cannot access '': No such file or directory
chmod: cannot access '': No such file or directory
chown: changing ownership of '/etc/pihole': Operation not permitted
chown: cannot access '/etc/pihole/dhcp.leases': No such file or directory
chown: changing ownership of '/etc/pihole/gravity.db': Operation not permitted

Why is it not permitted. I am using a persistent volume on a nfs share for storage.

---

Issue solved. I was using an Open Media Vault for my persistent volumes on a NFS share. I changed the settings of the share to (rw,no_root_squash,insecure,async,no_subtree_check,anonuid=1000,anongid=1000) and now it works.

Fixed GUI issue by navigating to persistant volume data and running
sudo chown -R www-data:www-data [filename]

verified with
ls -l [filename]

all files show user and group ass www-data

[brnl]

Manually changing the ownership on /etc/pihole and /etc/pihole/gravity.db work temporarily for me. As soon as I update gravity.db via the webgui (http://pi.hole/admin/gravity.php), the ownership of /etc/pihole/gravity.db has been reset to pihole:pihole.

I'm also running a PersistentVolumeClaim on NFS.

Edit[0]: I just tried setting the primary group for user pihole to www-data but that doesn't work:

$ usermod -g www-data -G pihole pihole
$ groups pihole
pihole : www-data pihole

Edit[1]: Setting the permissions to 666 (rw-rw-rw-) with the owner on /etc/pihole still on www-data:www-data also works! But this is also overwritten with a gravity update, unfortunately.

The weird thing for me is that user www-data is member of the group pihole:

$ groups www-data
www-data : www-data pihole

... but still doesn't have write-permissions on gravity.db:

$ sudo -u www-data touch /etc/pihole/gravity.db
touch: cannot touch '/etc/pihole/gravity.db': Permission denied

[brnl]

Fixed!

The problem is in the NFS server configuration!

TL;DR:

Remove --manage-gids from the RPCMOUNTDOPTS in the file /etc/default/nfs-kernel-server on the NFS server and restart the nfs-kernel-server service.

Research

So I found out that if user www-data had pihole as the primary group, I was able to write the gravity.db. As soon as I made www-data primary again and pihole the secondary group again, the permission was denied. However, if I did the same on the NFS server (by adding group 999 as a secondary group to user www-data), all was fine!

So now I knew it had to do something with the NFS communication. After some DuckDuckGo-ing I found this quote:
NFS permission problem with secondary groups

rpc.mountd(8) - rpc.mountd - NFS mount daemon

-g or --manage-gids
Accept requests from the kernel to map user id numbers into lists of group id numbers for use in access control. An NFS request will normally (except when using Kerberos or other cryptographic authentication) contains a user-id and a list of group-ids. Due to a limitation in the NFS protocol, at most 16 groups ids can be listed. If you use the -g flag, then the list of group ids received from the client will be replaced by a list of group ids determined by an appropriate lookup on the server. Note that the 'primary' group id is not affected so a newgroup command on the client will still be effective. This function requires a Linux Kernel with version at least 2.6.21.

This means that when --manage-gids is passed, the NFS server will try to replace the secondary groups with 'an appropriate lookup on the server'. I'm not 100% sure what that means, but in our situation it had undesired effects.

Fix

So to fix our permissions problem here, I have edited my /etc/default/nfs-kernel-server file on the NFS server and commented the line RPCMOUNTDOPTS="--manage-gids".

Now it works with a fresh install with values.yml PVC:

persistentVolumeClaim:
  enabled: true
  storageClass: nfs-client
  accessModes:
    - ReadWriteOnce

And the default file permissions:

root@pihole-xxxxxxxxxx-xxxxx:/# ls -lahF /etc/pihole/
total 91M
drwxrwxr-x 3 pihole pihole 4.0K Sep 30 05:50 ./
drwxr-xr-x 1 root   root   4.0K Sep 30 05:46 ../
[...]
-rw-rw-r-- 1 pihole pihole  67M Sep 30 05:47 gravity.db
[...]

Hope this helps!

Note: The config file also recommends to read http://wiki.debian.org/SecuringNFS, so that's a good next step. :-)

PS: Thanks to @i5Js, your research helped a lot to pinpoint the exact problem!

[MoJo2600]

@brnl You are my hero! I spent hours to try to find a solution. Can anybody of the others try the solution and report back please?

[i5Js]

Awesome @brnl works flawless now... I modified the nfs-kernel-server file and perform a gravity update using the web-ui and the owner and permissions remains and of course it is still working.

Many thanks for your knowledge here, really help me to understand which was the issue.

[r1cebank]

Thanks @brnl for your solution, I modified the config and did a fresh reinstall of pi-hole with nfs storage client, it works now 👍

[brnl]

Glad I could help, guys! 👍

[MoJo2600]

Thanks for resolving this issue, finally i can close it. See @brnl comment for a solution to this issue.

[11jwolfe2]

Does anyone have an idea how to do this for an Open Media Vault NFS share?

[brnl]

@11jwolfe2

Edit[0]: Nope never mind. But this might answer your question: https://forum.openmediavault.org/index.php?thread/17674-rpcmountdopts-configure-port/

To override the default ("--manage-gids") you set an empty environment variable: export OMV_NFSD_MOUNTDOPTS=" "
The space is required because else it will reset to the default again. Where you have to set this variable, I don't know. Please refer to the documentation for that. Edit[1] This might help! ;-)

[plsnotracking]

I'm using a simple manual storage, my setup doesn't have anything to do with NFS Share.

When I reinstall the new setup with a helm installation, I loose all my dhcp.leases and setupVars.conf

I've hopped on to the container and have changed ownership of all the folders.

total 6724
drwxrwxr-x 3 www-data www-data    4096 Oct 22 23:59 .
drwxr-xr-x 1 root     root        4096 Oct 22 23:52 ..
-rw-r--r-- 1 www-data www-data      18 Oct 22 23:53 GitHubVersions
-rw-r--r-- 1 www-data www-data     118 Oct 22 23:26 adlists.list
-rw-r--r-- 1 www-data www-data       0 Oct 22 23:30 dhcp.leases
-rw-r--r-- 1 www-data www-data     596 Oct 22 23:52 dns-servers.conf
-rw-rw-r-- 1 www-data www-data 5050368 Oct 22 23:52 gravity.db
-rw-r--r-- 1 www-data www-data 1137892 Oct 22 23:52 list.0.raw.githubusercontent.com.domains
-rw-r--r-- 1 www-data www-data  594616 Oct 22 23:20 list.1.mirror1.malwaredomains.com.domains
-rw-r--r-- 1 www-data www-data      48 Oct 22 23:52 local.list
-rw-r--r-- 1 www-data www-data      20 Oct 22 23:52 localbranches
-rw-r--r-- 1 www-data www-data      41 Oct 22 23:52 localversions
drwxr-xr-x 2 www-data www-data    4096 Oct 22 23:20 migration_backup
-rw-r--r-- 1 www-data www-data       0 Oct 22 23:20 pihole-FTL.conf
-rw-r--r-- 1 www-data www-data   45056 Oct 22 23:58 pihole-FTL.db
-rw-r--r-- 1 www-data www-data     729 Oct 22 23:59 setupVars.conf
-rw-r--r-- 1 www-data www-data     732 Oct 22 23:52 setupVars.conf.update.bak

I keep seeing this error at boot in the logs.

chown: cannot access '': No such file or directory
chmod: cannot access '': No such file or directory

Here's my setup guide I've used:
https://kauri.io/68-selfhost-pihole-on-kubernetes-and-block-ads-and/5268e3daace249aba7db0597b47591ef/a

Here's my values.yml

# Default values for pihole.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1

image:
  repository: "pihole/pihole"
  tag: v5.1.2
  pullPolicy: IfNotPresent

serviceTCP:
  type: LoadBalancer
  externalTrafficPolicy: Local
  #loadBalancerIP: ""
    # a fixed LoadBalancer IP
  annotations:
    # metallb.universe.tf/address-pool: network-services
    metallb.universe.tf/allow-shared-ip: pihole-svc

serviceUDP:
  type: LoadBalancer
  externalTrafficPolicy: Local
  loadBalancerIP: ""
    # a fixed LoadBalancer IP
  annotations:
    # metallb.universe.tf/address-pool: network-services
    metallb.universe.tf/allow-shared-ip: pihole-svc

virtualHost: pi.hole

ingress:
  enabled: false
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  path: /
  hosts:
    # virtualHost (default value is pi.hole) will be appended to the hosts
    - chart-example.local
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #     #- virtualHost (default value is pi.hole) will be appended to the hosts
  #      - chart-example.local

# Probes configuration
probes:
  # probes.liveness -- Configure the healthcheck for the ingress controller
  liveness:
    enabled: true
    initialDelaySeconds: 60
    failureThreshold: 10
    timeoutSeconds: 5
  readiness:
    enabled: true
    initialDelaySeconds: 60
    failureThreshold: 3
    timeoutSeconds: 5

resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  # limits:
  #  cpu: 100m
  #  memory: 128Mi
  # requests:
  #  cpu: 100m
  #  memory: 128Mi

persistentVolumeClaim:
  # set to true to use pvc
  enabled: true
  # set to true to use you own pvc
  existingClaim: "pihole"
  # annotations: "pihole"

  accessModes:
    - ReadWriteOnce
  size: "500Mi"
  ## If defined, storageClassName: <storageClass>
  ## If set to "-", storageClassName: "", which disables dynamic provisioning
  ## If undefined (the default) or set to null, no storageClassName spec is
  ##   set, choosing the default provisioner.  (gp2 on AWS, standard on
  ##   GKE, AWS & OpenStack)
  ##
  # storageClass: "-"

  ## If subPath is set mount a sub folder of a volume instead of the root of the volume.
  ## This is especially handy for volume plugins that don't natively support sub mounting (like glusterfs).

  ## subPath: "pihole"

nodeSelector:
  k3s.io/internal-ip: 192.168.0.199

tolerations: []

affinity: {}

# Administrator password when not using an existing secret (see below)
adminPassword: "admin"

# Use an existing secret for the admin password.
admin:
  existingSecret: "pihole-secret"
  passwordKey: "password"

# extraEnvironmentVars is a list of extra enviroment variables to set for pihole to use
extraEnvVars:
  TZ: America/Los_Angeles

# extraEnvVarsSecret is a list of secrets to load in as environment variables.
extraEnvVarsSecret: {}
  # env_var:
  #   name: secret-name
  #   key: secret-key

# default upstream DNS servers to use
DNS1: "127.0.0.1"
DNS2: "1.0.0.1"

antiaff:
  # set to true to enable antiaffinity (example: 2 pihole DNS in the same cluster)
  enabled: false
  # Here you can set the pihole release (you set in `helm install <releasename> ...`)
  # you want to avoid
  avoidRelease: pihole1
  # Here you can choose between preferred or required
  strict: true

doh:
  # set to true to enabled DNS over HTTPs via cloudflared
  enabled: true
  name: "cloudflared"
  repository: "crazymax/cloudflared"
  tag: latest
  pullPolicy: IfNotPresent
  envVars: {}
    # Here you can pass environment variables to the DoH container, for example:
    # TUNNEL_DNS_UPSTREAM: "https://1.1.1.2/dns-query,https://1.0.0.2/dns-query"

dnsmasq:
  upstreamServers: []
  # Here you can add upstream dns servers with. All lines will be added to the
  # pihole dnsmasq configuration.
  # The format should be like:
  # - server=/foo.bar/192.168.178.10
  # - server=/bar.foo/192.168.178.11

  customDnsEntries: []
  # Here you can add custom dns entries to override the
  # dns resolution with. All lines will be added to the
  # pihole dnsmasq configuration.
  # The format should be like:
  # - address=/foo.bar/192.168.178.10
  # - address=/bar.foo/192.168.178.11

  additionalHostsEntries: []
  # Dnsmasq reads the /etc/hosts file to resolve ips. You can add additional entries if you like
  # - 192.168.0.3     host4
  # - 192.168.0.4     host5


adlists: {}
  # If you want to provide blocklists, add them here.
  # - https://hosts-file.net/grm.txt
  # - https://reddestdream.github.io/Projects/MinimalHosts/etc/MinimalHostsBlocker/minimalhosts

whitelist: {}
  # If you want to provide whitelisted domains, add them here.
  # - clients4.google.com

blacklist: {}
  # If you want to have special domains blacklisted, add them here
  # - *.blackist.com

regex: {}
  # Add regular expression blacklist items
  # - (^|\.)facebook\.com$


webHttp: "80"
webHttps: "443"
hostNetwork: "false"
privileged: "false"

customVolumes:
  enabled: false
  config: {}
    # any volume type can be used here
    # hostPath:
    #   path: "/mnt/data"

monitoring:
  podMonitor:
    enabled: false
  sidecar:
    enabled: false
    port: 9617
    image:
      repository: ekofr/pihole-exporter
      tag: 0.0.9
      pullPolicy: IfNotPresent
    resources:
      limits:
        memory: 128Mi
      # requests:
      #  cpu: 100m
      #  memory: 128Mi

Really appreciate if I could persist my changes through updates in the future. thank you.

[arana198]

I didn't

Fixed!

The problem is in the NFS server configuration!

TL;DR:

Remove --manage-gids from the RPCMOUNTDOPTS in the file /etc/default/nfs-kernel-server on the NFS server and restart the nfs-kernel-server service.

Research

So I found out that if user www-data had pihole as the primary group, I was able to write the gravity.db. As soon as I made www-data primary again and pihole the secondary group again, the permission was denied. However, if I did the same on the NFS server (by adding group 999 as a secondary group to user www-data), all was fine!

So now I knew it had to do something with the NFS communication. After some DuckDuckGo-ing I found this quote: NFS permission problem with secondary groups

rpc.mountd(8) - rpc.mountd - NFS mount daemon
-g or --manage-gids
Accept requests from the kernel to map user id numbers into lists of group id numbers for use in access control. An NFS request will normally (except when using Kerberos or other cryptographic authentication) contains a user-id and a list of group-ids. Due to a limitation in the NFS protocol, at most 16 groups ids can be listed. If you use the -g flag, then the list of group ids received from the client will be replaced by a list of group ids determined by an appropriate lookup on the server. Note that the 'primary' group id is not affected so a newgroup command on the client will still be effective. This function requires a Linux Kernel with version at least 2.6.21.

This means that when --manage-gids is passed, the NFS server will try to replace the secondary groups with 'an appropriate lookup on the server'. I'm not 100% sure what that means, but in our situation it had undesired effects.

Fix

So to fix our permissions problem here, I have edited my /etc/default/nfs-kernel-server file on the NFS server and commented the line RPCMOUNTDOPTS="--manage-gids".

Now it works with a fresh install with values.yml PVC:

persistentVolumeClaim:
  enabled: true
  storageClass: nfs-client
  accessModes:
    - ReadWriteOnce

And the default file permissions:

root@pihole-xxxxxxxxxx-xxxxx:/# ls -lahF /etc/pihole/
total 91M
drwxrwxr-x 3 pihole pihole 4.0K Sep 30 05:50 ./
drwxr-xr-x 1 root   root   4.0K Sep 30 05:46 ../
[...]
-rw-rw-r-- 1 pihole pihole  67M Sep 30 05:47 gravity.db
[...]

Hope this helps!

Note: The config file also recommends to read http://wiki.debian.org/SecuringNFS, so that's a good next step. :-)

PS: Thanks to @i5Js, your research helped a lot to pinpoint the exact problem!

This didn't work for me but even if it did I was not comfortable doing this. I got it working by adding env variable

  extraEnvVars = {
    TZ                  = "UTC"
    PUID                = "1000"
    PGID                = "1000"
    PIHOLE_UID          = "1000"
    PIHOLE_GID          = "1000"
    WEB_UID             = "1000"
    WEB_GID             = "1000"
  }

The key was WEB_UID and WEB_GID needed to match filesystem's id and gid.

Hope this helps someone