I think posts got a little tangled here. @jrmckinn Did you want to post these replies here? (They kind of look out of context).
@poolcactus There seems to be something related to permissions there.
See if uninstalling Pi-hole and re-installing from scratch fixes it.
You don't need to run it from root or with sudo.
The install scrips has internal checks for the sudo utility and it uses that when needed.
tried the uninstall, and reinstall.
pihole installed as expected. Then ran:
echo "FTLDNS" | sudo tee /etc/pihole/ftlbranch
pihole checkout core FTLDNS
with the result:
[i] Restarting services...
[✓] Starting lighttpd service
[✓] Enabling lighttpd service to start on reboot
[✓] Starting pihole-FTL service
[✓] Enabling pihole-FTL service to start on reboot
[✓] Deleting existing list cache
[✗] DNS service is not running
[✓] Starting DNS service
[✗] DNS resolution is not available
Error: Unable to complete update, please contact support
now reverted back to master:
sudo rm /etc/pihole/ftlbranch
pihole checkout master
resulting in: (working again)
[✓] Force-reloading DNS service
[✓] DNS service is running
[✓] Pi-hole blocking is Enabled
[i] The install log is located at: /etc/pihole/install.log
Update Complete!Since you are on master right now, that means that dnsmasq is installed and running.
The upgrade to FTLDNS beta is failing because obviously DNS resolution does not work (during upgrade).
What you can do is remove (again) dnsmasq, edit the resolv.conf file and add a public DNS instead of the 127.0.0.1 and THEN checkout the FTLDNS.
Once completed, remember to pihole checkout web FTLDNS also.
Tried your last comment, but it resulted in the same: DNS not working.
I think it is an permission issue for pihole-FTL. My syslog shows:
pihole pihole-FTL[6476]: dnsmasq: failed to create listening socket for port 53: Permission denied
Jun 19 22:17:18 pihole dnsmasq[6534]: failed to create listening socket for port 53: Permission denied
Jun 19 22:17:18 pihole dnsmasq[6534]: FAILED to start up
does the user that makes the changes have permissions to open sockets on ports <1000?
I've read in another topic, that pihole-FTL is ran by the user 'pihole', not root.?
try running
sudo setcap CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_NET_ADMIN+eip /usr/bin/pihole-FTL
and then restart FTLDNS.
That is correct. If commands requiring elevated privileges are needed, they are invoked with sudo.
pi@pihole:~ $ sudo setcap CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_NET_ADMIN+eip /usr/bin/pihole-FTL
Failed to set capabilities on file `/usr/bin/pihole-FTL' (Operation not supported)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file
It seems that in your case pihole user can't bind ports bellow 1000.
You could always execute/start the pihole-FTL.service as root. That should work, but it's inconvenient to say the least ...
Tagging @DL6ER for awareness.
That's a route I'm not willing to take.
I ran the command as root and got the following:
root@pihole:~# setcap CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_NET_ADMIN+eip /usr/bin/pihole-FTL
Failed to set capabilities on file `/usr/bin/pihole-FTL' (Operation not supported)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file
Makes me believe, there is something wrong with the pihole-FTL released file?
Not really (I run 3 instances of FTLDNS beta without any issues).
It has something to do with the environment you're running it in, most likely.
What Platform are you running it on ?
rasbian stretch on Pi V2
Raspbian should have capabilities support, but it is odd that it isn't working. Try:
sudo setcap CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_NET_ADMIN+eip /usr/bin/pihole-FTL
This is unlikely, however it's not impossible that the file got damaged on your system. Please run
ls -lh /usr/bin/pihole-FTL
sha1sum /usr/bin/pihole-FTL
and tell us the output.
pi@pihole:~ $ sudo setcap CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_NET_ADMIN+eip /usr/bin/pihole-FTL
Failed to set capabilities on file `/usr/bin/pihole-FTL' (Operation not supported)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file
pi@pihole:~ $ ls -lh /usr/bin/pihole-FTL
-rwxr-xr-x 1 root root 1.4M Jun 19 22:28 /usr/bin/pihole-FTL
pi@pihole:~ $ sha1sum /usr/bin/pihole-FTL
cb0b59a1b2fa470c23301767d4002c956426cab7 /usr/bin/pihole-FTL
This matches “pihole-FTL-arm-linux-gnueabi”
So you have the correct file and everything is as expected except that setting capabilities aren't working on your system.
Are you running a custom kernel or file system?
No, the only curious thing there might be, is that I'm running a remote filesystem over NFS.
pi@pihole:~ $ mount
10.1.1.22:/piroot/pihole_jessie_rfs on / type nfs (rw,noatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.1.1.22,mountvers=3,mountproto=tcp,local_lock=all,addr=10.1.1.22)
I'm now not sure if NFSv3 has Linux Capabilities support? I'll try to upgrade to NFSv4..
What file system do you use on the remote hard drive?
It is run with an EXT4 FS.
Then I agree that it must be the NFS part that is causing trouble here. There are a few threads online.
@DL6ER, Agree that NFS is the culprit, and to test this theory I have moved my /usr/bin to the SD-card and ran the above command again and that works like a charm! Also possibly my containment for now.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.