pi-hole/docker-pi-holePublic

NotificationsYou must be signed in to change notification settings
Fork1.2k
Star10.5k

PiHole Broken after docker update to 20.10.14#1021

Locked Answeredbydschaper

whizzzkid asked this question inGeneral

whizzzkid

Mar 24, 2022

· 18 comments· 72 replies

AnsweredbydschaperReturn to top

Discussion options

whizzzkid
Mar 24, 2022
Sponsor

Versions

Pi-hole: v5.9 (pihole/pihole:latest)
AdminLTE: v5.11 (pihole/pihole:latest)
FTL: v5.14 (pihole/pihole:latest)

Platform

OS and version: Debin Buster
Platform:Docker:20.10.14

Expected behavior

Pihole service should start.

Actual behavior / bug

Startup script fails with:

Starting pihole-FTL (no-daemon) as piholepihole-FTL: No process foundStopping pihole-FTL

Steps to reproduce

Run pihole usingdocker-compose using:https://github.com/whizzzkid/home-infrastructure/blob/main/docker-compose.yaml#L158

Debug Token

I couldn't capture the debug as the image crashed

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

At first I thought it was a bad pihole update, but turns out it's a breakingdocker-ce update, downgrading todocker-ce=5:20.10.13~3-0~debian-buster fixed the issue.
The problem looks similar to:

You must be logged in to vote

Answered by dschaper

Mar 24, 2022

Update April 25th:

Due toa known issue with Docker and libseccomp <2.5, you may run into issues running2022.04 and later on host systems with an older version oflibseccomp2 (Such as Debian/Raspbian buster or Ubuntu 20.04, and maybeCentOS 7).

The first recommendation is to upgrade your host OS, which will include a more up to date (and fixed) version oflibseccomp.

If you absolutely cannot do this, some usershave reported success in updatinglibseccomp2 via backports on debian, or similar via updates on Ubuntu. You can try this workaround at your own risk

April 2nd: There is a new image2022.04.2beta. Can you folks try it and see if it's working for you?

March 30th at 1210: The lates…

View full answer

Replies: 18 comments 72 replies

Comment options

jbaldzer
Mar 24, 2022

Hi,
I can confirm this behaviour. This happened also after an update of docker to version 20.10.14
Error message:
FATAL ERROR in dnsmasq core: failed to create listening socket for port 53: Permission denied

Environment
Docker version 20.10.14, build a224086
Pi-hole:
Docker Tag [2022.02.1]
Pi-hole [v5.9]
FTL [v5.14]

Log output

