Hi there,
I just updated Pi-hole and it asked me if I wanted to keep lighttpd. It recommended I disable it, so I did. Now the web interface won't load.
I tried editing /etc/pihole/pihole.toml by removing ipv6 references according to another post here in the forums (V6 web interface can't be loaded - #4 by IVOS.pro), but it didn't help.
I tried re-enabling lighttp, and that resulted in 403 errors.
Please help.
Your debug log shows Pi-hole's webserver to be configured and listening on ports 80 and 443, if only for IPv4:
*** [ DIAGNOSING ]: Ports in use
[✓] tcp:0.0.0.0:80 is in use by pihole-FTL
[✓] tcp:0.0.0.0:443 is in use by pihole-FTL
[webserver]
port = "80o,443os" ### CHANGED, default = "80o,443os,[::]:80o,[::]:443os"
As your debug log shows your network to have link-local IPv6 connectivity, chances are that clients are trying to access Pi-hole's UI via IPv6:
*** [ DIAGNOSING ]: Network interfaces and addresses
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 192.168.1.223/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
valid_lft 2591012sec preferred_lft 2591012sec
inet6 fe80:<redacted>43e/64 scope link noprefixroute
valid_lft forever preferred_lft forever
You can re-enable Pi-hole to listen on IPv6 as well, via webserver.port under All settings » Miscellaneous, or via CLI,:
sudo pihole-FTL --config webserver.port "80o,443os,[::]:80o,[::]:443os"
All settings is available in Expert mode only.
Correct. I tried accessing the web UI before I edited the /etc/pihole/pihole.toml to remove the ipv6 ports, and, as I said, and it didn't work, so it won't work if I put IPv6 ports back in.
No, I'm using IPv4. I've actually disabled IPv6 on my network.
Any other suggestions?
For example, why is there a 403 when I enable lighttp?
And, to be specific, the web ui is just timing out (with lighttp disabled). It doesn't return anything, it just keeps waiting.
Hi guys,
Any word on this, by chance? I still can't access my Pi-hole admin page.
Everything was fine before this most recent update.
Please help.
I just upgraded from v6.0.3 to v6.0.4 and now have no webserver running. When I upgraded to 6 (v6.0.3) I had to stop and disable lighttp to get things to work. This update was supposed to fix people's webserver issues, but it broke mine. After the last upgrade I should have known to wait, but after reading the release notes it seemed alright.
Your debug log shows you don't have GUAs, so your network has no public IPv6 connectivity. But your hosts still assign LLAs to themselves, as demonstrated by the quote from your debug log.
If such a host would connect to http://pi.hole/admin, it is very likely to request the AAAA record for pi.hole and then use the returned IPv6 address to connect to your Pi-hole.
Once you have re-enabled Pi-hole's webserver to listen on IPv6, please share the output of:
curl -sSLI http://192.168.1.223:80/admin
curl -sSLI http://[fe80::305f:232a:b122:c43e]:80/admin
Okay, I put the following back in:
port = "80o,443os,[::]:80o,[::]:443os" ### CHANGED, default = "80o,443os,[::]:80o,[::]:443os"
The result of curl -sSLI http://192.168.1.223:80/admin is:
HTTP/1.1 308 Permanent Redirect
Location: /admin/
Cache-Control: max-age=3600
Content-Security-Policy: default-src 'self' 'unsafe-inline';
X-Frame-Options: DENY
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: *
Content-Length: 0
Date: Tue, 25 Feb 2025 14:41:50 GMT
Connection: close
HTTP/1.1 302 Found
Location: /admin/login
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate, private, max-age=0
Expires: 0
Pragma: no-cache
Content-Security-Policy: default-src 'self' 'unsafe-inline';
X-Frame-Options: DENY
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Content-Type: text/html; charset=utf-8
Date: Tue, 25 Feb 2025 14:41:50 GMT
Connection: close
And curl -sSLI http://[fe80::305f:232a:b122:c43e]:80/admin returns:
curl: (7) Failed to connect to fe80::305f:232a:b122:c43e port 80 after 0 ms: Couldn't connect to server
Your IPv4 result would indicate that P-hole's web UI is accessible via IPv4.
Does http://192.168.1.223:80/admin bring up Pi-hole's login page?
What's the output of nslookup pi.hole?
And run from the machine that failed to curl the IPv6 address, what's the output of
ip -6 address show scope link
http://192.168.1.223:80/admin works and brings up the web GUI! That's great, thank you. I was trying to go to the following URL, which was failing (I guess because if the "https"?):
https://192.168.1.223/admin/
And ip -6 address show scope link returns nothing on my machine, but it returns the following on the Raspberry Pi:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::305f:232a:b122:c43e/64 scope link noprefixroute
valid_lft forever preferred_lft forever
And on my machine, nslookup pi.hole returns:
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: pi.hole
Address: 192.168.1.223
Name: pi.hole
Address: fe80::305f:232a:b122:c43e
But on the Raspberry Pi, nslookup pi.hole returns:
Server: 192.168.1.223
Address: 192.168.1.223#53
Name: pi.hole
Address: 192.168.1.223
Name: pi.hole
Address: fe80::305f:232a:b122:c43e
Those nslookup results for pi.hole look fine.
You should perhaps keep an eye on the machine with that 127.0.0.53 stub resolver:
It has used Pi-hole as upstream for that nslookup, but if it would be aware of other upstreams, it may by-pass Pi-hole via those at times.
If that would be the case, you'd had to adjust that stub resolver's DNS configuration.
As pi.hole returns A/IPv4 as well as AAAA/IPv6 records, that would support my explanaton how IPv6-capable clients in your network may fail to open Pi-hole's web UI when Pi-hole's webserver isn't listening on IPv6.
That would explain why curling the IPv6 address failed.
It would suggest that -in absence of your router not advertising a public IPv6 prefix- clients in your network may or may not have auto-assigned a link-local IPv6 for themselves.
For those that do, it would be of advantage to keep Pi-hole's webserver listening on IPv6 as well, for the reasons I've explained in my previous post.
Alternatively, if you absolutely want IPv6 to be gone from your Pi-hole machine, you could consider to remove Pi-hole's IPv6 webserver ports again, and in order to Pi-hole reply to AAAA requests with NODATA, disable IPv6 on that machine itself.
For the latter, you'd have to consult your machine's OS documentation and support, as exact steps for that would depend on your machine's OS and release.
With that knowledge, you should be able to access Pi-hole's web UI, whichever way you decide.
Thank you, I appreciate all your help and your detailed reply about IPv6.
I'm not very familiar with IPv6, and I have it mostly disabled on my router (running OpenWRT).
I suppose I'll just leave it the way it is, then.
Although, what exactly do you mean by:
Should I change it to the Raspberry Pi IP address, you mean? I think I have OpenWRT to announce the RPi DNS IP address to all clients upon connecting. Did I mis-configure something, do you think?
As for the RPI admin page, I think the problem was actually because I was trying to access https://192.168.1.223/admin/ with "https" (SSL/TLS). The browser times out. Since I didn't know what the problem was, I found a post on here that said someone fixed it by removing the IPv6 stuff, and I tried that but it didn't fix it.
When I run curl -sSLI https://192.168.1.223:80/admin (note the "https") on my machine, it returns:
curl: (35) OpenSSL/3.0.13: error:0A00010B:SSL routines::wrong version number
Whereas curl -sSLI http://192.168.1.223:80/admin works fine (as in my post above). Not sure what's going there. In a web browser, as I said, the SSL request just times out, but "http" works fine. I imagine that just has to do with the fact that I haven't configured an SSL cert for Pi-hole.
Anyway, doesn't really matter since I can access the admin web GUI again.
Thanks again!
Consider your nslookup result:
This shows that a DNS server at 127.0.0.53 has answered the DNS requests.
That server isn't Pi-hole, but a local DNS stub resolver on the machine that nslookup was run from (probably systemd-resolved).
That's perfectly OK, as long as that stub resolver is forwarding DNS requests to your Pi-hole exclusively.
From just one nslookup result, we can't be sure that it won't be aware of other DNS servers. You could consider to check that stub resolver's DNS configuration to be sure.
I'm pretty sure I have things configured correctly for DNS on my local machine, though, because when I configured OpenWRT to announce the RPI IP (and I'm using Unbound on that same RPI, btw), I read the way to do that is to configure (Linux) clients like that, with 127.0.0.53. It's been set up that way for a few years now, and has been working fine. All the clients on the network use the Unbound server, per my previous tests - and DNS is working.
All clients have been using the "announced" RPI IP via OpenWRT (the Unbound server on the RPi) when they connect to the network. And it definitely was working. But now when I go to the v6 of Pi-hole's admin Query Log page, I just noticed that I'm not seeing my DNS requests showing up at all... I was on seeing them fine on Pi-hole v5. I do see a few (too few) of Unbound's requests, however, but that's it. Very strange...
Here's the data (and that's all - there should be about 3-4 other clients showing up on here). This is after I rebooted the RPi and I guess Unbound queried an NTP server. But there's nothing else in the Query table on that page, when there definitely should be (this is data I cut and pasted from the Pihole web GUI, sorry for the formatting):
2025-02-25 22:57:59
PTR
e.3.4.c.2.2.1.b.a.2.3.2.f.5.0.3.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa 192.168.1.223 22.2 µs
2025-02-25 22:57:59
PTR
223.1.168.192.in-addr.arpa 192.168.1.223 29.6 µs
2025-02-25 22:57:59
PTR
e.3.4.c.2.2.1.b.a.2.3.2.f.5.0.3.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa 192.168.1.223 26.9 µs
2025-02-25 22:57:59
AAAA pool.ntp.org 192.168.1.223
2025-02-25 22:57:59
A pool.ntp.org 192.168.1.223
I also just tested going to a domain that I know is blocked by Pi-hole, and it appears to have blocked it, but it didn't show up on the Query Logs page... UPDATE 1: However, I just checked the logs via the Pihole web GUI and it is showing that it is blocking the things I expect to be blocked and it is showing my machine's IP as being observed.
UPDATE 2: Also, out of curiosity I went to the FTL log and it shows this:
2025-02-25 23:28:48.891 INFO Local URI: "/admin/img/favicons/favicon-16x16.png"
2025-02-25 23:29:00.072 ERROR SQLite3: statement aborts at 1: [BEGIN TRANSACTION IMMEDIATE] cannot start a transaction within a transaction (1)
2025-02-25 23:29:00.072 ERROR ERROR: SQL query "BEGIN TRANSACTION IMMEDIATE" failed: SQL logic error (SQLITE_ERROR)
2025-02-25 23:29:00.072 ERROR Storing devices in network table ("BEGIN TRANSACTION IMMEDIATE") failed
2025-02-25 23:30:00.071 ERROR SQLite3: statement aborts at 52: [DELETE FROM query_storage WHERE id IN (SELECT id FROM query_storage WHERE timestamp <= 1732663800 LIMIT (SELECT COUNT(*)/100 FROM query_storage));] database disk image is malformed (11)
2025-02-25 23:30:00.071 ERROR ERROR: SQL query "DELETE FROM query_storage WHERE id IN (SELECT id FROM query_storage WHERE timestamp <= 1732663800 LIMIT (SELECT COUNT(*)/100 FROM query_storage));" failed: database disk image is malformed (SQLITE_CORRUPT)
2025-02-25 23:30:00.071 WARNING Database /etc/pihole/pihole-FTL.db is damaged and cannot be used.
2025-02-25 23:30:00.071 ERROR delete_old_queries_in_DB() failed!
2025-02-25 23:30:00.071 ERROR SQLite3: statement aborts at 1: [BEGIN TRANSACTION IMMEDIATE] cannot start a transaction within a transaction (1)
2025-02-25 23:30:00.071 ERROR ERROR: SQL query "BEGIN TRANSACTION IMMEDIATE" failed: SQL logic error (SQLITE_ERROR)
2025-02-25 23:30:00.071 ERROR Storing devices in network table ("BEGIN TRANSACTION IMMEDIATE") failed
2025-02-25 23:31:00.069 ERROR SQLite3: statement aborts at 1: [BEGIN TRANSACTION IMMEDIATE] cannot start a transaction within a transaction (1)
2025-02-25 23:31:00.069 ERROR ERROR: SQL query "BEGIN TRANSACTION IMMEDIATE" failed: SQL logic error (SQLITE_ERROR)
2025-02-25 23:31:00.069 ERROR Storing devices in network table ("BEGIN TRANSACTION IMMEDIATE") failed
2025-02-25 23:31:28.020 INFO Local URI: "/admin/taillog"
2025-02-25 23:31:28.111 INFO Local URI: "/admin/scripts/js/taillog.js"
2025-02-25 23:31:53.556 INFO Local URI: "/admin/taillog"
2025-02-25 23:32:00.073 ERROR SQLite3: statement aborts at 1: [BEGIN TRANSACTION IMMEDIATE] cannot start a transaction within a transaction (1)
2025-02-25 23:32:00.074 ERROR ERROR: SQL query "BEGIN TRANSACTION IMMEDIATE" failed: SQL logic error (SQLITE_ERROR)
2025-02-25 23:32:00.074 ERROR Storing devices in network table ("BEGIN TRANSACTION IMMEDIATE") failed
2025-02-25 23:32:49.695 INFO Local URI: "/admin/taillog"
2025-02-25 23:33:00.074 ERROR SQLite3: statement aborts at 1: [BEGIN TRANSACTION IMMEDIATE] cannot start a transaction within a transaction (1)
2025-02-25 23:33:00.074 ERROR ERROR: SQL query "BEGIN TRANSACTION IMMEDIATE" failed: SQL logic error (SQLITE_ERROR)
2025-02-25 23:33:00.074 ERROR Storing devices in network table ("BEGIN TRANSACTION IMMEDIATE") failed
2025-02-25 23:33:23.913 INFO Local URI: "/admin/taillog"
This sounds like a problem:
2025-02-25 23:30:00.071 WARNING Database /etc/pihole/pihole-FTL.db is damaged and cannot be used.
Any way to fix this?
A post was split to a new topic: Unable to access web UI via port 80
We can force pi-hole to regenerate the FTL db by renaming it. you can use the command
sudo mv /etc/pihole/pihole-FTL.db /etc/pihole/pihole-FTL-damaged.db
Then try to restart the pi-hole.
Thank you, that worked. I now see the expected entries in the log again, and the FTL log is free of errors.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.