some settings tabs often will not load

[tgaff]

Versions

• Pi-hole: Pi-hole version is v5.17.3 (Latest: v5.17.3)
• AdminLTE: web version is v5.21 (Latest: v5.21)
• FTL: FTL version is v5.24 (Latest: v5.24)

Platform

• OS and version: Debian GNU/Linux 11 (bullseye)

• Platform: pihole docker

Expected behavior

All tabs on the Settings page should load when clicked.

Actual behavior / bug

They do not load. Specifically the following tabs do not load:

• Web interface
• API
• Privacy
• Teleporter

But sometimes they do load. I think this may be related to a JS tab implementation. I haven't checked what tech is behind the pihole web app but inspecting the HTML when the problem is happening is showing that the active in and fade classes on the relevant panels are not swapping as I believe they should...possibly a race condition.

Steps to reproduce

Steps to reproduce the behavior:

1. Go to settings
2. click DHCP (may not be necessary but seems it happens most often from this starting point)
3. observe DHCP tab content displayed and DHCP tab is highlighted
4. click Web Interface
5. observe Web Interface content does not display but Web interface tab is highlighted.
   a. repeat for API, Privacy and Teleporter tabs
6. If you did not see the bug in the previous step then:
   a. click the System tab
   b. hard refresh (in Chrome on MacOS Cmd+Shift+R)
   c. observe system tab
   d. return to step 2 and repeat

Note that having the chrome dev tools open seemed to have a latching effect on the issue...though, given the intermittency, I'm not totally sure.

Debug Token

• URL: https://tricorder.pi-hole.net/d4TxAHVc/

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

I spent two days thinking this was a permissions issue and then a cookies issue. Now I think it's JS. If I still sound sane and someone wants to point me towards where the relevant source code is I'd be happy to take a first peek at it. 😅

Seen in

• Firefox: 121.0 (64-bit)
• chrome: Version 121.0.6167.160 (Official Build) (x86_64)
• safari Version 16.5 (17615.2.9.11.6, 17615)
• brave

[DL6ER]

Do you see any errors in the "Console" (check the developer tools you can summon using F12)?

[rdwebdesign]

One more question:

• Do you see the same behavior after disabling all browser extensions?

[tgaff]

Do you see any errors in the "Console" (check the developer tools you can summon using F12)?

No. I spent a fair bit of time looking at the networking section and then inspecting the page itself. Never once saw an error.

One more question:

• Do you see the same behavior after disabling all browser extensions?

I see it in incognito mode in both Brave and Firefox.

[tgaff]

Decided to try a different OS too. On Firefox Focus on Android 14 I get very similar behavior. The only difference I noted was that the "Web Interface" tab worked but API, Privacy and Teleporter still did not display. At least in 2 out of 3 tries.