[2022-03-24 07:32:48.711 3975M] Using log file /var/log/pihole-FTL.log[2022-03-24 07:32:48.711 3975M] ########## FTL started on c53f40441296! ##########[2022-03-24 07:32:48.711 3975M] FTL branch: master[2022-03-24 07:32:48.711 3975M] FTL version: v5.14[2022-03-24 07:32:48.711 3975M] FTL commit: 52e6b95[2022-03-24 07:32:48.711 3975M] FTL date: 2022-02-12 19:58:34 +0000[2022-03-24 07:32:48.711 3975M] FTL user: pihole[2022-03-24 07:32:48.711 3975M] Compiled for x86_64 (compiled on CI) using gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516[2022-03-24 07:32:48.712 3975M] Creating mutex[2022-03-24 07:32:48.712 3975M] Creating mutex[2022-03-24 07:32:48.713 3975M] Starting config file parsing (/etc/pihole/pihole-FTL.conf)[2022-03-24 07:32:48.713 3975M]    SOCKET_LISTENING: only local[2022-03-24 07:32:48.714 3975M]    AAAA_QUERY_ANALYSIS: Show AAAA queries[2022-03-24 07:32:48.714 3975M]    MAXDBDAYS: max age for stored queries is 365 days[2022-03-24 07:32:48.714 3975M]    RESOLVE_IPV6: Resolve IPv6 addresses[2022-03-24 07:32:48.714 3975M]    RESOLVE_IPV4: Resolve IPv4 addresses[2022-03-24 07:32:48.714 3975M]    DBINTERVAL: saving to DB file every minute[2022-03-24 07:32:48.714 3975M]    DBFILE: Using /etc/pihole/pihole-FTL.db[2022-03-24 07:32:48.714 3975M]    MAXLOGAGE: Importing up to 24.0 hours of log data[2022-03-24 07:32:48.714 3975M]    PRIVACYLEVEL: Set to 0[2022-03-24 07:32:48.714 3975M]    IGNORE_LOCALHOST: Show queries from localhost[2022-03-24 07:32:48.714 3975M]    BLOCKINGMODE: Null IPs for blocked domains[2022-03-24 07:32:48.715 3975M]    ANALYZE_ONLY_A_AND_AAAA: Disabled. Analyzing all queries[2022-03-24 07:32:48.715 3975M]    DBIMPORT: Importing history from database[2022-03-24 07:32:48.715 3975M]    PIDFILE: Using /run/pihole-FTL.pid[2022-03-24 07:32:48.715 3975M]    PORTFILE: Using /run/pihole-FTL.port[2022-03-24 07:32:48.715 3975M]    SOCKETFILE: Using /run/pihole/FTL.sock[2022-03-24 07:32:48.715 3975M]    SETUPVARSFILE: Using /etc/pihole/setupVars.conf[2022-03-24 07:32:48.715 3975M]    MACVENDORDB: Using /etc/pihole/macvendor.db[2022-03-24 07:32:48.715 3975M]    GRAVITYDB: Using /etc/pihole/gravity.db[2022-03-24 07:32:48.715 3975M]    PARSE_ARP_CACHE: Active[2022-03-24 07:32:48.716 3975M]    CNAME_DEEP_INSPECT: Active[2022-03-24 07:32:48.716 3975M]    DELAY_STARTUP: No delay requested.[2022-03-24 07:32:48.716 3975M]    BLOCK_ESNI: Enabled, blocking _esni.{blocked domain}[2022-03-24 07:32:48.716 3975M]    NICE: Cannot change niceness to -10 (permission denied)[2022-03-24 07:32:48.716 3975M]    MAXNETAGE: Removing IP addresses and host names from network table after 365 days[2022-03-24 07:32:48.716 3975M]    NAMES_FROM_NETDB: Enabled, trying to get names from network database[2022-03-24 07:32:48.716 3975M]    EDNS0_ECS: Overwrite client from ECS information[2022-03-24 07:32:48.716 3975M]    REFRESH_HOSTNAMES: Periodically refreshing IPv4 names[2022-03-24 07:32:48.716 3975M]    RATE_LIMIT: Rate-limiting client making more than 1000 queries in 60 seconds[2022-03-24 07:32:48.716 3975M]    LOCAL_IPV4: Automatic interface-dependent detection of address[2022-03-24 07:32:48.716 3975M]    LOCAL_IPV6: Automatic interface-dependent detection of address[2022-03-24 07:32:48.717 3975M]    BLOCK_IPV4: Automatic interface-dependent detection of address[2022-03-24 07:32:48.717 3975M]    BLOCK_IPV6: Automatic interface-dependent detection of address[2022-03-24 07:32:48.717 3975M]    REPLY_ADDR4: Using IPv4 address 192.168.178.105 instead of automatically determined IP address[2022-03-24 07:32:48.717 3975M]    SHOW_DNSSEC: Enabled, showing automatically generated DNSSEC queries[2022-03-24 07:32:48.717 3975M]    MOZILLA_CANARY: Enabled[2022-03-24 07:32:48.717 3975M]    PIHOLE_PTR: internal PTR generation enabled (pi.hole)[2022-03-24 07:32:48.717 3975M]    ADDR2LINE: Enabled[2022-03-24 07:32:48.717 3975M]    REPLY_WHEN_BUSY: Permit queries when the database is busy[2022-03-24 07:32:48.717 3975M]    BLOCK_TTL: 2 seconds[2022-03-24 07:32:48.717 3975M]    BLOCK_ICLOUD_PR: Enabled[2022-03-24 07:32:48.717 3975M]    CHECK_LOAD: Enabled[2022-03-24 07:32:48.718 3975M]    CHECK_SHMEM: Warning if shared-memory usage exceeds 90%[2022-03-24 07:32:48.718 3975M]    CHECK_DISK: Warning if certain disk usage exceeds 90%[2022-03-24 07:32:48.718 3975M] Finished config file parsing[2022-03-24 07:32:48.720 3975M] Database version is 12[2022-03-24 07:32:48.720 3975M] Resizing "FTL-strings" from 40960 to (81920 * 1) == 81920 (/dev/shm: 688.1KB used, 67.1MB total, FTL uses 676.2KB)[2022-03-24 07:32:48.721 3975M] Imported 0 alias-clients[2022-03-24 07:32:48.721 3975M] Database successfully initialized[2022-03-24 07:32:48.729 3975M] New upstream server: 8.8.4.4:53 (0/32)[2022-03-24 07:32:48.744 3975M] New upstream server: 4.2.2.2:53 (2/32)[2022-03-24 07:32:48.745 3975M] New upstream server: 8.8.8.8:53 (3/32)[2022-03-24 07:32:48.786 3975M] Resizing "FTL-domains" from 12288 to (1024 * 24) == 24576 (/dev/shm: 729.1KB used, 67.1MB total, FTL uses 717.1KB)[2022-03-24 07:32:48.847 3975M] Resizing "FTL-queries" from 229376 to (8192 * 56) == 458752 (/dev/shm: 741.4KB used, 67.1MB total, FTL uses 729.4KB)[2022-03-24 07:32:48.884 3975M] New upstream server: 4.2.2.1:53 (4/32)[2022-03-24 07:32:48.959 3975M] Resizing "FTL-queries" from 458752 to (12288 * 56) == 688128 (/dev/shm: 970.8KB used, 67.1MB total, FTL uses 958.8KB)[2022-03-24 07:32:48.973 3975M] New upstream server: 208.67.220.220:53 (5/32)[2022-03-24 07:32:49.023 3975M] Resizing "FTL-domains" from 24576 to (1536 * 24) == 36864 (/dev/shm: 1.2MB used, 67.1MB total, FTL uses 1.2MB)[2022-03-24 07:32:49.092 3975M] Resizing "FTL-queries" from 688128 to (16384 * 56) == 917504 (/dev/shm: 1.2MB used, 67.1MB total, FTL uses 1.2MB)[2022-03-24 07:32:48.847 3975M] Resizing "FTL-queries" from 229376 to (8192 * 56) == 458752 (/dev/shm: 741.4KB used, 67.1MB total, FTL uses 729.4KB)[2022-03-24 07:32:48.884 3975M] New upstream server: 4.2.2.1:53 (4/32)[2022-03-24 07:32:48.959 3975M] Resizing "FTL-queries" from 458752 to (12288 * 56) == 688128 (/dev/shm: 970.8KB used, 67.1MB total, FTL uses 958.8KB)[2022-03-24 07:32:48.973 3975M] New upstream server: 208.67.220.220:53 (5/32)[2022-03-24 07:32:49.023 3975M] Resizing "FTL-domains" from 24576 to (1536 * 24) == 36864 (/dev/shm: 1.2MB used, 67.1MB total, FTL uses 1.2MB)[2022-03-24 07:32:49.092 3975M] Resizing "FTL-queries" from 688128 to (16384 * 56) == 917504 (/dev/shm: 1.2MB used, 67.1MB total, FTL uses 1.2MB)[2022-03-24 07:32:49.232 3975M] Resizing "FTL-queries" from 917504 to (20480 * 56) == 1146880 (/dev/shm: 1.4MB used, 67.1MB total, FTL uses 1.4MB)[2022-03-24 07:32:49.245 3975M] Resizing "FTL-domains" from 36864 to (2048 * 24) == 49152 (/dev/shm: 1.7MB used, 67.1MB total, FTL uses 1.7MB)[2022-03-24 07:32:49.343 3975M] Resizing "FTL-strings" from 81920 to (122880 * 1) == 122880 (/dev/shm: 1.7MB used, 67.1MB total, FTL uses 1.7MB)[2022-03-24 07:32:49.386 3975M] Resizing "FTL-queries" from 1146880 to (24576 * 56) == 1376256 (/dev/shm: 1.7MB used, 67.1MB total, FTL uses 1.7MB)[2022-03-24 07:32:49.563 3975M] Resizing "FTL-queries" from 1376256 to (28672 * 56) == 1605632 (/dev/shm: 2.0MB used, 67.1MB total, FTL uses 1.9MB)[2022-03-24 07:32:49.718 3975M] Resizing "FTL-queries" from 1605632 to (32768 * 56) == 1835008 (/dev/shm: 2.2MB used, 67.1MB total, FTL uses 2.2MB)[2022-03-24 07:32:49.845 3975M] Resizing "FTL-queries" from 1835008 to (36864 * 56) == 2064384 (/dev/shm: 2.4MB used, 67.1MB total, FTL uses 2.4MB)[2022-03-24 07:32:49.949 3975M] Resizing "FTL-queries" from 2064384 to (40960 * 56) == 2293760 (/dev/shm: 2.6MB used, 67.1MB total, FTL uses 2.6MB)[2022-03-24 07:32:49.845 3975M] Resizing "FTL-queries" from 1835008 to (36864 * 56) == 2064384 (/dev/shm: 2.4MB used, 67.1MB total, FTL uses 2.4MB)[2022-03-24 07:32:49.949 3975M] Resizing "FTL-queries" from 2064384 to (40960 * 56) == 2293760 (/dev/shm: 2.6MB used, 67.1MB total, FTL uses 2.6MB)[2022-03-24 07:32:50.054 3975M] Resizing "FTL-queries" from 2293760 to (45056 * 56) == 2523136 (/dev/shm: 2.9MB used, 67.1MB total, FTL uses 2.9MB)[2022-03-24 07:32:50.099 3975M] Resizing "FTL-domains" from 49152 to (2560 * 24) == 61440 (/dev/shm: 3.1MB used, 67.1MB total, FTL uses 3.1MB)[2022-03-24 07:32:50.112 3975M] Imported 42997 queries from the long-term database[2022-03-24 07:32:50.113 3975M]  -> Total DNS queries: 42997[2022-03-24 07:32:50.113 3975M]  -> Cached DNS queries: 2169[2022-03-24 07:32:50.113 3975M]  -> Forwarded DNS queries: 32603[2022-03-24 07:32:50.113 3975M]  -> Blocked DNS queries: 7744[2022-03-24 07:32:50.113 3975M]  -> Unknown DNS queries: 0[2022-03-24 07:32:50.113 3975M]  -> Unique domains: 2057[2022-03-24 07:32:50.113 3975M]  -> Unique clients: 6[2022-03-24 07:32:50.113 3975M]  -> Known forward destinations: 6[2022-03-24 07:32:50.113 3975M] Successfully accessed setupVars.conf[2022-03-24 07:32:50.115 3975M] FATAL ERROR in dnsmasq core: failed to create listening socket for port 53: Permission denied[2022-03-24 07:32:50.121 3975M] ########## FTL terminated after 1s 410ms  (code 1)! ##########

