Disabling Pi-Hole doesn't disable it

[argeljoseph]

This is a: BUG

Details

In my a docker environment, even though the Pi-Hole is supposed to be disabled (in the attachment, chosen indefinitely) I then try to access sites that are blocked by Pi-Hole, and they are still blocked. I then try and click on settings (or you can try any other link within Pi-Hole), and somehow Pi-Hole is in enabled state.

Related Issues

• [*] I have searched this repository/Pi-hole forums for existing issues and pull requests that look similar

How to reproduce the issue

1. Environment data

• Operating System: (Not sure as using docker image)
• Hardware: QNAP TS-264
• Kernel Architecture:
• Docker Install Info and version:
  • Software source: docker
  • Supplimentary Software: n/a
• Hardware architecture:

2. docker-compose.yml contents, docker run shell command, or paste a screenshot of any UI based configuration of containers here
3. any additional info to help reproduce

These common fixes didn't work for my issue

• [*] I have tried removing/destroying my container, and re-creating a new container
• [*] I have tried fresh volume data by backing up and moving/removing the old volume data
• [*] I have tried running the stock docker run example(s) in the readme (removing any customizations I added)
• [*] I have tried a newer or older version of Docker Pi-hole (depending what version the issue started in for me)
• [*] I have tried running without my volume data mounts to eliminate volumes as the cause

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.

[rdwebdesign]

2. docker-compose.yml contents, docker run shell command, or paste a screenshot of any UI based configuration of containers here

Please:

1. post your compose file (or docker run command) used to start your container.
2. Generate and upload a debug log, then post here only the Token.

[lwsrbrts]

This may not be relevant but I landed here and saw this issue as I'd recently changed my pihole to use a compose file and discovered that any attempt to add new CNAMEs or temporarily disable blocking resulted in the same outcome as the OP ie. nothing happened.

After some digging through the container logs and additional searching relating to the errors from the container logs, it turned out that my use of the following entry in the compose file under the pihole service was causing my issue:

    security_opt:
      - no-new-privileges:true

As I understand it, this declaration prevents the container from using sudo which it needs. In my case I'm running the container on a Synology NAS which needs to be running dnsmasq.d as root (so I understand) - the issue may not happen even with the above declaration, if dnsmasq.d is running as pihole, but I can't test that in my scenario.

What I do know is that someone has seen this before so, if the OP's issue is also caused by this, I think it may be prudent to add a note to the README.md or draw attention to it somehow.

[argeljoseph]

1. post your compose file (or docker run command) used to start your container.
-- Unfortunately, I'm new to using QNAP, and instead used the GUI of the Container Station to create the container
2. Generate and upload a debug log, then post here only the Token
I was trying to generate the logs with the token, for some reason, that's also not running. I'll try and see if I can recreate the container and check what @lwsrbrts has mentioned.

[argeljoseph]

Hello @rdwebdesign , I was able to finally generate the debnug log. Here it is: https://tricorder.pi-hole.net/7NC2nFvN/

@lwsrbrts - not sure how I can do what you did with QNAP. I didn't use a docker compose to build the container... I tried rebuilding from scratch and still facing the issue