Pretty new to Unraid and Docker and I'm a bit confused. I see Docker apps listed as "official" and tagged with blue marks, but when I try to use them it turns out that they are third party apps and unsupported by the original development team on Unraid.

In this specific case I tried to use the binhex-official-pihole container. I ran into several issues and posted on the PiHole forums. Apparently many of the variables are specified incorrectly, and others are out of date. I can't get help with this container there as it isn't supported on Unraid.

At that point I started looking here and there is no container support thread for this one. How is it in any way "official" if the dev team isn't supporting it, and neither is the Unraid team? Do I just pick a different release and move on?

Thanks!

Its official because it uses the docker container image from the author of the application i.e. pihole/pihole

Unraid templates are a wrapper which hold the docker configuration, equivalent of docker run command.

There templates are nearly all community author supported, and typically have a support thread... this one doesn't seem to, so post in their general thread: https://forums.unraid.net/topic/44108-support-binhex-general/page/8/

Before you go and install pi-hole on unraid you should know there's a caveat to running this on unraid; Every time your server goes down(reboot, stopping the array, updating the container etc), your DNS will go down, meaning you're unable to reach the internet on any of your devices.

The ideal setup: Many Unraid users run Pi-hole on an always-on dedicated device (like a Raspberry Pi or a mini PC).

If you do decide to install it on your server, you should set your secondary DNS on your router to Cloudflare's DNS (1.1.1.1) or Google's DNS (8.8.8.8). That way, when your server goes down, your devices can still reach the internet using the secondary DNS server.

1 hour ago, tjb_altf4 said:

Its official because it uses the docker container image from the author of the application i.e. pihole/pihole

Ok... so there could be any number of official templates for a single image? I could see it make sense in that context.

1 hour ago, strike said:

Before you go and install pi-hole on unraid you should know there's a caveat to running this on unraid; Every time your server goes down(reboot, stopping the array, updating the container etc), your DNS will go down, meaning you're unable to reach the internet on any of your devices.

The ideal setup: Many Unraid users run Pi-hole on an always-on dedicated device (like a Raspberry Pi or a mini PC).

If you do decide to install it on your server, you should set your secondary DNS on your router to Cloudflare's DNS (1.1.1.1) or Google's DNS (8.8.8.8). That way, when your server goes down, your devices can still reach the internet using the secondary DNS server.

I was debating buying another Pi or putting it on one I already have running Home Assistant. I figured this server should be fine since I leave it on, but it's looking like another board would simplify things.

I read that the router will bounce between DNS servers rather than exclusively use the first until it needs to fall back on the second. If another DNS is listed, traffic will route around the PiHole in normal operation. Are you saying that's incorrect?

2 minutes ago, Anti-Matt-er said:

I read that the router will bounce between DNS servers rather than exclusively use the first until it needs to fall back on the second. If another DNS is listed, traffic will route around the PiHole in normal operation. Are you saying that's incorrect?

No, I'm not saying that. I'm not using Pi-Hole myself right now, so I haven't tested it, but you're probably right in what you're saying. If you did the research, I'm taking your word for it :) It makes sense. But I still recommend installing it on a pi or something, especially if what you're saying is correct.

11 minutes ago, Anti-Matt-er said:

I figured this server should be fine since I leave it on

My server is also on 24/7, but I do take it down for updates and maintenance pretty regularly (at least every 2-3 months). And sometimes when you least expect it, it stays down for a while for whatever reason.

23 minutes ago, Anti-Matt-er said:

Ok... so there could be any number of official templates for a single image? I could see it make sense in that context.

Usually, there's only one official template for a container image. But almost all templates are made by unraid community members. There are also a few app developers who use Unraid and create the templates themselves, but most official templates are created by Unraid members who have no affiliation with the author of the app. This is just to make them easily available in the app store. So there can be many templates for a container, but usually only one official. Like @tjb_altf4 said, Official just means that it's using the official image the author of the app made.

Usually, you'll find a support thread for a container on Unraid, but some template authors just link to the official support channel for the app. But in your case, you should post in the binhex thread already mentioned if it's an issue with outdated variables, as you said.

Edited May 28May 28 by strike

Thanks. I posted in the other thread so hopefully I'll get some traction there. I also had issues with their Gluetun release as well so I'm hoping they respond.

Might buy another RPi for running PiHole tho. I could make that the first DNS and keep the NAS as backup.

I do wanna mention that this "official" icon is a rather meaningless and dockerhub only feature.

6 hours ago, Mainfrezzer said:

I do wanna mention that this "official" icon is a rather meaningless and dockerhub only feature.