You must be logged in to vote

1 reply

Comment options

dschaper Mar 25, 2022
Maintainer

That seems to be a different issue. Or you hadrestart=always|unless-stopped and docker tried to restart the existing running container with the binary that was not fully permissioned.

The error manifested as thes6-init not completing and no information written topihole-FTL.log. If you are seeing log entries then please make sure they are not old ones.

Comment options

braymullo
Mar 24, 2022

Confirmed on both Raspi 4B (running bullseye light) and on OMV6 (on a Mac mini)

You must be logged in to vote

0 replies

Comment options

kchenery
Mar 24, 2022

I had the same problem. Found I could get DNS working if I removed:

network_mode: "host"

from mydocker-compose file and instead used the port mappings:

    ports:      - "53:53/tcp"      - "53:53/udp"      - "67:67/udp"      - "80:80/tcp"      - "443:443/tcp"

However; I also use the pihole or DHCP and that would fail. I had to disable that to get things started. The DHCP would fail with:

FATAL ERROR in dnsmasq core: failed to bind DHCP server socket: Permission denied

I already had:

    cap_add:      - NET_ADMIN

set in the compose file. I tried a few othersALL andNET_BIND_SERVICE though nothing worked.

Ended up disabling the docker container for now and installed manually which worked.

You must be logged in to vote

