DEV Community: Yoshi Nakamoto

Pi-hole v6: Setting up wildcard domains

Yoshi Nakamoto — Fri, 12 Sep 2025 12:57:49 +0000

In my previous article, I talked about my password and login troubles on Pi-hole V6, it seems that this isn't the end of my journey, as I've ran into new ones while trying to set up wildcard domains on Pi-hole v6.

TLDR version: Dnsmasq config files no longer loads by default on Pi-hole v6. You will need to enable it manually via All Settings > Miscellaneous > misc.etcdnsmasq_d. If you just need to insert a few lines, skip creating the config file and add it to > misc.dnsmasq_line instead on the same page.

Creating a dnsmasq config file for wildcard domains

Pi-hole doesn't have a way to setup wildcard domains via it's web dashboard. This can only be done manually by adding a dnsmasq configuration file under /etc/dnsmasq.d.

You first a create a config file, e.g. /etc/dnsmasq.d/99-myserver.com.conf (where the 99 is just the order of priority if you are managing multiple configuration files), and inside that config file, just put in:

server=/myserver.com/#
address=/.myserver.com/100.101.102.103

The first line server=/myserver.com/# prevents Pi-hole from trying to resolve myserver.com using an upstream DNS.

The second line address=/.myserver.com/100.101.102.103 tells Pi-hole that the domain myserver.com + any subdomain *.myserver.com should be pointed to 100.101.102.103.

Pi-hole v6 doesn't load dnsmasq config file by default

This is the part that tripped me up. In v6, dnsmasq config files are no longer loaded by default. You will need to enable it via All Settings > Miscellaneous > misc.etcdnsmasq_d.

Once enabled, you should be able to get Pi-hole to resolve the hostname to correct IP address. You can test it using dig by telling it to query the hostname via your Pi-hole's IP address, the IP 192.168.1.123 is used in the example below.

$ dig abc.myserver.com @192.168.1.123 +nocomments

; <<>> DiG 9.10.6 <<>> abc.myserver.com @192.168.1.123 +nocomments
;; global options: +cmd
;abc.myserver.com.          IN  A
abc.myserver.com.       0   IN  A   100.101.102.103

;; Query time: 4 msec
;; SERVER: 192.168.1.123#53(192.168.1.123)
;; WHEN: Fri Sep 12 21:00:54 +08 2025
;; MSG SIZE  rcvd: 57

Just a few lines? Skip creating the config file.

It appears that on the same settings page there is also another field misc.dnsmasq_lines. If you have just a few config lines, just enter it in there saves you the trouble of having jump into the terminal to create the file.

Perfect! With wildcard domains working, I can now skip having to manually assign each subdomain for each of the web services I intend to run on my Unraid server.

Pi-hole v6: How to actually set a password and login properly?

Yoshi Nakamoto — Fri, 12 Sep 2025 12:15:06 +0000

My initial experience setting up Pi-hole v6 on Unraid was a real head-banger. I just could not log in at all.

TLDR version: Set password using pihole setpasswd and login to Pi-hole's web dashboard via a hostname, not raw IP address.

What's changed with passwords on Pi-hole V6?

I went down the password rabbit hole, trying to figure what has changed between v5 and v6, and what may or may not apply when running Pi-hole under Unraid's environment.

Here are some of my learnings:

The initial randomly generated password only show up once. If you've restarted the Docker instance (which I did as I was changing a few container configs), this does not show up in the logs anymore. If you've missed the boat, just skip over and set a password instead.
The new command to set a password is now pihole setpasswd. While pihole -a -p still works, pihole setpasswd is the newer preferred one now. Also, when you set a password, the hash of the password is now stored in /etc/pihole/pihole.toml for v6 (not /etc/pihole/setupVars.conf as that is for v5).
WEBPASSWORD is now FTLCONF_webserver_api_password. Not a secure practice (as this is visible in plain text in your docker config file), but if you decide to set a password via the Docker container's variable, WEBPASSWORD no longer works, use FTLCONF_webserver_api_password instead.
WEBPASSWORD_FILE still works. You can create a file containing the password and assign the path of the file to the WEBPASSWORD_FILE docker environment variable on v6. Yes, I know what you're thinking, the naming is not consistent anymore.
Pointing FTLCONF_webserver_api_password or WEBPASSWORD_FILE to a Docker secret entry. This is not for Unraid. Using Docker secrets requires you to setup Docker Compose or Docker Swarm on Unraid, which isn't standard practice on Unraid.

In short, just run pihole setpasswd in the Docker terminal of your Pi-hole instance.

Is the login page broken?

I have tried everything above and I still can't login. I'd enter my password on the login page, hit enter, and... nothing. The page would just refresh. My login attempts were just being silently rejected.

