T0rqueWr3nch

I came up with an additional solution for using a Pi-hole docker container:

Lol, it happened to me last night while I was adding my cell phone at a coffee shop! Thankfully, I had a backup WireGuard tunnel on my unRAID development VM, but I figured I'd warn everyone else.

ADDITIONAL WARNING: DO NOT add a new client ("peer") to WireGuard if you are connected remotely. Adding a new peer toggles the WireGuard tunnel off which will render you unable to reconnect. All the more reason to always have more than one way into your homelab.

Added an additional quick start guide for WireGuard with Linux clients: How to Set Up a WireGuard Client on Linux with .conf File

For those of you struggling to get WireGuard working with the Pi-hole docker container, this should be wholly unnecessary. I reproduced the problem on my unRAID VM and came up with an alternative solution that doesn't require anything nearly as exotic as a VLAN or an additional interface. All you need to do is convert the Pi-hole container to a host network type instead of the ipvlan you normally set up. Instructions here: As a bonus, I have seen sporadic reports of the Pi-hole container failing to start due to "dnsmasq: failed to create listening socket for port 53: Address already in use". This same solution should fix that problem.

Instructions For Pi-Hole with WireGuard: For those of you who don't have a homelab exotic enough to have VLANs and who also don't have a spare NIC lying around, I have come up with a solution to make the Docker Pi-Hole container continue to function if you are using WireGuard. Here are the following steps I used to get a functional Pi-hole DNS on my unRAID VM with WireGuard: 1a) Since we're going to change our Pi-hole to a host network, we'll first need to change your unRAID server's management ports so there isn't a conflict with Settings > Management Access: 1) Take your Pi-hole container and edit it. Change the network type to "Host". This will allow us to avoid the problems inherent in trying to have two bridge networks talk to each other in Docker. (Thus removing our need to use a VLAN or set up a separate interface). You'll also want to make sure the ServerIP is set to your unRAID server's IP address and make sure that DNSMASQ_LISTENING is set to single (we don't want PiHole to take over dnsmasq): 2) We'll need to do some minor container surgery. Unfortunately the Docker container lacks sufficient control to handle this through parameters. For this step, I will assume you have the following volume mapping, modify the following steps as needed: 3) Launch a terminal in unRAID and run the following command to cd into the above directory: cd /mnt/cache/appdata/pihole/dnsmasq.d/ 4) We're going to create an additional dnsmasq config in this directory: nano 99-my-settings.conf 5) Inside this dnsmasq configuration, add the following: bind-interfaces Where the listen-address is the IP address of your unRAID server. The reason this is necessary is because without it, we end up with a race condition depending on if the Docker container or libvirt starts first. If the Docker container starts first (as what happens when you set the container to autostart), libvirt seems to be unable to create a dnsmasq which could cause problems for those of you with VMs. If libvirt starts first, you run into a situation where you get the dreaded: "dnsmasq: failed to create listening socket for port 53: Address already in use". This is because without the above configuration, the dnsmasq created by Pi-hole attempts to listen on all addresses. By the way, this should also fix that error for those of you running Pi-hole normally (I've seen this error a few times in the forum and I can't help but wonder if this was the reason we went with the ipvlan set up in the first place). Now, just restart the container. I tested this and it should not cause any interference with the dnsmasq triggered by libvirt.

Got it working! Running on the host network, there is a conflict with unRAID's dnsmasq listening on port 53. I killed the dnsmasq process, so we'll need a more elegant solution. Any idea what unRAID is using it for? It looks like it was listening on an IP address that's in a subnet I don't even use. Update: Looks like we probably use the dnsmasq for libvirt, so probably not the best to just outright kill it...

I staged this on my unRAID VM. I'll give it a try in a few minutes.

So maybe this is an option we should present then as opposed to creating a VLAN set up that most probably don't have networks that are ready for one or an interface that requires hardware they might not have on hand?

Minor point of clarification- PiHole is just a glorified DNS; it just prevents the resolution to IP address of domain names associated with ads; traffic does not go through it, but your point is well-taken. Just to give some background on the "why": The problem is that Docker, by design, isolates bridged networks from each other: https://docs.docker.com/network/bridge/ (This may be a bit of an oversimplification since I think when you use the "custom" network type in the Docker container, you're actually using an ipvlan network, but the end result is apparently the same). The way around this is to either move to another interface or set up a router-on-a-stick with VLANs as Hoopster/bonienl have suggested. However, I recognize that this isn't necessarily the most practical solution. VLANs carry a lot of overhead in the sense that your network has to be set up for them. And you don't necessarily have a second NIC for the alternative interface option. It would be nice if you could just switch to the host network type in the Docker container, but unfortunately PiHole has to listen on 80 which then would create a conflict with unRAID which also uses :80 for the web GUI. I personally don't use PiHole due to the last time I tried it, it was a bit overzealous in its blocking and started blocking Google-owned domains, so I'm flying a little blind here. It may be possible to surgically modify iptables to fix this. I'll try to stand up an instance of PiHole in my unRAID VM and see if I can reproduce the issue and then potentially fix it. Unfortunately, I'm about to fly out for an early Christmas vacation and might not be able to get to it for a week. -TorqueWrench

That reminds me of an important optimization he can make since he didn't say what those write speeds to the array were. zwolfinger, you can improve your array write performance by changing the tunable to "reconstruct write":

Think of the entire data stream as a pipeline. The flow rate is determined by the narrowest pipe. 800 mbps is about as fast as you can hope for due to the packet overhead on a 1 Gbps connection. If you're using standard 5400 RPM drives in your array, you can get anywhere from 50-100 Mbps sequential write speeds, which means that your standard home gigabit ethernet saturates your drive write speeds. This is why a lot of us don't bother with the expense/hassle of a 10G network. So would it have been faster? Probably not, but it might have been more convenient. The reason it's slower to write to the "RAID" (it's not actually a RAID array, hence the name, unRAID) array is because there's no striping in unRAID, you're basically writing to one disk at a time while unRAID does the redundancy calculation read/writes on the other drives.

Hi pi, Unassigned Devices plugin would be your best bet. Install the plugin, then you should just be able to connect your WD MyCloud directly to your unRAID server via USB. Then, using the binhex-krusader Docker container (a file explorer-like program), be able to transfer the files directly from the USB drive to the array. Let me know if you need more detail, Torquewrench

Hi everyone, with a lot of us travelling for Thanksgiving this week, I've updated this guide. This is just a friendly reminder to double check your homelab/unRAID server set up before leaving. Nothing ruins an otherwise perfect trip more than planning on watching a movie with the family while you're gone and the server is down or worrying about what may be wrong at home. The guide has been updated with additional articles on: The Homelab Lifeline: The Easiest Guide to Creating a Reverse SSH Tunnel Remote Start for Servers: How To Set Up Wake-on-LAN (WOL) Hope this helps yall out with building a more resilient system!

That's what I got on my last round, which are still pretty good drives, rumored to be HGST Ultrastar essentially: Note that you will almost certainly have to tape over the 3.3V pin to use it in your unRAID rig: https://amzn.to/2Ncc2WR. I find a steady hand and a pair of tweezers helps to install the Kapton tape relatively easily. Instructions here: https://www.instructables.com/id/How-to-Fix-the-33V-Pin-Issue-in-White-Label-Disks-/ Unless they change things on us, these are not SMR drives. -Torquewrench