0 replies

Comment options

DFlexy
Mar 24, 2022

Same problem here.

Linux Rasphouse 5.10.103-v8+ pi-hole/pi-hole#1530 SMP PREEMPT Tue Mar 8 13:06:35 GMT 2022 aarch64 GNU/Linux

Starting pihole-FTL (no-daemon) as piholeStopping pihole-FTLpihole-FTL: no process foundStarting pihole-FTL (no-daemon) as piholeStopping pihole-FTLpihole-FTL: no process foundStarting pihole-FTL (no-daemon) as piholeStopping pihole-FTLpihole-FTL: no process foundStarting pihole-FTL (no-daemon) as piholeStopping pihole-FTLpihole-FTL: no process foundStarting pihole-FTL (no-daemon) as piholeStopping pihole-FTLpihole-FTL: no process foundStarting pihole-FTL (no-daemon) as piholeStopping pihole-FTLpihole-FTL: no process foundStarting pihole-FTL (no-daemon) as pihole

You must be logged in to vote

0 replies

Comment options

dsm1212
Mar 24, 2022

If you set the pihole uid/gid to 0 it will come up. Docker must have changed some permissions management for network.

You must be logged in to vote

0 replies

Comment options

DFlexy
Mar 24, 2022

Variable done work now ;)

-e PIHOLE_UID=0 \