Upon inspecting the /auth network request, I found a clue - it was returning a no SID provided message in the response.

Taking an educated guess, SID likely means Session ID. This suggests that Pi-hole possibly refused to start an authenticated session.

Does Pi-hole strictly requires HTTPS to establish a session? That doesn't make any sense. Why would a service that you're setting up for the first time require HTTPS? Accessing via the HTTP protocol is normally what folks do for initial configuration, as doing cert signing and validation upfront complicates the setup process.

Pi-hole Needs a Hostname!

In a fit of frustration, I decided to put the issue aside and set up the Nginx reverse proxy to Pi-hole, as I was planning on doing it anyway. And that's when it happened - the login magically worked!

It turns out Pi-hole wants to be accessed via a hostname rather than a raw IP address. Therefore, the fix for the broken login is actually embarrassingly simple, just add an entry in your local machine's hosts file.

pi-hole.lan 12.34.56.78

And just like that, I can finally login! It's frustrating that such a simple, non-obvious step was the cause of so much headache. Hopefully, this saves someone else from the troubles I endured.

rcp & rmv: copying & moving using rsync with the simplicity of cp & mv

Yoshi Nakamoto — Tue, 09 Sep 2025 16:14:09 +0000

These two commands rcp and rmv acts a direct replacement for cp and mv for copying or moving files using rsync.

Instead of doing:

rsync -avh --partial --info=progress2 source dest
rsync -avh --partial --info=progress2 --remove-source-files source dest

Now you can simply do:

rcp source dest
rmv source dest

You can also include additional rsync options, here are two examples with -z for compression (great for faster network transfers) and --dry-run to see what gets transferred without actually transferring (yet).

rcp -z source dest
rmv --dry-run source dest

The rcp() and rmv() shell functions

You can copy and paste the following lines in your .zshrc or .bashrc file.

# Function to copy files using rsync
# Usage: rcp [rsync_options] source [source2...] destination
rcp() {
  rsync -avh --partial --info=progress2 "$@"
}

# Function to move files using rsync (and delete empty directories after)
# Usage: rmv [rsync_options] source [source2...] destination
rmv() {
  local default_options=(-avh --partial --info=progress2 --remove-source-files)
  local rsync_options=()
  local is_dry_run=0

  # Separate options from paths
  while [[ "$#" -gt 0 ]]; do
    if [[ "$1" == "--dry-run" ]] || [[ "$1" == "-n" ]]; then
      is_dry_run=1
      rsync_options+=("$1")
    elif [[ "$1" == "--" ]]; then
      shift
      break
    elif [[ "$1" == "-"* ]]; then
      rsync_options+=("$1")
    else
      break
    fi
    shift
  done

  # Check if at least two arguments remain (sources and destination)
  if [[ "$#" -lt 2 ]]; then
    echo "Usage: rmv [rsync_options] source [source2...] destination"
    return 1
  fi

  local all_paths=("${@:1:$#}")
  local source_paths=("${all_paths[@]:0:${#all_paths[@]}-1}")
  local dest_path="${all_paths[-1]}"

  # Execute rsync by passing options from the arrays
  rsync "${default_options[@]}" "${rsync_options[@]}" "${source_paths[@]}" "$dest_path" && {
    for source_dir in "${source_paths[@]}"; do
      if [[ -d "$source_dir" ]]; then
        if [[ $is_dry_run -eq 0 ]]; then
          echo "Removing empty directory '$source_dir'..."
          find "$source_dir" -type d -empty -delete
        else
          echo "Dry run: would remove empty directory '$source_dir'..."
          find "$source_dir" -type d -empty -print
        fi
      fi
    done
  }
}

macOS users: Upgrade your rsync

The default rsync tool that comes bundled with macOS is v2.6.9 does not support the --info=progress2 command, so run brew install rsync to get the latest rsync.

$ /usr/bin/rsync --version
openrsync: protocol version 29
rsync version 2.6.9 compatible

$ /opt/homebrew/bin/rsync --version
rsync  version 3.4.1  protocol version 32

Once installed, add this to your .zshrc or .bashrc file to replace the default rsync with homebrew's rsync.

alias rsync="/opt/homebrew/bin/rsync"

Handling the removal of empty directories

The --remove-source-files option in rsync does not remove empty directories after all the files has been moved. Therefore, in the rmv() shell function above, you will notice that it will run additional commands to remove the empty directories using find after rsync has finished running.

So there you have it! These two little shell functions, rcp and rmv, wrapping up the power of rsync into something as easy to use as cp and mv.

No more remembering long strings of options, just a simple command that gets the job done, with a nice progress update to boot.