Web interface isn't accepting input

Help Community Help
1

I'm on DietPi (Debian based) and am using nginx as a webserver. I also used their script to install Pi-hole. But I strongly doubt that that's the issue.

Expected Behaviour:

I enter some settings on the webinterface and click on save. I expect those settings to be applied and be saved.
If I click on Generate Debug Log, I expect a debug log to be generated and the token to be displayed.

Actual Behaviour:

Settings aren't applied not saved. If I change the theme to dark layout, the dark layout is applied for like 10 seconds and then jumps back to bright layout.
Clicking on Generate Debug Log doesn't seem to do anything. The button is just grayed out, but no text is coming up.

Debug Token:

jgsv2eb8kt

Furthermore the /var/log/nginx/error.log says:

2020/10/16 12:27:58 [error] 772#772: *694 FastCGI sent in stderr: "PHP message: PHP Warning:  Executing sudo pihole status web failed. in /var/www/html/admin/scripts/pi-hole/php/func.php on line 79" while reading upstream, client: 192.168.1.10, server: nullnullsix, request: "POST /admin/settings.php?tab=api HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.3-fpm.sock:", host: "nullnullsix", referrer: "http://nullnullsix/admin/settings.php?tab=api"
2020/10/16 12:27:58 [error] 772#772: *694 FastCGI sent in stderr: "PHP message: PHP Warning:  Executing sudo pihole -a -e 'my@email.address' failed. in /var/www/html/admin/scripts/pi-hole/php/func.php on line 79PHP message: PHP Warning:  Executing sudo pihole -a layout boxed failed. in /var/www/html/admin/scripts/pi-hole/php/func.php on line 79" while reading upstream, client: 192.168.1.10, server: nullnullsix, request: "POST /admin/settings.php?tab=api HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.3-fpm.sock:", host: "nullnullsix", referrer: "http://nullnullsix/admin/settings.php?tab=api"

If I had to guess I'd say that right settings are the problem. Maybe some user is not member of a group where it is supposed to be. Any ideas?

2

Nginx is not a supported web server for Pi-hole. Also, DietPi has a different implementation of the web server. Your best source for a solution may be here:

3

I'm quite sure that nginx is not the reason for that problem. Are you sure you can't tell me why sudo pihole status could fail?

4

Can you try to call the command manually:

sudo pihole status web

The web server user should have sudo permissions:

cat /etc/sudoers.d/pihole

I'll so a test install with Nginx to see if there is a general issue.

5

I solved the problem. The solution was to set the setuid-bit of /usr/bin/sudo via chmod u+s /usr/bin/sudo. www-data was correctly registered in the sudoers file but couldn't execute the sudo command because of the missing bit.

My question is now: Do you have an idea why this bit was missing? Could it be a bug in DietPi?
I converted my root file system to btrfs a while ago. My only other explanation for the missing bit is that the conversion caused the loss of a bit.

6

Interesting, we set this actively during image creation: DietPi/PREP_SYSTEM_FOR_DIETPI.sh at 0503b98013b0783e22be309d03eb44adf3c871f1 · MichaIng/DietPi · GitHub

And when installing sudo freshly (e.g. purge + install), it is the default as well, I mean it's the concept how sudo works :thinking:.

Which device do you use what was the initial image?

cat /var/lib/dietpi/.dietpi_image_version
7

I'm using a Raspberry Pi 4 and the 64-bit Image downloaded from your website.

cat /var/lib/dietpi/.dietpi_image_version displays this:

G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=31
G_DIETPI_VERSION_RC=2
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

Now I'm quite sure that I screwed up during the btrfs partition creation. I formatted the partition manually and copied the data from the original ext4 partition to btrfs. I should have used --preserve=all as argument for cp to keep things like a setuid-bit :man_facepalming:

@jfb @MichaIng Thank you for the help!

8

Ah yes that explains it :slightly_smiling_face:. cp -a is the way to go.

1 Like
9

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