You must be logged in to vote

0 replies

Comment options

dsm1212
Mar 24, 2022

Reading a bit I'm not sure why we never needed cap NET_BIND_SERVICE before. I think that maybe what is needed but I'm busy and don't want to take my network down again. Will try later tonight.

You must be logged in to vote

0 replies

Comment options

PromoFaux
Mar 24, 2022
Maintainer

I'm not going to be able to troubleshoot this much, I'm currently on lunch at work and then away for the weekend... But can someone try setting the env varDNSMASQ_USER toroot to see if that makes any difference?

You must be logged in to vote

1 reply

Comment options

shmick Mar 29, 2022

I can confim that settingDNSMASQ_USER toroot worked for me

Comment options

Niracus
Mar 24, 2022

I'm not going to be able to troubleshoot this much, I'm currently on lunch at work and then away for the weekend... But can someone try setting the env varDNSMASQ_USER toroot to see if that makes any difference?

This worked for me!

You must be logged in to vote

0 replies

Comment options

d-rez
Mar 24, 2022

I can also confirm this issue. Fortunately I'm running two instances in my network in a docker cluster and only updated one at a time. 20.10.12 still works absolutely fine, 20.10.14 throws the above errors in pihole-FTL logs (and not much at all in docker logs)

I've deleted and re-created docker containers, volumes and services (stack) completely and verified image hash is the same on both hosts. I use Host network as well, otherwise I wouldn't know which devices on my network are which (for stats).

Per Docker docs,NET_BIND_SERVICE isenabled by default so that shouldn't be relevant to the issue. It's more likely thatsome other change affected this, specifically the vague reference to the CVE anddefault inheritable capabilities.. Maybe the image simply needs to be rebuilt with a newer Docker version, as there are reference to the builder as well.

SettingDNSMASQ_USER toroot fixed it for me as well for the time being. Thanks for the suggestion.

You must be logged in to vote

0 replies

Comment options

JonasSchubert
Mar 24, 2022

Variable done work now ;)
-e PIHOLE_UID=0 \

This helped. Pi Hole is running again. Thanks

You must be logged in to vote

0 replies

Comment options

DFlexy
Mar 24, 2022

Tests OK with

  -e DNSMASQ_USER=root \

work too same

  -e PIHOLE_UID=0 \

You must be logged in to vote

0 replies

Comment options

rluetzner
Mar 24, 2022

@DFlexy 's answer is acceptable as a temporary workaround, but seeing as in the past Pi-Hole tried to take up as little permissions as necessary it's counterproductive to let everything run as root.

Earlier I opened up an issue with Docker, where someone pointed me in the right direction. Maybe the comment might help fix the underlying issue:moby/moby#43420 (comment)

The following is a quote from the comment:

I'm not familiar with the entirety of the pihole image, but I was able to findthis line:
setcap CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_NET_ADMIN,CAP_SYS_NICE,CAP_CHOWN+ei$(which pihole-FTL)|| ret=$?
This is setting file inheritable capabilities (+ei) but can be changed to set file permitted capabilities (+ep) instead, which would then achieve the desired effect of escalation for the named capabilities (subject to the container's bounding set; you'll still need to specifically addNET_ADMIN to the container).

You must be logged in to vote

4 replies

Comment options

PromoFaux Mar 24, 2022
Maintainer

We can give it a go.

#1022

Once that passes we'll merge it in and get the:dev tag built to try...

Comment options

PromoFaux Mar 24, 2022
Maintainer

