Please follow the below template, it will help us to help you!
If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.
Expected Behaviour:
Statistics shown on landing page. Ability to see and modify lists under groups management tab.
-operating system
-hardware]_
Actual Behaviour:
Landing page shows no stats. The holding containers are shown for Total Queries, Queries blocked, and Percent blocked with no data.
Groups managenent page shows no entries. When attempting to add an entry, an error popup is shown.
Errors shown in /var/log/lighttpd/error.log
2020-09-23 19:33:32: (log.c.217) server started
2020-09-23 19:33:44: (mod_fastcgi.c.2543) FastCGI-stderr: PHP message: PHP Warning: Use of undefined constant SQLITE3_OPEN_READWRITE - assumed 'SQLITE3_OPEN_READWRITE' (this will throw an Error in a future version of PHP) in /var/www/html/admin/scripts/pi-hole/php/groups.php on line 26PHP message: PHP Fatal error: Uncaught Error: Class 'SQLite3' not found in /var/www/html/admin/scripts/pi-hole/php/database.php:42
2020-09-23 19:33:44: (mod_fastcgi.c.2543) FastCGI-stderr: thrown in /var/www/html/admin/scripts/pi-hole/php/database.php on line 42
2020-09-23 19:33:44: (mod_fastcgi.c.2543) FastCGI-stderr: PHP message: PHP Warning: Use of undefined constant SQLITE3_OPEN_READONLY - assumed 'SQLITE3_OPEN_READONLY' (this will throw an Error in a future version of PHP) in /var/www/html/admin/scripts/pi-hole/php/database.php on line 61PHP message: PHP Fatal error: Uncaught Error: Class 'SQLite3' not found in /var/www/html/admin/scripts/pi-hole/php/database.php:42
2020-09-23 19:21:23: (mod_fastcgi.c.2543) FastCGI-stderr: PHP message: PHP Warning: Use of undefined constant SQLITE3_OPEN_READWRITE - assumed 'SQLITE3_OPEN_READWRITE' (this will throw an Error in a future version of PHP) in /var/www/html/admin/scripts/pi-hole/php/groups.php on line 26PHP message: PHP Fatal error: Uncaught Error: Class 'SQLite3' not found in /var/www/html/admin/scripts/pi-hole/php/database.php:42
Do you have php{Version}-sqlite3 installed?
Add
These are the packages you need to run pihole fully operational
INSTALLER_DEPS=(dhcpcd5 git "${iproute_pkg}" whiptail dnsutils)
# Pi-hole itself has several dependencies that also need to be installed
PIHOLE_DEPS=(cron curl iputils-ping lsof netcat psmisc sudo unzip wget idn2 sqlite3 libcap2-bin dns-root-data libcap2)
# The Web dashboard has some that also need to be installed
# It's useful to separate the two since our repos are also setup as "Core" code and "Web" code
PIHOLE_WEB_DEPS=(lighttpd "${phpVer}-common" "${phpVer}-cgi" "${phpVer}-${phpSqlite}" "${phpVer}-xml" "${phpVer}-intl")
These are the packages you need to run pihole fully operational
Excluding dhcpcd5 and php-cgi, as php-fpm is used when you installed Pi-hole via dietpi-software. However, lets concentrate on clearly missing SQLite access for now.
Aside of assuring that php(I guess "7.3")-sqite3 is installed, also assure it is enabled: phpenmod sqlite3
And as I have no insights into the debug upload, which SBC (or VM/PC?) and which distro version (Stretch or Buster?) is it?
On Debian Stretch, we needed to apply Ondrej's PHP repo to be able to install PHP7.3, otherwise we would have needed to drop support for a large amount of software titles on Stretch which dropped PHP version support below 7.2, Nextcloud will even drop PHP7.2 support with their next release.
This repository switched the default PHP version from 7.3 to 7.4 meanwhile, which means PHP7.4 is installed with the meta packages (i.e. installing php-sqlite3 instead of php7.3-sqlite3). This is usually not an issue since dietpi-software as well as the Pi-hole installer (although we skip the webserver-related part anyway via --disable-install-webserver) install the explicit versioned packages instead of meta packages, if PHP was already installed. But there are a few Debian packages which pull the meta PHP packages explicitly as dependency, e.g. phpmyadmin, so either that way or when following any guide which states something like apt install php-<module_name>, one can end up with two concurrent PHP instances, with php CLI commands being linked to php7.4.
So while Lighttpd keeps using php7.3-fpm, phpenmod enables modules for PHP7.4 instead, that way at least it is thinkable that sqlite3 module is not enabled for the PHP version that Lighttpd uses.
@ottoxgam
Can you please run and paste the following:
grep -r php /etc/lighttpd/ # Identify which PHP version Lighttpd uses
dpkg -l | grep php # Identify which PHP packages are installed
ls -al /etc/php/7.[0-4]/*/conf.d/*sqlite* # Identify for which PHP versions the SQLite module is enabled
After searching around for a while I found this thread. Translated using google and ran everything. At some point, php7.3 was updated to 7.4, breaking the pihole dashboard. I can only assume it was when I updated my dietpi vm.
I did have to reinstall the packages that were removed, including: php7.3-cgi php7.3-cli php7.3-common php7.3-curl php7.3-fpm php7.3-gd php7.3-intl php7.3-json php7.3-mbstring php7.3-opcache php7.3-readline php7.3-sqlite3 php7.3-sqlite3-dbgsym php7.3-xml php7.3-zip
ii php-apcu 5.1.18+4.0.11-1+0~20200518.14+debian9~1.gbpa99079 amd64 APC User Cache for PHP ii php-common 2:76+0~20200511.26+debian9~1.gbpc9beb6 all Common files for PHP packages ii php7.3-cgi 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 server-side, HTML-embedded scripting language (CGI binary) ii php7.3-cli 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 command-line interpreter for the PHP scripting language ii php7.3-common 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 documentation, examples and common module for PHP ii php7.3-curl 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 CURL module for PHP ii php7.3-fpm 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 server-side, HTML-embedded scripting language (FPM-CGI binary) ii php7.3-gd 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 GD module for PHP ii php7.3-intl 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 Internationalisation module for PHP ii php7.3-json 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 JSON module for PHP ii php7.3-mbstring 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 MBSTRING module for PHP ii php7.3-opcache 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 Zend OpCache module for PHP ii php7.3-readline 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 readline module for PHP ii php7.3-sqlite3 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 SQLite3 module for PHP ii php7.3-sqlite3-dbgsym 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 Debug symbols for php7.3-sqlite3 ii php7.3-xml 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 DOM, SimpleXML, WDDX, XML, and XSL module for PHP ii php7.3-zip 7.3.22-1+0~20200909.67+debian9~1.gbpdd7b72 amd64 Zip module for PHP
ls -al /etc/php/7.[0-4]/*/conf.d/sqlite
I see your lighttpd.conf is the one from Pi-hole installer, means you installed Pi-hole via dietpi-software first and reconfigured it via pihole -r afterwards + selected to install Lighttpd via installer.
This at least breaks other web applications that run on the same web server, if installed (due to changed webroot) and it leads to some obsolete/doubled Lighttpd directives + php7.3-cgi is installed while we use php7.3-fpm.
So while it's not really an issue in most cases currently, I add the little reminder to NOT select installing Lighttpd when using pihole -r + reconfigure after having it installed via dietpi-software.
We just had a similar case on our GitHub and hence I wanted to add this to our docs.
Second:
To add multiple lines of code or logs beautifully for Discourse/Markdown, do:
``` #how to escape "`" in markdown?
line1
line2
``` #ignore these comments
So wrap code into three times apostrophe at a separate line. This is btw done automatically when you paste the code/log first, select all lines and then hit the "Preformatted text" button. Single apostrophe is only good for small single line code chuncks and line breaks are omitted inside which makes it difficult to read .
All provided images are Buster but of course there are still many users running older Stretch images. Yes I agree, that PHP transition caused many issues (many more on ARMv6 RPi models!) and I'll not going to implement such anymore, e.g. for providing PHP8 on Buster when it's stable on Bullseye. Instead software which drops PHP7.3 support in the future will be disabled within dietpi-software on Buster (and Stretch), unless an already installed PHP8 instance is found (manually done by user). At least that's the plan for now, we'll see if that causes less or more issues when for sure some users do the upgrade manually.
.
.