The issue I am facing:
No matter how many times I run pihole -a -p and set no password, in n mins/hours, its back to asking me for a password again.
How can I make it so it never asks for a password, and the empty password persists?
If its empty, it should not ask you.
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
pihole -d
or do it through the Web interface:
Tools > Generate Debug Log
https://tricorder.pi-hole.net/YqiS7xAz/
If we cant figure it out, Ill just go yell at Jacob (we work together). 
You're running Pi-hole as docker container, right?
How does your docker-compose.yml look like?
Unraid doesnt use docker-compose files. But it also doesnt really do anything out of ordinary. Oddly, I didnt have this issue until some recent upgrades. Also whats odd is that its not like Im changing the password, then restarting the docker. Even with the docker continuing to run, at some point I'll be asked for the password again.
What do you have set up for your template?
Edit: If you can post the yaml from the template please? Redact what you don't want out there.
And Jacob hasn't been a part of Pi-hole for a few years now.
1 Like
Ohhh! Ding ding, you solved it. There is a variable in the docker unraid yaml called "web password". And what looks like some sort of cronjob that makes sure it's set to what you have it as in unraid.
[i] Installing latest logrotate script...
[i] Existing logrotate file found. No changes made.
[i] Assigning password defined by Environment Variable
[✓] New password set
I just removed that key/value. That'll do it! Thanks.
I know Jacob hasn't been part of PiHole for years. I just like to joke with him any time I run into PiHole issues that he should fix it, since he wrote it 
Thanks for the help, this is considered solved.
2 Likes
The behaviour was changed in the 2022.07 release to always set the password to be that of the WEBPASSWORD variable if it was set, which it probably should have been like from the start. The idea being that a user can set their password without having to mount /etc/pihole and manually set the value
That code is only run on container startup.
Does unraid do something weird like restart the container every now and again? Or do you have something in place that periodically pulls the container image and then recreates it? (Thinking auto upgrades - which are ill-advised at the best of times!)
No, Unraid will only restart it if you do a docker upgrade of PiHole or reboot Unraid, which are both manual functions. Whats interesting is I noticed:
[i] Installing latest logrotate script...
[i] Existing logrotate file found. No changes made.
[i] Assigning password defined by Environment Variable
[✓] New password set
Even though the uptime of my container was 2-3 days.
Looking through some of the cronjobs:
# cat pihole
# Pi-hole: A black hole for Internet advertisements
# (c) 2017 Pi-hole, LLC (https://pi-hole.net)
# Network-wide ad blocking via your own hardware.
#
# Updates ad sources every week
#
# This file is copyright under the latest version of the EUPL.
# Please see LICENSE file for your rights under this license.
#
#
#
# This file is under source-control of the Pi-hole installation and update
# scripts, any changes made to this file will be overwritten when the software
# is updated or re-installed. Please make any changes to the appropriate crontab
# or other cron file snippets.
# Pi-hole: Update the ad sources once a week on Sunday at a random time in the
# early morning. Download any updates from the adlists
# Squash output to log, then splat the log to stdout on error to allow for
# standard crontab job error handling.
13 3 * * 7 root PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole updateGravity >/var/log/pihole/pihole_updateGravity.log || cat /var/log/pihole/pihole_updateGravity.log
# Pi-hole: Flush the log daily at 00:00
# The flush script will use logrotate if available
# parameter "once": logrotate only once (default is twice)
# parameter "quiet": don't print messages
00 00 * * * root PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole flush once quiet
@reboot root /usr/sbin/logrotate --state /var/lib/logrotate/pihole /etc/pihole/logrotate
# Pi-hole: Grab local version and branch every 10 minutes
*/10 * * * * root PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole updatechecker local
# Pi-hole: Grab remote version every 24 hours
22 16 * * * root PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole updatechecker remote
@reboot root PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole updatechecker remote reboot
Any of those look like suspects?
Did you notice this more than once, or only once? It will print to the log every time the container is (re)started. I guess because you had WEBPASSWORD set to a value, it was getting set on every container (re)start.
Those cronjobs are all standard and wont restart the container! Each one has a description above it
Multiple times. Basically, any time I needed to get into the UI, I would have to into the console and reset the password to be nothing.
I could certainly add WEBPASSWORD back in, and do some testing to see if it continues.
If you are seeing it multiple times, then something else is causing your container to restart. As I said, those lines are only printed when the startup script is run.
I don't have any experience in unraid unfortunately, so I don't know how it all first together, but perhaps something external to the container? Are there any logs from unraid itself? Perhaps it thinks the container is not responding properly and is giving it a kick (clutching at straws here). Or perhaps a more complete snippit of the container logs?
I don't think there is any need for this.
The container is not restarting. It is often up for weeks at a time, yet still the UI would ask for a new password every time I logged in (every few hours/days).
No worries, I dont have to try to reproduce it. We'll consider this solved.
Thanks again for the help.
There is still an underlying issue, in that the container appears to be doing something that it is not supposed to do. Your password getting set (to the configured value) is just a consequence of the fact that something else is broken/misconfigured along the line.
Here is my container log since I upgraded it to latest 2 days ago:
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service cron: starting
s6-rc: info: service cron successfully started
s6-rc: info: service _uid-gid-changer: starting
s6-rc: info: service _uid-gid-changer successfully started
s6-rc: info: service _startup: starting
FTLCONF_REPLY_ADDR4 is deprecated. Converting to FTLCONF_LOCAL_IPV4
[i] Starting docker specific checks & setup for docker pihole/pihole
[i] Setting capabilities on pihole-FTL where possible
[i] Applying the following caps to pihole-FTL:
* CAP_CHOWN
* CAP_NET_BIND_SERVICE
* CAP_NET_RAW
* CAP_NET_ADMIN
[i] Ensuring basic configuration by re-running select functions from basic-install.sh
[i] Installing configs from /etc/.pihole...
[i] Existing dnsmasq.conf found... it is not a Pi-hole file, leaving alone!
[i] Installing /etc/dnsmasq.d/01-pihole.conf...
[✓] Installed /etc/dnsmasq.d/01-pihole.conf
[i] Installing /etc/.pihole/advanced/06-rfc6761.conf...
[✓] Installed /etc/dnsmasq.d/06-rfc6761.conf
[i] Installing latest logrotate script...
[i] Existing logrotate file found. No changes made.
[i] Pre existing WEBPASSWORD found
[i] Added ENV to php:
"TZ" => "europe/London",
"PIHOLE_DOCKER_TAG" => "2022.09.3",
"PHP_ERROR_LOG" => "/var/log/lighttpd/error-pihole.log",
"CORS_HOSTS" => "",
"VIRTUAL_HOST" => "192.168.1.253",
[i] Using IPv4 and IPv6
[i] Preexisting ad list /etc/pihole/adlists.list detected (exiting setup_blocklists early)
[i] Setting DNS servers based on PIHOLE_DNS_ variable
[i] Applying pihole-FTL.conf setting LOCAL_IPV4=192.168.1.253
[i] Applying pihole-FTL.conf setting REPLY_ADDR4=192.168.1.253
[i] FTL binding to default interface: eth0
[i] Enabling Query Logging
[i] Testing lighttpd config: Syntax OK
s6-rc: info: service _startup successfully started
s6-rc: info: service pihole-FTL: starting
s6-rc: info: service pihole-FTL successfully started
s6-rc: info: service lighttpd: starting
s6-rc: info: service lighttpd successfully started
s6-rc: info: service _gravityonboot: starting
s6-rc: info: service _gravityonboot successfully started
s6-rc: info: service legacy-services: starting
[i] All config checks passed, cleared for startup ...
[i] Docker start setup complete
Pi-hole version is v5.12.1 (Latest: v5.12.1)
AdminLTE version is v5.15 (Latest: v5.15)
FTL version is v5.18 (Latest: v5.18)
Container tag is: 2022.09.3
[i] pihole-FTL (no-daemon) will be started as root
Checking if custom gravity.db is set in /etc/pihole/pihole-FTL.conf
Skipping Gravity Database Update.
s6-rc: info: service legacy-services successfully started
And that's it, nothing else logged.
Of particular note:
...
s6-rc: info: service _startup: starting
...
s6-rc: info: service _startup successfully started
...
That is the oneshot s6 service that runs the startup script linked in a previous comment. As it is oneshot it should not be running more than once, and if it is (you say that you are seeing those log outputs in there several times, suggesting container restart or something other) - then there is a problem somewhere - either in your configuration, some incompatibility with unRaid, or some as yet undiscovered edge case.
But this is why I asked for fuller logs, so that we may spot something that doesn't look right, and understand what is actually happening - because as it is designed, you should not be seeing this behaviour.
This is my log in it's entirety, from the logs link of the docker container:
text error warn system array login
s6-rc: info: service cron successfully started
s6-rc: info: service _uid-gid-changer: starting
s6-rc: info: service _uid-gid-changer successfully started
s6-rc: info: service _startup: starting
s6-rc: info: service _startup successfully started
s6-rc: info: service pihole-FTL: starting
s6-rc: info: service pihole-FTL successfully started
s6-rc: info: service lighttpd: starting
s6-rc: info: service lighttpd successfully started
s6-rc: info: service _gravityonboot: starting
s6-rc: info: service _gravityonboot successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
Device "br0" does not exist.
Device "br0" does not exist.
Device "br0" does not exist.
Device "br0" does not exist.
ServerIP is deprecated. Converting to FTLCONF_LOCAL_IPV4
[i] Starting docker specific checks & setup for docker pihole/pihole
[i] Setting capabilities on pihole-FTL where possible
[i] Applying the following caps to pihole-FTL:
* CAP_CHOWN
* CAP_NET_BIND_SERVICE
* CAP_NET_RAW
* CAP_NET_ADMIN
[i] Ensuring basic configuration by re-running select functions from basic-install.sh
[i] Installing configs from /etc/.pihole...
[i] Existing dnsmasq.conf found... it is not a Pi-hole file, leaving alone!
[✓] Installed /etc/dnsmasq.d/01-pihole.conf
[✓] Installed /etc/dnsmasq.d/06-rfc6761.conf
[i] Installing latest logrotate script...
[i] Existing logrotate file found. No changes made.
[i] Assigning password defined by Environment Variable
[✓] New password set
[i] Added ENV to php:
"TZ" => "America/Los_Angeles",
"PIHOLE_DOCKER_TAG" => "2022.09.3",
"PHP_ERROR_LOG" => "/var/log/lighttpd/error-pihole.log",
"CORS_HOSTS" => "",
"VIRTUAL_HOST" => "192.168.88.4",
[i] Using IPv4
[i] Preexisting ad list /etc/pihole/adlists.list detected (exiting setup_blocklists early)
[i] Setting DNS servers based on PIHOLE_DNS_ variable
[i] Applying pihole-FTL.conf setting LOCAL_IPV4=192.168.88.4
[i] FTL binding to custom interface: br0
[i] Enabling Query Logging
[i] Testing lighttpd config: Syntax OK
[i] All config checks passed, cleared for startup ...
[i] Docker start setup complete
Current Pi-hole version is v5.12.1
Current AdminLTE version is v5.15
Current FTL version is v5.18
Container tag is: 2022.09.3
[i] pihole-FTL (no-daemon) will be started as pihole
Checking if custom gravity.db is set in /etc/pihole/pihole-FTL.conf
[i] Neutrino emissions detected...
[✓] Pulling blocklist source list into range
[✓] Preparing new gravity database
[i] Using libz compression
[i] Target: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
[✓] Status: Retrieval successful
[i] Analyzed 139583 domains
[i] List stayed unchanged
[✓] Creating new gravity databases
[✓] Storing downloaded domains in new gravity database
[✓] Building tree
[✓] Swapping databases
[✓] The old database remains available.
[i] Number of gravity domains: 139583 (139583 unique domains)
[i] Number of exact blacklisted domains: 0
[i] Number of regex blacklist filters: 0
[i] Number of exact whitelisted domains: 1
[i] Number of regex whitelist filters: 0
[✓] Cleaning up stray matter
[✓] FTL is listening on port 53
[✓] UDP (IPv4)
[✓] TCP (IPv4)
[✓] UDP (IPv6)
[✓] TCP (IPv6)
[✓] Pi-hole blocking is enabled
root@ea1f31f3f4bf:/# uptime
10:33:24 up 1 day, 13:44, 0 users, load average: 0.41, 0.56, 0.63
Edit: And for completeness here is the run command
docker run
-d
--name='pihole'
--net='br0'
--ip='192.168.88.4'
-e TZ="America/Los_Angeles"
-e HOST_OS="Unraid"
-e HOST_HOSTNAME="SuperNova"
-e HOST_CONTAINERNAME="pihole"
-e 'TCP_PORT_53'='53'
-e 'UDP_PORT_53'='53'
-e 'TCP_PORT_80'='80'
-e 'PIHOLE_DNS_'='192.168.88.2'
-e 'TZ'='America/Los_Angeles'
-e 'WEBPASSWORD'='1234'
-e 'INTERFACE'='br0'
-e 'ServerIPv6'=''
-e 'IPv6'='False'
-e 'DNSMASQ_LISTENING'='all'
-e 'WEBUIBOXEDLAYOUT'='boxed'
-e 'UDP_PORT_67'='67'
-e 'TCP_PORT_443'='443'
-e 'FTLCONF_REPLY_ADDR4'='192.168.88.4'
-l net.unraid.docker.managed=dockerman
-l net.unraid.docker.webui='http://[IP]:[PORT:80]/admin'
-l net.unraid.docker.icon='https://i.imgur.com/OWkNcEn.png'
-v '/mnt/user/appdata/pihole/pihole/':'/etc/pihole/':'rw'
-v '/mnt/user/appdata/pihole/dnsmasq.d/':'/etc/dnsmasq.d/':'rw'
--cap-add=NET_ADMIN
--restart=unless-stopped 'pihole/pihole:latest'
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.