(Note that I'm on the Privacy tab but seeing details from Web Interface, this is very similar but slightly different than what I saw on Desktop)

Also I've reproduced this with both the docker images:

• pihole/pihole:2023.02.1
• pihole/pihole:2024.01.0
• rlabinc/pihole-unbound:latest

[tgaff]

In addition I just realized that on some of those tabs text is cut-off. (seen in FF and Brave using both pihole/pihole:2024.01.0
rlabinc/pihole-unbound:latest)

This may be a separate issue.

[rdwebdesign]

Please, post your current compose file or docker run command used to start the container.

[rdwebdesign]

I just realized that on some of those tabs text is cut-off.
(...)
This may be a separate issue.

No... Actually this could explain what you see in the browser.

If the page is incomplete, one or more tabs will be incomplete.
The end of one tab could be "mixed" with other tab and javascript code will show a tab different than expected.

The real question is: What is causing this? Why the pages are broken?

You are trying with many different images, but no other users saw this behavior, so it is very unlikely the issue is on the images.

It must be something on your system.

Are you using a volume to store the web interface (/var/www/html/admin)?

[tgaff]

OK, I think you could be on to something.

In order to get past an error showing in a red banner at the top I set a couple of variables. Error: There was a problem applying your settings. PHP error (2): parse_ini_file(/etc/pihole/setupVars.conf): failed to open stream: Permission denied in /var/www/html/admin/settings.php:17

Specifically I set WEB_UID or PIHOLE_GID. They're marked Experimental in the docker README. Setting these allowed me to get past the error and save changes.

# https://hub.docker.com/r/pihole/pihole
version: "3"
# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
  pihole:
    container_name: pinhole
    hostname: pi.hole
    image: pihole/pihole:2024.01.0
    # For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      # - "67:67/udp" # Only required if you are using Pi-hole as your DHCP server
      - "80:80/tcp"
    environment:
      TZ: $TZ
      WEBPASSWORD: $PW
      WEB_UID: 1003
      PIHOLE_GID: 100
    # Volumes store your data between container upgrades
    volumes:
      - CHANGE_TO_COMPOSE_DATA_PATH/pihole/etc-pihole:/etc/pihole
      - CHANGE_TO_COMPOSE_DATA_PATH/pihole/etc-dnsmasq.d:/etc/dnsmasq.d
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    # cap_add:
    #  - NET_ADMIN # Required if you are using Pi-hole as your DHCP server, else not needed
    restart: unless-stopped
    
    networks:
      pihole_ipvlan:
        ipv4_address: 192.168.0.203

networks:
  pihole_ipvlan:
    external: true

Note: You can ignore CHANGE_TO_COMPOSE_DATA_PATH it's automatically substituted for a real path owned by appuser:users or 1003 100

If you can point me toward any documentation on the UID/GID settings it might help in further debugging. What I had known based on the README is:

• PIHOLE_UID and WEB_UID shouldn't be the same
• PIHOLE_GID and WEB_GID shouldn't be the same
• PIHOLE_UID and WEB_UID shouldn't conflict with values in the container.

Also the container UID/GIDs

• values in container for Groups are 0-60, 100, 65534, 101 and 1000(pihole)
• values in container for user ids are 0-13, 33 (www-data), 34, 38, 39, 41, 65534, 100 and 999(pihole)

There was technically a conflict with PIHOLE_GID being set to 100 (hosts's users account overlapping docker's users account) but I'm able to reproduce the issue even after removing PIHOLE_GID (and of course restarting) so I don't think that's it.

[PromoFaux]

There isn't any further documentation on those UID/GID variables. The Pull Request that introduced them is here: #982, maybe there is some relevant discussion that gives you some pointers.

One possible hint in here though, is that the files inside /etc/pihole/ should be owned by pihole:pihole. Did you try PIHOLE_UID: 1003 instead of WEB_UID?

Of course, what might actually turn out to be the simplest solution (given it's nearing complete-state) is switching to the v6 beta image tag :development-v6, which entirely gets rid of the WEB_[U|G]ID variables, owing to pihole-FTL becoming it's own web server. The entire image is a ground-up rewrite for v6. If you do, make sure you take a backup of your /etc/pihole mount before switching - as it will make irreversible config file changes.

[tgaff]

what might actually turn out to be the simplest solution (given it's nearing complete-state) is switching to the v6 beta image tag :development-v6

So far I can't reproduce the issue in :development-v6, likely because the tabs are just gone and each page loads separately. I'm using PIHOLE_UID and GID there. I like that it only needs 1 user, will continue testing it.

[tgaff]

There isn't any further documentation on those UID/GID variables. The Pull Request that introduced them is here: #982, maybe there is some relevant discussion that gives you some pointers.

I'll take a look at this soon. Thanks for pointing to it - I failed to find it earlier.

One possible hint in here though, is that the files inside /etc/pihole/ should be owned by pihole:pihole. Did you try PIHOLE_UID: 1003 instead of WEB_UID?

I tried a few other configs - probably should have written them down.

With PIHOLE_UID:1003 and PIHOLE_GID: 100 I get the banner error. Pretty clearly the web server's user also needs access to this file.

FWIW here's what the etc dir looks like in that case (from the host)

-rw-r--r--  1    0   0       0 Feb 16 15:29 custom.list
-rw-r--r--  1 1003 100       0 Feb 16 15:29 dhcp.leases
-rw-r--r--+ 1    0   0     651 Feb 16 15:29 dns-servers.conf
-rw-rw-r--+ 1 1003 100 9424896 Feb 16 15:29 gravity.db
-rw-rw-r--+ 1 1003 100   94208 Feb 16 15:29 gravity_old.db
-rw-r--r--+ 1    0   0 3333898 Feb 16 15:29 list.1.raw.githubusercontent.com.domains
-rw-rw-r--+ 1    0   0      95 Feb 16 15:29 list.1.raw.githubusercontent.com.domains.sha1
-rw-r--r--+ 1    0   0      65 Feb 16 15:29 local.list
-rw-r--r--  1    0   0     241 Feb 16 15:29 logrotate
drwxrwxr--+ 2    0   0    4096 Feb 16 15:29 migration_backup
-rw-rw-r--  1 1003   0     157 Feb 16 15:29 pihole-FTL.conf
-rw-rw-r--+ 1 1003 100   81920 Feb 16 15:36 pihole-FTL.db
-rw-r--r--  1    0   0     209 Feb 16 15:29 setupVars.conf
-rw-r--r--+ 1    0   0      27 Feb 16 15:29 setupVars.conf.update.bak
-rw-r--r--+ 1    0   0     378 Feb 16 15:29 versions

Similarly with PIHOLE_UID:1003 and WEB_GID:100 - same alert banner.

I'm not sure how that banner is persisted - even if I 777 the files in that directory I see the error banner. However I do see the setupVars.conf theme change when I change it from the webUI. That's seems weird to me.

All of the above is using the official 2024.01.0 image.

[tgaff]

I'm not sure how that banner is persisted - even if I 777 the files in that directory I see the error banner. However I do see the setupVars.conf theme change when I change it from the webUI. That's seems weird to me.

This got me thinking. I ended up inspecting the docker data directory a little bit more and recreated it without an ACL attached.
As of now I think this has no issue (banner, nor loading issue) when I set the following:

  PIHOLE_UID: 1003
  WEB_GID: 100 

Though the image with the following still has the intermittent loading issue...

      WEB_UID: 1003
      PIHOLE_UID: 1003
      PIHOLE_GID: 100

I don't understand how an ACL could cause a web-server to intermittently render only part of a page though and worry that I'm just having intermittent luck.

[StuartMorrisAU]

I just switched to using docker and had the same issue with the settings tabs sporadically not loading. I had created a user/group specifically for the web and assigned WEB_UID and WEB_GID in my .env file, but the settings UI kept breaking. I commented out those variables and the UI loaded OK. Regardless of whether I use these environment variables, /var/www/html/admin continues to be owned by root:root rather than www-data:www-data.

[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.

[tgaff]

Not sure if this should be closed or not. On the one hand it seems like it might be fixed in the development branch. On the other hand the behavior exhibited of the server rendering only parts of its templates in a somewhat random fashion may indicate a deeper issue. I don't see how that could be explained in full by permissions or ACLs since in general file-system permissions should make a file readable or not rather than an inconsistent "partly-readable". (Are two processes fighting over ownership?)

I don't have enough knowledge of the architecture of this project to even come close to anything that might explain it - I'm only extrapolating from the web world I've worked in. If it was one of my sites I would find the behavior suspicious enough to want to get to the bottom of it.

[splattergamesextended]

why was this issue closed? I just installed PiHole in Docker on my OMV machine and I'm getting more or less the same issue. There's a "fix" that doesn't help at all: creating the container without volumes in docker-compose.yml but that really doesn't help when I need a persistent install that survives updates (which PiHole designed in a way that you have to remove the container...). Just a handful of people who have/had the same issue with no real solution in sight. I don't know if I want to give EVERY user all privileges just to test out if that fixes anything, but I'm pretty certain these issues are related and should be addressed.

[splattergamesextended]

nevermind, this stems from the "wonky" mount points (maybe add that somewhere in the documentation anyone?).
The docker-compose.yml contained a ./etc-pihole:/etc/pihole and ./etc-dnsmasq.d:/etc/dnsmasq.d by default which DOES NOT WORK if you have "external media" attached, e.g. OMV which usually defaults to using other drives for docker. Solution was to replace the path with /srv/dev............./Path-to-config-folder and now PiHole runs like it is supposed to. Maybe this should be a pull request, put please add this information on the main page for install instructions so other people don't waste hours looking for permission problems!

[bangity]

Thank you to above!!!. Crazy this worked. I struggled to find a solution for months.

[splattergamesextended]

Thank you to above!!!. Crazy this worked. I struggled to find a solution for months.

If this is directed at me, no problem. Besides, check again if it REALLY works like it's supposed to. I had more issues still that I had to resolve. You can check this comment for a workaround.