Something is bugging setting capabilities via systemd directives on Cloudkey's that have been upgraded to Buster:
About Linux capabilities:
$ man capabilities
[..]
CAPABILITIES(7) Linux Programmer's Manual CAPABILITIES(7)
NAME
capabilities - overview of Linux capabilities
DESCRIPTION
For the purpose of performing permission checks, traditional
UNIX implementations distinguish two categories of processes:
privileged processes (whose effective user ID is 0, referred
to as superuser or root), and unprivileged processes (whose
effective UID is nonzero). Privileged processes bypass all
kernel permission checks, while unprivileged processes are
subject to full permission checking based on the process's
credentials (usually: effective UID, effective GID, and sup‐
plementary group list).
Starting with kernel 2.2, Linux divides the privileges tradi‐
tionally associated with superuser into distinct units, known
as capabilities, which can be independently enabled and dis‐
abled. Capabilities are a per-thread attribute.
Capabilities list
The following list shows the capabilities implemented on
Linux, and the operations or behaviors that each capability
permits:
CAP_AUDIT_CONTROL (since Linux 2.6.11)
Enable and disable kernel auditing; change auditing
filter rules; retrieve auditing status and filtering
rules.
[..]
My Buster:
$ hostnamectl
[..]
Operating System: Raspbian GNU/Linux 10 (buster)
$ systemctl cat pihole-FTL.service
[..]
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_NET_ADMIN CAP_SYS_NICE CAP_IPC_LOCK CAP_CHOWN
Does below one report the version without errors?
pihole-FTL -v
If so, you could try hack capabilities on a file level.
For that, you could edit the systemd unit file for the pihole-FTL daemon with below one:
sudo systemctl edit --full pihole-FTL.service
Look for a line that says:
ExecStart=/usr/bin/pihole-FTL -f
And add below line above it:
ExecStartPre=setcap CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_NET_ADMIN,CAP_SYS_NICE,CAP_IPC_LOCK,CAP_CHOWN+eip "/usr/bin/pihole-FTL"
So it resembles below:
$ sudo systemctl edit --full pihole-FTL.service
[..]
ExecStartPre=/opt/pihole/pihole-FTL-prestart.sh
ExecStartPre=setcap CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_NET_ADMIN,CAP_SYS_NICE,CAP_IPC_LOCK,CAP_CHOWN+eip "/usr/bin/pihole-FTL"
ExecStart=/usr/bin/pihole-FTL -f
[..]
Save/exit and follow/tail the systemd journal live with below:
sudo journalctl --full --follow --unit pihole-FTL.service
In another shell session, restart the daemon with below one and check the journal for errors/warnings appearing:
sudo systemctl restart pihole-FTL.service
To check if it runs:
sudo systemctl status pihole-FTL.service
systemctl is-active pihole-FTL.service
pihole status
And on which ports its listening:
sudo ss -nltup | grep 'Netid\|pihole-FTL\|lighttpd'
Drawback is that you most likely lose the hack when you do a Pi-hole upgrade or repair.