Blacklist and Whitelist not working


Please follow the below template, it will help us to help you!

Expected Behaviour:

Adding a domain to the whitelist or blacklist pages in the web admin page should allow/deny these domains.

Actual Behaviour:

I simply get a pop-up box below the field to add a domain that says “Failure! Something went wrong, see output below:” There is no output below it.

Debug Token:


I selected not to use lighttpd because I already have httpd(Apache) installed and simply used that instead.

Thank you for the help!


Posted correct token this time!


assigned Mcat12 #2


That token identifier does not exist.



Whoops! Well that’s embarrassing! Fixed it. Also saved the debug output to a file this time.



Check your apache logs for any PHP errors.



No errors, just a notice.

" Notice : Undefined variable: api in /var/www/html/admin/scripts/pi-hole/php/add.php on line 14"

I also just now noticed that the Status in the upper left of the admin panel says Unknown.



There was another user who was running into a similar issue, and submitted a patch which might fix this:



Hi, My patch can fix your PHP error/warnings, but I think you have a permission problem. In my case, under Debian, I have to change some Nginx & php-fpm directives (not your case) to make the Stats work. To make the stats work Pi-hole need access to some directories like /var/log… /proc… /sys… /var/run… /run… /dev… etc.



I have changed a few owners/groups, but not in any of the directories you’ve listed. I will poke around and see what restoring a few directories back to root does.


Just reread your post. My stats work just fine. The only things that do not seem to work are the features under Long-Term Data, the Status in the top left area (temp, load, and memory work fine) and the black/whitelisting features.

When I tried to access Long-Term Data >> Query Log, I got this error:

An unknown error occurred while loading the data.

Fatal error: Uncaught Error: Class ‘SQLite3’ not found in /var/www/html/admin/api_db.php:71
Stack trace:
#0 /var/www/html/admin/api_db.php(86): SQLite3_connect(true)
#1 {main}
thrown in /var/www/html/admin/api_db.php on line 71

I queried rpm and sqlite was installed, so maybe it is a permissions issue. If so, I have no idea where to start looking for it.



If it’s not finding sqlite, then make sure you have the PHP sqlite library installed. Debian’s package:

For an RPM based distro, you will probably need php-pdo


SqLite3 and json_encode() fault

Installing php-pdo fixed that issue. Thanks! Back to the white/blacklisting issue. I know it isn’t a permissions issue, at least within /etc/pihole because I (temporarily) changed the perms for that entire directory into 777. Still couldn’t black/whitelist. All other directories are stock Centos permissions.

I am probably going to set up a virtual machine and install pi-hole on a fresh install of centos. See what happens then.



Make a new debug token.



I successfully set up pi-hole on a virtual machine of Centos 7. I went with a minimal install with a gui so I could test it locally. Everything worked correctly so I assume pi-hole is fighting with some other service on my current machine. I will just reinstall centos on it after backing up things, install pi-hole, then one by one put all my other services back onto it.

Thanks for the help everyone!



Apparently, I cannot edit my post now because it was flagged (Is this because I am a new user?). I looked through the whole source and it appears the all Pi-Hole commands use the pihole binary. My binary is located at /usr/local/bin/pihole so I changed my sudoers file to %web ALL=(root) NOPASSWD: /usr/local/bin/pihole. Now, my setup works great and I don’t have to worry about giving full root access to the public by accident.



The post was flagged for including information that would be dangerous to use. Please remember that our users come from a wide variety of backgrounds and posting commands that are dangerous is not helpful as some users will copy the information without fully understanding the implications. Giving the httpd user full non-password root access to the filesystem is not advised and changing the ownership of the /etc/pihole directory can and will cause issues with the proper operation of the Pi-hole device.



That’s understandable. Feel free to edit my response to clarify why giving full access is dangerous and that you probably won’t need to change the owner of the config directory. Setting the proper user and sudoer config options should definitely be an option in the installer. I did not know Pi-Hole was trying to use sudo when I installed it, so my first thought was the installer didn’t set the right permissions for use with NGinx. I am going to find out how to make a bug report for Pi-Hole so this can be added to the installer.

While I understand the Pi-Hole does not officially support other webservers, but it doesn’t have to. It just has to give the user the option to choose a different user to install Pi-Hole under. I know how to edit NGinx’s config, I just didn’t know Pi-Hole used sudo commands as I was given zero indication of sudo being used when I installed the server.

I opened a bug report to add this feature at



Pi-hole’s installer does set the sudoer file correctly, just for lighttpd. We support lighttpd, not nginx.

1 Like

closed #21

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