dev now building. Watch this space:https://github.com/pi-hole/docker-pi-hole/actions/runs/2036312268

Comment options

PromoFaux Mar 24, 2022
Maintainer

Appears it did not. Back to the drawing board

Comment options

rluetzner Mar 24, 2022

Too bad, but thanks for trying. Maybe some of the guys over at the Moby project might be able to help. They were expecting some images to break and sound like they're willing to help iron things out.

Comment options

dschaper
Mar 24, 2022
Maintainer

Update April 25th:

The first recommendation is to upgrade your host OS, which will include a more up to date (and fixed) version oflibseccomp.

If you absolutely cannot do this, some usershave reported success in updatinglibseccomp2 via backports on debian, or similar via updates on Ubuntu. You can try this workaround at your own risk

April 2nd: There is a new image2022.04.2beta. Can you folks try it and see if it's working for you?

March 30th at 1210: The latest fixes are now in thedev image.

Edit: With the root workarounds removed of course.

Edit2: This is the moby issue tracking the changes to Docker that looks to be the cause of this issue;
moby/moby#43420 (comment)

You must be logged in to vote

33 replies

Comment options

dsm1212 Mar 27, 2022

I've got pihole running non-root by changing the sysctl parameter which allows anyone to open a port below 1024. But my reading says that should not be necessary if ambient caps are used correctly. The cat /proc/525/status shows why I need to use the sysctl parameter --> The pihole-FTL process in the dev container on my system is running with no caps enabled. This should not be the case in the dev container if the caps were being effective. I can see some of you are saying the change is working, I don't know if maybe you are not using host networking or maybe your sysctl parameter was already zero (default is zero on ubuntu I've read). But on my debian bullseye system, using the dev container, the process is still running with no caps.

Comment options

dsm1212 Mar 28, 2022

I think the problem is that some of these kernels like bullseye support ambient caps and older ones don't. You've only set the inherited caps, but on systems that support ambient no caps will be propagated across an execve for a non-privileged user unless they are in the ambient set.

Comment options

rdwebdesign Mar 28, 2022
Maintainer

dschaper is already trying a solution to support ambient caps, but it's not finished yet.

Comment options

dschaper Mar 28, 2022
Maintainer

@dsm1212 I have the ambient working with a slight change. There is a problem in libcap that doesn't propagate ambient permissions when uid/gid/user is changed for the runner.https://bugzilla.redhat.com/show_bug.cgi?id=1950187

So I have to set the+ep in the docker start up script and then wrap thepihole-FTL call incapsh with the ambient. I had it last night but I couldn't get my GPG to sign or I would have pushed the branch.

And yes, that means Bullseye, but Bullseye has a problem with the ARMv7 arch that prevents working correctly. That is from atouch call to make sure a file exists, thetouch always fails. I'll have to code a guard around that function but it's in the Core repo.

You can pulldjschaper/pihole-caps-test:first and it will run on every platform but ARMv7. And the caps do prop, the binary gets+eip for the network capabilites whenpihole-FTL is run as thepihole user.

Comment options

dschaper Mar 28, 2022
Maintainer

dsm1212, the PR is at#1030 and it's the workaround for ambient being wiped out when we change to$DNSMASQ_USER

Answer selected bydschaper

Comment options

SuperSandro2000
Mar 25, 2022

Why is this a discussion which is marked as answered? This is a bug which is definitely not fixed.

You must be logged in to vote

8 replies

Comment options

whizzzkid Mar 26, 2022
AuthorSponsor

@dschaper The selected answer should be to stay ondocker-ce@20.10.13 till this fix is live on pihole stable. The selected answer is probably a fix ondev, and is not stable enough for average user.

Comment options

d-rez Mar 27, 2022

I think y'all should just chill and let the dev handle it how they see fit. Dev branch, running as root and staying on an older version are all workarounds and not solutions, but they will all contribute to the same effect and people can choose what they want to try. None of them are straightforward for an "average user", one requires locking packages from updating (unless you meant not updating raspbian at all, which again is not a solution either), the other changing image or modifying environment variables.

Comment options

SuperSandro2000 Mar 27, 2022

This still doesn't explain why this is a discussion. This is clearly a bug/issue.

Issues on GItHub already don't have the greatest UX and now we have a discussion which is like combining 5 issues and is really confusing.

Comment options

dschaper Mar 27, 2022
Maintainer

With Issues we can't have threaded discussions. We'd have this entire discussion as one single 50 comment thread.

With Discussions we can have threads so entitled whines like this thread can be isolated from the real work of solving the issue caused by an upstream change that wasn't disclosed before it was released.

Comment options

SuperSandro2000 Mar 27, 2022

We'd have this entire discussion as one single 50 comment thread.

The first 10 comments where each a new thread and then you opened one thread which is actually about the solution. So I don't think this is happening here.

the real work of solving the issue caused

I tried contributing more logs but to my question on how to get more logs I didn't receive an answer. The first dev tag I tried didn't change anything.

Comment options

DFlexy
Mar 27, 2022

@dschaper

Tests now for u ;)
Dont work and with static set ip and no DHCP work too
U can see too i creat new volumes for test