I have got to disagree here. I will concede that the concept is rather cryptic for those not deeply versed in applications on unRAID and the Docker ecosystem but it still is an important piece of information.
The key is to understand that for any "application" available via docker through the Community Applications (CA) "appstore" there are possibly 3 separate entities acting as "providers/maintainers".

The template maintainer is the one who created the Dockerman Template for the container. Generally speaking they are the only ones with explicit knowledge that the application is going to be installed on unRAID, and they are typically expected to provide some manner of support for their templates as a prerequisite for being included in CA. That said the template is really little more than a convenience mechanism for specifying the proper docker run command. Users can easily override any part of the template (or even just make their own).

The image maintainer is the one who created the Docker image. A docker image consists of an application and all the dependencies and environment it requires to run. There is a lot of stuff that goes into an image in addition to its main application. Two images that contain an application (say plex) could have wildly different environments and configurations, as well as any number of additional applications, customizations and scripts. When it comes to choosing an specific image to use you have to trust that the provider of the image understands how to properly setup the application within the chosen environment, is committed to keeping the application/environment up to date (containers that install updates within themselves are not the norm). In a lot of ways an image maintainer is like a package maintainer for a distro in that they may not be the developer of the application but they are responsible for maintaining it for that particular environment. Additionally most docker images are mostly host agnostic the maintainers dont know or care what os the container runs on. The fact that image maintainers are not necessarily affiliated with the unRAID community means support is not a guarantee.

Finally the application maintainer is the one who actually develops and maintains the application. They generally have a number of installation methods / environments / distros that they officially support, which may or may not include containers. In general they reserve the right to provide support only for officially supported installations.

What the official icon tells us is that the image maintainer and application maintainer are one and the same. It means that this specific container image is one of the officially supported installation methods (on any platform). It essentially means that there is one less entity in the chain of support. Generally this is a good thing, though there are some cases where the official image is less featureful or well build than a third party image.

Finally its also worth noting that the "App Store" is called "Community Applications" for a reason. Limetech is rarely if ever the maintainer of a template, image, or application. In that regard there are very few unRAID "applications" that are "officially supported" by Limetech.

Just now, primeval_god said:

it still is an important piece of information.

who gets peddled by Dockerhub? Certainly helpful. Adguard/Adguardhome doesnt have it. And also ignores all that publish mainly to literally any other registry than Dockerhub.

11 minutes ago, primeval_god said:

What the official icon tells us is that the image maintainer and application maintainer are one and the same.

Also, thats flatout wrong, for CA. Binhex isnt a Maintainer of Pihole, and if his template is borked, Pihole cant do anything about it.

Edit: I do wanna elaborate a bit further. The official tag makes maybe sense just on docker hub seen byitself.

For CA it shouldn't be pulled at all. Official should be a manual tag that Lime/Squid attaches to container if there actually happens to be the same entity behind the app, the image and template. It just causes confusion and at the worst case annoys the Devs, when something is tagged as official but the issue is something they have no control over.

Edited May 28May 28 by Mainfrezzer
elaborate

4 hours ago, Mainfrezzer said:

Also, thats flatout wrong, for CA. Binhex isnt a Maintainer of Pihole, and if his template is borked, Pihole cant do anything about it.

Binhex is the template maintainer, Pihole is both the image and application maintainer. If there is something wrong with the template you have to ask Binhex (or just fix it yourself). If there is something wrong with the image or application you have to ask Pihole. Of the 3 components of a docker application on unRAID, template, image, and application, the template is the simplest to tweak/fix (its a docker run command with extra steps).

4 hours ago, Mainfrezzer said:

Official should be a manual tag that Lime/Squid attaches to container if there actually happens to be the same entity behind the app, the image and template.

There are vanishingly few application maintainers who maintain their own templates for unRAID.

4 hours ago, Mainfrezzer said:

It just causes confusion and at the worst case annoys the Devs, when something is tagged as official but the issue is something they have no control over.

I can see the case for clarifying its meaning, but i still think the underlying information is valuable. It should be made clear that template maintainers should be the first stop for support for CA applications.

Edited May 28May 28 by primeval_god

11 minutes ago, primeval_god said:

There are vanishingly few application maintainers who maintain their own templates for unRAID.

Just the way it goes for almost every package.

Even a variation of the badge, that makes it clear that it just uses an image that happens to be curated by dockerhub would certainly make things more clear than a flatout "OFFICIAL" one.

On 5/27/2026 at 9:36 PM, Anti-Matt-er said:

