[SOLUTION] Pi-hole v6 on Ugreen NAS (UGOS Pro) — port 53 conflict with dnsmasq

FAQs Community How-to's
1

Hi everyone,

After hours of troubleshooting I finally solved the Pi-hole DNS failure on Ugreen NAS.
Sharing this because I saw many users with the same issue and no clear solution.

System: Ugreen NAS running UGOS Pro (confirmed on multiple models)

Symptom:
Pi-hole starts, web panel loads, but shows "DNS server failure" and no device gets DNS responses.
Logs show:
CRIT: Error in dnsmasq configuration: failed to create listening socket for port 53: Address in use

Root cause:
UGOS Pro runs dnsmasq instances that occupy port 53 before Pi-hole can bind to it:

  • Virtual Machine app (libvirt) creates instances on 192.100.0.1:53 and 192.100.1.1:53
  • The base system runs its own instance on 127.0.0.1:53

Confirm with: sudo ss -tulpn | grep :53

Solution:

  1. Uninstall the Virtual Machines app from UGOS App Center (if you don't use VMs)

  2. Stop and disable the system dnsmasq:
    sudo systemctl stop dnsmasq
    sudo systemctl disable dnsmasq

  3. Restart Pi-hole:
    sudo docker compose down && sudo docker compose up -d

  4. Fix NAS DNS permanently:
    echo "nameserver YOUR_NAS_IP" | sudo tee /etc/resolv.conf
    sudo chattr +i /etc/resolv.conf

Working docker-compose.yml:

services:
pihole:
container_name: pihole
image: pihole/pihole:latest
network_mode: host
cap_add:

  • NET_ADMIN
  • NET_BIND_SERVICE
    environment:
    TZ: America/Lima
    WEBPASSWORD: 'your_password'
    FTLCONF_webserver_port: 8090
    FTLCONF_dns_listeningMode: single
    FTLCONF_dns_interface: eth0
    volumes:
  • /volume1/docker/pihole/etc-pihole:/etc/pihole
  • /volume1/docker/pihole/etc-dnsmasq.d:/etc/dnsmasq.d
    restart: unless-stopped

Note: UGOS uses port 80, so set a different port for Pi-hole web interface with FTLCONF_webserver_port.
Note: If WEBPASSWORD doesn't apply on first start, reset it with:
sudo docker exec -it pihole pihole setpassword your_password

Hope this helps. Confirmed working on UGOS Pro.

2

This variable is invalid.

You need to use the correct one: FTLCONF_webserver_api_password

3

YOUR_NAS_IP should be substituted with the actual IP of your NAS, I presume, which would have your NAS use Pi-hole for DNS.

On the machine that runs Pi-hole, it would be recommended to use a public DNS server IP in addition or instead of Pi-hole, so OS updates as well as Pi-hole's update and repair scripts would be able to run even if Pi-hole would be inoperational.

I also notice that you try to prevent updates to resolv.conf by making it immutable. You should note that processes with elevated privileges may still alter that file.

The contents of /etc/resolv.conf is typically controlled by some tool, as usually indicated by a comment in that file. You should configure that tool to persist changes to your resolv.conf, rather than editing it manually.
You may want to investigate the proper way of populating /etc/resolv.conf on your NAS.

4

Sometimes you might want to use the mask option here too because some services are very stubborn and ignore your settings after a reboot :frowning:

See here : systemctl(1) - Linux manual page

mask UNIT...
           Mask one or more units, as specified on the command line. This
           will link these unit files to /dev/null, making it impossible
           to start them. This is a stronger version of disable, since it
           prohibits all kinds of activation of the unit, including
           enablement and manual activation.

Just in case you need it...

5

Thanks for the correction! I've updated the compose file to use FTLCONF_webserver_api_password instead. Confirmed it works correctly on first start without needing to reset manually.

6

Thanks for the detailed feedback!

You're right about the DNS fallback. I've updated /etc/resolv.conf to include both Pi-hole and a public DNS as backup:

nameserver 192.168.xx.xx
nameserver 8.8.8.8

Regarding chattr +i, noted — it's not the ideal method. I'll investigate the proper way to persist changes on UGOS Pro. For now it's working but I understand it's not bulletproof.

7

Good tip on mask! I've applied it:

sudo systemctl mask dnsmasq

Much safer than just disable to prevent it from coming back after UGOS updates. Thanks!