PiHole Broken after docker update to 20.10.14

[whizzzkid]

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 pihole
pihole-FTL: No process found
Stopping pihole-FTL

Steps to reproduce

Run pihole using docker-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 breaking docker-ce update, downgrading to docker-ce=5:20.10.13~3-0~debian-buster fixed the issue.
The problem looks similar to:

• pihole-FTL: No process found pi-hole#1809
• https://discourse.pi-hole.net/t/pi-hole-wont-start-after-docker-update/44454

[jbaldzer]

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)! ##########

[dschaper]

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

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

[braymullo]

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

[kchenery]

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

network_mode: "host"

from my docker-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 others ALL and NET_BIND_SERVICE though nothing worked.

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

[DFlexy]

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 pihole
Stopping pihole-FTL
pihole-FTL: no process found
Starting pihole-FTL (no-daemon) as pihole
Stopping pihole-FTL
pihole-FTL: no process found
Starting pihole-FTL (no-daemon) as pihole
Stopping pihole-FTL
pihole-FTL: no process found
Starting pihole-FTL (no-daemon) as pihole
Stopping pihole-FTL
pihole-FTL: no process found
Starting pihole-FTL (no-daemon) as pihole
Stopping pihole-FTL
pihole-FTL: no process found
Starting pihole-FTL (no-daemon) as pihole
Stopping pihole-FTL
pihole-FTL: no process found
Starting pihole-FTL (no-daemon) as pihole

[dsm1212]

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

[DFlexy]

Variable done work now ;)

-e PIHOLE_UID=0 \

[dsm1212]

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.

[PromoFaux]

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 var DNSMASQ_USER to root to see if that makes any difference?

[shmick]

I can confim that setting DNSMASQ_USER to root worked for me

[Niracus]

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 var DNSMASQ_USER to root to see if that makes any difference?

This worked for me!

[d-rez]

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 is enabled by default so that shouldn't be relevant to the issue. It's more likely that some other change affected this, specifically the vague reference to the CVE and default inheritable capabilities.. Maybe the image simply needs to be rebuilt with a newer Docker version, as there are reference to the builder as well.

Setting DNSMASQ_USER to root fixed it for me as well for the time being. Thanks for the suggestion.

[JonasSchubert]

Variable done work now ;)

-e PIHOLE_UID=0 \

This helped. Pi Hole is running again. Thanks

[DFlexy]

Tests OK with

  -e DNSMASQ_USER=root \

work too same

  -e PIHOLE_UID=0 \

[rluetzner]

@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 find this 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 add NET_ADMIN to the container).

[PromoFaux]

We can give it a go.

#1022

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

[PromoFaux]

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

[PromoFaux]

Appears it did not. Back to the drawing board

[rluetzner]

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.

[dschaper]

Update April 25th:

Due to a known issue with Docker and libseccomp <2.5, you may run into issues running 2022.04 and later on host systems with an older version of libseccomp2 (Such as Debian/Raspbian buster or Ubuntu 20.04, and maybe CentOS 7).

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

If you absolutely cannot do this, some users have reported success in updating libseccomp2 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 image 2022.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 the dev 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)

[dsm1212]

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.

[dsm1212]

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.

[rdwebdesign]

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

[dschaper]

@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 the pihole-FTL call in capsh 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 a touch call to make sure a file exists, the touch always fails. I'll have to code a guard around that function but it's in the Core repo.

You can pull djschaper/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 when pihole-FTL is run as the pihole user.

[dschaper]

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

[SuperSandro2000]

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

[whizzzkid]

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

[d-rez]

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.

[SuperSandro2000]

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.

[dschaper]

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.

[SuperSandro2000]

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.

[DFlexy]

@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 pihole
Stopping pihole-FTL
pihole-FTL: no process found
Starting 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

[PromoFaux]

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

[rluetzner]

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

[Iruberiam]

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.

[Iruberiam]

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.

[whizzzkid]

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

[dawid-woitaschek]

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

[dsm1212]

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.

[rdwebdesign]

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

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

[d-rez]

I agree with the others, can definitely confirm the current latest image is 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.

[dawid-woitaschek]

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.

[PromoFaux]

Locking this thread as it is now resolved.