Getting this as of todays update.
Seems that your Pi-hole failed to force a time sync due to lack of permissions, presumably after detecting a mismatch between the latest database queries and your system's current time following a reboot.
What platform do you run your Pi-hole on?
And do you run it as bare-metal or as a Docker container?
1 Like
No, I did not reboot. Running in a PROXMOX container. It only started doing that, after todays update. No other changes where made, that I am aware of.
1 Like
Exactly the same here, except I'm using Debian in a proxmox container
Both of your said "container" instead of "virtual machine" so I guess you are using LXC virtualization here? Mind that these containers are not dedicated machines by themselves but use the host's kernel.
The proxmox documentation explicitly states:
For security reasons, access to host resources needs to be restricted. Therefore, containers run in their own separate namespaces. Additionally some syscalls (user space requests to the Linux kernel) are not allowed within containers.
Further down, they suggest you could try
To disable AppArmor for a container, add the following line to the container configuration file located at
/etc/pve/lxc/CTID.conf:lxc.apparmor.profile = unconfinedWarning Please note that this is not recommended for production use.
and check if this makes time synchronization work but mind the warning. If so, the proxmox support forum (or even Google) may know how to give only the time setting capability selectively to your Pi-hole container. Unfortunately, the documentation isn't clear about if this also allows the aforementioned restricted syscalls so we really need to try it.
I'm not myself familiar with Proxmox, but it turns out I'm the end that proxmox won't allow your Pi-hole container to set the time for you automatically, you can easily disable this feature by seeing either the config option ntp.sync.interval = 0 or ntp.sync.server = "".
Will have to check on that, but Pi-Hole was fine until todays update... So for me, it's Pi-Hole and not PROXMOX "fault"...
Pi-hole just introduced NTP synchronization as a new feature and it runs just fine on any bare metal installations as well as inside docker containers. So I indeed play the ball back into proxmox's field.
1 Like
Same issue for me on my Docker Container on my Raspi 4B:
2024-06-30 16:14:54.948 ERROR Error NTP client: Failed to adjust time during NTP sync: Insufficient permissions
2024-06-30 16:29:11.365 WARNING API: Bad request (The API is hosted at pi.hole/api, not pi.hole/admin/api)
2024-06-30 17:05:15.965 WARNING API: Bad request (The API is hosted at pi.hole/api, not pi.hole/admin/api)
2024-06-30 17:05:22.303 WARNING API: Bad request (The API is hosted at pi.hole/api, not pi.hole/admin/api)
2024-06-30 17:14:59.182 INFO Received 8/8 valid NTP replies from pool.ntp.org
2024-06-30 17:14:59.182 INFO Time offset: -1.246214e+00 ms (excluded 1 outliers)
2024-06-30 17:14:59.182 INFO Round-trip delay: 2.128363e+01 ms (excluded 1 outliers)
2024-06-30 17:14:59.182 ERROR Error NTP client: Failed to adjust time during NTP sync: Insufficient permissions
2024-06-30 18:15:03.444 INFO Received 8/8 valid NTP replies from pool.ntp.org
2024-06-30 18:15:03.444 INFO Time offset: -1.063449e+00 ms (excluded 1 outliers)
2024-06-30 18:15:03.445 INFO Round-trip delay: 1.818500e+01 ms (excluded 1 outliers)
2024-06-30 18:15:03.445 ERROR Error NTP client: Failed to adjust time during NTP sync: Insufficient permissions
2024-06-30 19:15:07.915 INFO Received 8/8 valid NTP replies from pool.ntp.org
2024-06-30 19:15:07.916 INFO Time offset: 2.336434e+00 ms (excluded 1 outliers)
2024-06-30 19:15:07.916 INFO Round-trip delay: 3.791441e+01 ms (excluded 1 outliers)
2024-06-30 19:15:07.916 ERROR Error NTP client: Failed to adjust time during NTP sync: Insufficient permissions
2024-06-30 20:15:12.184 INFO Received 8/8 valid NTP replies from pool.ntp.org
2024-06-30 20:15:12.185 INFO Time offset: -6.758145e-01 ms (excluded 1 outliers)
2024-06-30 20:15:12.185 INFO Round-trip delay: 2.052975e+01 ms (excluded 1 outliers)
2024-06-30 20:15:12.185 ERROR Error NTP client: Failed to adjust time during NTP sync: Insufficient permissions
2024-06-30 20:54:23.814 WARNING API: Bad request (The API is hosted at pi.hole/api, not pi.hole/admin/api)
2024-06-30 20:54:29.671 WARNING API: Bad request (The API is hosted at pi.hole/api, not pi.hole/admin/api)
Agree, but then we need a option to disable it and it's already in the Webinterface implemented. So all good.
From my pov we can close this
In Docker, you may need to explicitly grant SYS_TIME to the container. e.g in a compose file that would look like:
cap_add:
- SYS_TIME
3 Likes
i think this fixed it, ty!
Nice for you guys, that know what you are doing... 
So what do I need to "turn off"? I am assuming it is something in this tab.
Looks like disabling these two, "fixed" it....
I hoped that it fix it, but doesn't, The error occurs again if you restart dns resolver. Looks like the config page doesn't stop to act as a local ntp server
True, not solved and I do not have to restart anything! Even after disabling the NTP options, the error keeps coming back. 
1 Like
No, these are the wrong config options.
Either remove the left string (empty out the text field) or set the right value to zero - or both, like:
Ok, change it to 0. Let's see what happens. Thanks 4 the info... 
Also having issues since the arrival of ntp.
Context: running pi-hole and unbound in docker on a firewalla purple device, which redirects outgoing ntp requests to itself as it provides ntp functionality.
having adapted the yaml config (this stopped the error message as per above) and the pi-hole settings, I still have to use another dns provider than the 'internal' pi-hole on the device...
I saw some open issues still on github.com so will keep an eye.
Why? If you have even more context for us, we can immediately start working on a fix. The issue is always that if users decide to wait for a bug to be fixed, it takes as long until the first one steps up and provides sufficient context so an actual fix can be prepared.
On other notes, it'd be great if you could test if your current NTP improvements branch tweak/ntp_delay already helps with the issue you are facing:
pihole checkout ftl tweak/ntp_delay
you can - at any point - go back without issues using
pihole checkout ftl development-v6
Well, as previous posts of mine my indicate, that is my natural reaction. It's just that time is very very tight as we're less then a week away from our wedding (which requires us to travel through approx 2.8 countries from West to East of Europe ) and I've been promoted to an absolutely awesome but utterly intense new job...
And of course, any changes I do need to happen when the family is either sleeping or out...
I assume the special branches are also pushed to the docker images?
I just tested this problem still exists
Pi Hole runs under debiaqn 12 in the LXC container under Proxmox