I was debating buying another Pi or putting it on one I already have running Home Assistant. I figured this server should be fine since I leave it on, but it's looking like another board would simplify things.

I read that the router will bounce between DNS servers rather than exclusively use the first until it needs to fall back on the second. If another DNS is listed, traffic will route around the PiHole in normal operation. Are you saying that's incorrect?

I myself run pihole on unraid. It's not bad, you just have to think to have 2 dns. That's why I have another unraid running on a small server that I call HA that is running a duplicate instance of each network critical component like DNS. That's the way to go. You can use Pi or anything you want to run pihole. Everything can go down, even a pihole. We have unraid server that have years of uptime (not OS updated) and I've saw pi rebooted daily.

Now for the DNS question, here's how OS work. First, they get the DNS from your DHCP. If you are using pihole, the DHCP should only distribute the IP of the pihole. I'll get on to why later. If you have multiple PiHoles, the DHCP server should give all of them (or at least those you want to be used).

The client itself use a round robin way for queries. Your computer does a lot of queries and this is done to be sure a server doesn't get overloaded. The primary server do tend to receive more query. If the server it query fail as unreachable, it will try to contact another DNS in the list. It doesn't keep a tab on who is up or not, so it might try again for another query on the unreachable server. This can cause latency, but won't stop your Internet from working. That's how all of the internet work (without talking about Load Balancer and other stuff like it, simple flat explanation). It is not a list of server 1, then 2, then 3, it's round robin random style. If you are running windows, run ipconfig /all in a cmd and you will see under DNS a simple list, no priority.

Now, why don't you want your DHCP to broadcast both the PiHole DNS and the router DNS? Normally, you would configure pihole to use your router DNS. The reason is PiHole won't know anything about local network if you connect it directly to an internet DNS. You can do it, but you need to make other configuration in PiHole to forward those type of dns query to the router. For a beginner, it's just easier to connect to the router DNS.

But the reason to not send the Router DNS to the client is because of the round robin said earlier. By doing this, it means that some query goes to pihole, some goes to the router. Which mean that if you block in pihole a website, like www.xxx.com, if at the time of the request, the computer query the router, it won't be blocked.

Don't forget that a computer also have a cache DNS. When a domain name is resolved, it cache the information for a certain amount of time (and browser can have their own cache also seperate of the OS, Edge and Chrome are notorius for that). Which mean that if you resolve and address and then block it, it could still work for a while. That's why in the documentation, it is recommended to close all browser and clear local dns cache of the client when testing; sometime even a reboot.

Edited June 5Jun 5 by Nodiaque

Cool, that confirms what I hard read previously regarding how multiple DNS servers are used.

Since I posted, I ended up buying another Pi to use as the primary DNS. Going to try setting that up this weekend. I was still hoping to use the Unraid server as a secondary DNS, but I absolutely CANNOT get the PiHole container in Docker to utilize it's own IP with the MACVLAN network setting. There is simply nowhere I can find to set the IP, nor am I able to set it with extra parameters. I tried IPVLAN too, but my router may have had trouble with it sharing a MAC address with the Unraid server itself. Tried the container support thread too, with mixed results. Unfortunately, PiHole on Docker in Unraid has been a fail for me 🙁 so far.

I'll tell you how I setup my pihole and docker network. I have many container with their own ip. You will need to enable advanced view everywhere.

I use macvlan and enable host access. This is not required but I do need it for my own scenario.

Then, enable IPv4 custom network on interface eth0. This should be the same range as your router.

Then, in you docker, you will select the custom eth0 network. After that, you will see a place to put a fixed address right under it.

Be sure that in "extra parameter", you have this:

--cap-add=NET_ADMIN --hostname=hostnameofyourpiholehere

After, in the template, you should see "serverip" and "serveripv6" (at least my template have). If your template doesn't have it, just create it

Under value, it should be the same ip you used for fixed ip.

I'm looking at the pihole available in the list and it seems the one I used isn'T listed anymore (but it's using the official pihole docker). I see binhex does also use the official docker so it should work if you add it in that docker. I honestly see way more option in mine but it might be option I added by reading the pihole wiki.

You could use bridge mode. I don't like bridge mode cause it's putting the pihole in it's separate vlan, not what I like. I want them directly on my vlan and that's how I learn to do it. Running over multiple vlan is easier with custom docker network then using default bridge. There's also benefit on using custom vlan vs bridge but I won't go into that here.

I did create a docker pihole with all the var I use. There's many other you can use and the link for them is in the description. It should appear soon in the CA tabs. It's by default in bridge mode.