Okay, so it seems you are both running non-standard configurations. Both times, your web server user is lacking group membership in the group pihole.
Not sure which user your web servers are running as (typical for lighttpd is www-data). Try to find out which is the correct web server user and add it to group pihole. Thereafter, restart your web server and try again. If this is not sufficient to communicate the new group membership (it should be), you might have to restart your system.
As you suggested, I added user www-data to group pi-hole and rebooted the Pi (rebooting the service didn't do anything). Now, I can use the tools in Group Management.
I can also add domains to the whitelist. But . . . for some reason, the whitelist doesn't show me the items that are on it, and even when it works, it gives me "Failure!" messages. If I try to add a new item that I know is not on the list, it says the following:
UPDATE: I cleared the cache in my browser, and everything showed up as expected. Thanks! UPDATE 2: I said in an earlier post that the entries from my previous install had not migrated. This was incorrect. They just weren't showing up until this issue was resolved.
This worked. I am using lighttpd. For those with a similar issue. I checked to see which users existed, as @DL6ER said the default user for lighttpd is www-data. I confimed by checking the /etc/passwd file that the user existed and added the user to the pihole group.
usermod -a -G pihole www-data
^^ will add the pihole group to the www-data user. You will need to use this command with an elevated account or with sudo.
But I also note that Pi-hole v4 worked fine when I installed it on a fresh Diet-Pi today. It was only after upgrading to v5 that the saving issue appeared. I'm assuming there's something different about how the web server user attempts to write to a database in v5 vs how it wrote to local files in the /etc/pihole directory in v4 and that's what's causing the error to appear.
I suspect that once v5 is out of Beta, the Diet-Pi devs will incorporate it into their software installer. I suppose it's also completely possible that this issue goes away when v5 is able to be installed fresh.
Yes, the difference is that v4.0 calls sudo pihole ... which does all the changes whereas v5.0 has a completely re-engineered security concept directly interacting with the database without having a script in the middle of the operations. This elegantly solves a lot of things where we had to do validations before, e.g., against bash command exploitation.
Many thanks for reporting. Yes this is a known issue with Pi-hole v5 on current DietPi and has been fixed already for the upcoming release.
If users choose to install the webserver manually, then it might even run as a different user, hence adding www-data to pihole group would not change something. Of course in very most cases it's www-data, but guessing too much and relying on it, is probably not he best solution. Instead a clear documentation about the needs might be better.
First it is asked whether to install the web interface, then it is asked whether to install webserver. Of course the second question does not make any sense if one already chose to not install the web interface, also practically in the script, choosing webserver has exactly zero effect when web interface is not chosen. The PR I linked also removes the webserver question when web interface was already deselected.
Now pihole does nothing, if you are not installing Lighttp.
The only things that are missing, and this only since Pi-hole v5 beta:
webserver permissions to access query database
PHP modules, i.e. php-intl, which is not part of most default PHP installs
Of course to have blocking page working as expected, the webserver needs to be configured to redirect 404 to it. And the admin web UI of course must be accessible by the webserver. But the blocking page is anyway not really recommended, at least not enabled by default and a performance penalty, and website access is somehow trivial.
IMO, if one already chooses to manually install and setup the webserver, I would skip really any related configure step. It can be wrong, it could even break things, if it does not match the manual system setup, or how it is/was intended.
PHP modules are btw a separate topic, since PHP has not really something to do with the webserver. But if a custom webserver setup is wanted, then a custom - probably custom compiled/package-less - PHP setup is present as well.