Getting pihole-docker to work on OSMC

I've been running pihole on my raspberry pi on and off for a couple of years now. I've been forced to stop using it a few times over the years because overnight I would find that the container couldn't start because it couldn't bind to port 53.

An important note here (though it shouldn't be), is that I'm running OSMC as the OS on the RPI instead of Debian/Ubuntu.

I've got a pretty simple setup using docker and docker-compose for pihole with my compose file that looks like this:

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp"
      - "1080:80/tcp"
    environment:
      TZ: 'Europe/London'
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq.d:/etc/dnsmasq.d'
      - '/etc/resolv.conf:/etc/resolv.conf'
    cap_add:
      - NET_ADMIN
    restart: always

For oficcial instructions see the official docker-pi-hole repo

The error

This problem usually shows up after running an OS upgrade. And whenever I run docker compose up to start pi-hole I see this error

Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint pihole (): failed to bind host port for 0.0.0.0:53:172.18.0.2:53/tcp: address already in use

Troubleshooting and the usual suspects

Troubleshooting usually indicates that this may be a problem with resolved which is normally fixed by changing a few lines in /etc/resolv.conf and the instructions to do this are available in multiple places but one of the best right now is in the instructions for another dns-level ad blocker: adguard home.

This does not fix the problem for me, if I do sudo lsof -i :53 I can still see some processes bound to port 53.

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
connmand 363 root   11u  IPv4  10158      0t0  UDP osmc:domain 
connmand 363 root   12u  IPv6  10162      0t0  UDP osmc:domain 
connmand 363 root   13u  IPv4  10166      0t0  TCP osmc:domain (LISTEN)
connmand 363 root   14u  IPv6  10170      0t0  TCP osmc:domain (LISTEN)
connmand 363 root   17u  IPv4  13863      0t0  UDP my_hostname:47639->_gateway:domain 
connmand 363 root   18u  IPv4  13883      0t0  UDP my_hostname:39349->_gateway:domain 

But now the problem is a bit clearer, something in the OS is ignoring the resolved settings and still starting up a DNS server.

The Solution

It turns out that the OS plays a major role here because even though it's debian based, OSMC has a few customizations that mess with these specific settings. As part of the settings for the distro, they install and configure connman and this is starting it's own DNS.

I was lucky to find this discussion on the OSMC forums, but since I don't trust I'll find it again next time, here's the short version:

Now that we know the problem, it's simple enough open /etc/osmc/prefs.d/connman with your favourite editor and change dnsproxy=yes to dnsproxy=no. The file should end up looking something like this:

# /etc/osmc/prefs.d/connman 
# If set to yes, connman enables a dns proxy running on localhost port 53 and sets /etc/resolv.conf nameservers to point at 127.0.0.1
# If set to no, the dns proxy is disabled and connman will update nameservers directly in /etc/resolv.conf.

dnsproxy=no

Once that change is done, simply restart connman and you're set

sudo systemctl restart connman

While it's not needed, I've opted to also make the same change in /etc/connman.prefs for good measure.

And that's it!