LOGS:Starting pihole-FTL (no-daemon) as piholeStopping pihole-FTLpihole-FTL: no process foundStarting pihole-FTL (no-daemon) as pihole

My code:

docker run -d \  --name=piholetest \  --hostname=piholetest \  -e TZ=America/Maceio \  -e ServerIP=172.30.0.254 \  -e DHCP_ACTIVE=true \  -e DHCP_START=172.30.0.100 \  -e DHCP_END=172.30.0.200 \  -e DHCP_ROUTER=172.30.0.1 \  -e PIHOLE_DNS_=172.20.0.2 \  -e DNSMASQ_LISTENING=bind \  -e WEBUIBOXEDLAYOUT=traditional \  -e WEBTHEME=default-dark \  -e DHCP_rapid_commit=true \  -e VIRTUAL_HOST="pi.hole" \  -v pihole_test:/etc/pihole/ \  -v dnsmasq_test:/etc/dnsmasq.d/ \  --cap-add=NET_ADMIN \  --cap-add=CAP_SYS_NICE \  --network=host \  --restart=unless-stopped \  pihole/pihole:dev

You must be logged in to vote

21 replies

Comment options

PromoFaux Apr 4, 2022
Maintainer

2022.04.2 should be working fine with macvlan (my setup is using macvlan, but no DHCP). Just make sure you haveCAP_NET_ADMIN set, else you wont be able to use DHCP.

Comment options

rluetzner Apr 4, 2022

I can confirm that. I'm running the latest pihole image with macvlan and DHCP without issues.CAP_NET_ADMIN is set as isPIHOLE_UID in my case.

Comment options

Iruberiam Apr 5, 2022

Thanks for the feedback, I suspect compose isn't applying CAP_NET_ADMIN on my system, I'm using compose v2.4. I'll attempt to update.

Comment options

Iruberiam Apr 5, 2022

I've recreated/reformatted my compose file and can confirm that the latest build now works correctly. I had some old perhaps deprecated entries.
hostname: pi-hole mac_address: xx:xx:xx:xx:xx:xx privileged: true maybe one of these was causing the issue.

Edit: Forgot to add also updated compose to 3.3.

Comment options

whizzzkid Apr 5, 2022
AuthorSponsor

Can someone share the updateddocker-compose entry? Can't afford to bring my network down again.

Comment options

dawid-woitaschek
Apr 25, 2022

Still not working... Even in the current dev. -.-

You must be logged in to vote

4 replies

Comment options

dsm1212 Apr 25, 2022

The fix is even working on latest now. I see others have upticked so maybe there is a particular platform where it fails or something. You need to provide details, the ones here are addressed and confirmed to be fixed.

Comment options

rdwebdesign Apr 25, 2022
Maintainer

If it's not working, it's probably a different issue.

Please, try ourDiscourse forum or open a new issue and provide more information.

Comment options

d-rez Apr 25, 2022

I agree with the others, can definitely confirm the current latest imageis working fine on a raspbian,without the root user workaround. If you want anyone to take a look, you need to be way more specific on what isn't working.

Comment options

dawid-woitaschek Apr 25, 2022

Well... I just purged the whole container (bye bye, around 20 local entries) and fired it up with the latest image - and it's working again. :)

Dunno what was wrong before that. Tried the dev, tried the named beta - nada.

Nothing special configured before... Around 20 clients, ~ 600k blocking entries, local entries and conditional forwarding to my router/DHCP because of local hostnames. I will observe it and report back if it gets worse again.