`DBusFatalError: Automatic time synchronization is enabled` on initial setup (blocking all subsequent setup steps)

[andrewjbennett]

Describe the issue you are experiencing

I'm attempting to set up HA on a Raspberry Pi 3, using the image from github (haos_rpi3-64-16.0.img.xz) flashed directly onto an SD card (using dd).

The system boots, but the initial setup fails / isn't able to progress.

Looking in the logs there are many errors related to the supervisor not having internet access etc (despite me viewing this from the web viewer, so it definitely has a network connection), but the initial/underlying error is that the system time is out of date, but it's unable to set it because automatic time synchronization is enabled:

2024-10-09 02:43:53.650 WARNING (MainThread) [supervisor.core] System time/date shift over more than 3 days found!
2024-10-09 02:43:53.650 INFO (MainThread) [supervisor.host.control] Setting new host datetime: 2025-07-12T09:26:28+00:00
2024-10-09 02:43:53.676 CRITICAL (MainThread) [supervisor.core] Fatal error happening on load Task [...] supervisor.exceptions.DBusFatalError: Automatic time synchronization is enabled

Presumably this is because NTP is enabled.

I can't disable NTP, because I get an error about a read-only filesystem.

I was able to set the correct date myself using date -s; I couldn't find any sort of override option for datetimectl (which is the cli interface to the same underlying functions the supervisor is using).

I'm not sure whether you'd be able to mitigate this by disabling NTP immediately prior to https://github.com/home-assistant/supervisor/blob/9a0f530a2f639af81d896cb35a9c12012d1e1a42/supervisor/core.py#L424 and then re-enabling it again if it was previously enabled, or whether that would also fail due to the read-only file system.

To be clear: I have successfully worked around this problem, so I don't need immediate help, but I imagine this would have tripped up anybody who didn't know how to drop into a login shell and directly adjust the time using date.

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

Steps to reproduce the issue

1. Have the system clock set to 2024 (it's currently 2025) for some reason (I don't think the raspi3 has a RTC, so I'm not sure where it got that date from?)
2. Do a standard install of HA, following the documented process
3. Watch as it's unable to make any progress, due to a lot of errors about the supervisor not having internet access ...

Anything in the Supervisor logs that might be useful for us?

(I don't have access to this because I haven't finished setup yet)

System information

(I haven't "configured" it yet so don't have system information, sorry -- I'm using a Raspberry Pi 3, using the image haos_rpi3-64-16.0.img)

Supervisor diagnostics

(again, I don't have access to this yet because I haven't finished setup)

Additional information

No response

[agners]

Hm, interesting find, thanks for the detailed report!

We have two mechanism which set time: systemd-timesyncd which tries to use time.cloudflare.com via NTP and Supervisor built-in mechanism which sets the time roughly based on our own https based service. It seems that the first mechanism failed in your case (do you happen to know if your network environment or your provider indeed blocks time.cloudflare.com?).

However, that the second mechanism fails with supervisor.exceptions.DBusFatalError: Automatic time synchronization is enabled is new to me. I wonder if that is a change in systemd-timesyncd's D-Bus API 🤔 .

[sairon]

There's no recent change in the D-Bus API, respectively Systemd's timedated imlementation for setting the time. It's been present at least since v213 from 2014, and as I confirmed, the OS version from the time when #2901 was implemented (OS 5.13) also returns this error:

# busctl call org.freedesktop.timedate1 /org/freedesktop/timedate1 org.freedesktop.timedate1 SetTime xbb 1753187696000000 1 0
Call failed: Automatic time synchronization is enabled

So it makes me wonder if this fallback implementation ever worked. Maybe it was only tested on Supervised installs where NTP was disabled?

[martinbrose]

Hi, I had the exact same problem...

Took me quite a while to use the same workaround via the cli of using login and date -s.

Not sure how easy a quick fix is? But in the interim, could a warning be added to the screen "Preparing Home Assistant" that guides the user to the workaround when the supervisor knows its clock is behind? It would have saved me quite some frustration and time...

Thank you!

[martinbrose]

I investigated further and in my case the problem is with me using PiHole's DHCP functionality, which comes with ntp server functionality as default. When I deactivate everything in the Network Time Sync settings (ntp), Home Assistant starts fine on my Raspberry Pi.

Maybe add something to the page https://www.home-assistant.io/more-info/unhealthy/setup (shown when you click setup under the status Unhealthy on the Home Assistant observer page on port 4357) that highlights:

• potential problem when your DHCP server provides ntp
• outlines the manual workaround with login and 'date -s "YYYY-MM-DD HH:MM:SS"`?

[agners]

I investigated further and in my case the problem is with me using PiHole's DHCP functionality, which comes with ntp server functionality as default.

Technically, HAOS should prefer the DHCP provided NTP server in that case. Can you check, does /run/systemd/timesyncd.conf.d/10-ntp.conf exist in your setup and does it contain the IP of the NTP server?

And if you can reproduce the failing case again, the log output of journalctl -u systemd-timesyncd would be helpful.

[martinbrose]

The basic problem in my setup was that I activated DNSSEC in my Pi-hole settings and that failed for some reason. That resulted in Pi-hole not being able to resolve pool.ntp.org. I had to deactivate that and now the Pi-hole ntp server functionality works.

Before that, running ntpdate -q 127.0.0.1 on my Pi-hole server showed "no eligible servers," and earlier ntpdig reported "stratum 0, probable KOD packet".

I can change this and reproduce the failing case again, no problem.

[martinbrose]

And yes, /run/systemd/timesyncd.conf.d/10-ntp.conf exists on HAOS and shows the IP address of my Pi-hole DHCP server.

[martinbrose]

Here is the output from journalctl -u systemd-timesyncd:

Oct 08 15:43:33 homeassistant systemd[1]: Starting Network Time Synchronization...
Oct 08 15:43:34 homeassistant systemd[1]: systemd-timesyncd.service: Deactivated successfully.
Oct 08 15:43:34 homeassistant systemd[1]: Stopped Network Time Synchronization.
Oct 08 15:43:34 homeassistant systemd[1]: Starting Network Time Synchronization...
Oct 08 15:43:34 homeassistant systemd[1]: Started Network Time Synchronization.
Oct 08 15:43:52 homeassistant systemd-timesyncd[720]: Network configuration changed, trying to establish connection.
Oct 08 15:44:01 homeassistant systemd-timesyncd[720]: Network configuration changed, trying to establish connection.
Oct 08 15:44:01 homeassistant systemd-timesyncd[720]: Network configuration changed, trying to establish connection.
Oct 08 15:44:01 homeassistant systemd-timesyncd[720]: Network configuration changed, trying to establish connection.
Oct 08 15:44:01 homeassistant systemd[1]: Stopping Network Time Synchronization...
Oct 08 15:44:01 homeassistant systemd[1]: systemd-timesyncd.service: Deactivated successfully.
Oct 08 15:44:01 homeassistant systemd[1]: Stopped Network Time Synchronization.
Oct 08 15:44:01 homeassistant systemd[1]: Starting Network Time Synchronization...
Oct 08 15:44:02 homeassistant systemd[1]: Started Network Time Synchronization.
Oct 08 15:44:11 homeassistant systemd[1]: Stopping Network Time Synchronization...
Oct 08 15:44:11 homeassistant systemd[1]: systemd-timesyncd.service: Deactivated successfully.
Oct 08 15:44:11 homeassistant systemd[1]: Stopped Network Time Synchronization.
Oct 08 15:44:11 homeassistant systemd[1]: Starting Network Time Synchronization...
Oct 08 15:44:11 homeassistant systemd[1]: Started Network Time Synchronization.
Oct 08 15:47:42 homeassistant systemd-timesyncd[2501]: Network configuration changed, trying to establish connection.
Oct 08 15:47:42 homeassistant systemd-timesyncd[2501]: Network configuration changed, trying to establish connection.
Oct 08 15:47:42 homeassistant systemd-timesyncd[2501]: Network configuration changed, trying to establish connection.
Oct 08 15:47:42 homeassistant systemd-timesyncd[2501]: Network configuration changed, trying to establish connection.
Oct 08 15:47:52 homeassistant systemd-timesyncd[2501]: Timed out waiting for reply from 192.168.0.2:123 (192.168.0.2).

The system received an IP address from the DHCP sever and I can access ports 8123 and 4357.

[agners]

@martinbrose hm, this log seems to indicate that the NTP time server on you Pi hole is not running correctly and/or your network is filtering some traffic maybe?

Oct 08 15:47:52 homeassistant systemd-timesyncd[2501]: Timed out waiting for reply from 192.168.0.2:123 (192.168.0.2).

[martinbrose]

@martinbrose hm, this log seems to indicate that the NTP time server on you Pi hole is not running correctly and/or your network is filtering some traffic maybe?

Oct 08 15:47:52 homeassistant systemd-timesyncd[2501]: Timed out waiting for reply from 192.168.0.2:123 (192.168.0.2).

Yes, problem resolved. The problem was that DNSSEC failed on my Pi-Hole. Somehow wasn't notably affecting me in my daily internet use, but the Pi-Hole NTP component couldn't establish a connection to the configured NTP servers. Once I deactivated DNSSEC, it all worked.

[agners]

So it makes me wonder if this fallback implementation ever worked. Maybe it was only tested on Supervised installs where NTP was disabled?

Hm, yeah that is the only explanation.

Also, it seems that disabling NTP is not possible because the file system is read-only:

# busctl call org.freedesktop.timedate1 /org/freedesktop/timedate1 org.freedesktop.timedate1 SetNTP bb false false
Call failed: File /etc/systemd/system/dbus-org.freedesktop.timesync1.service: Read-only file system

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.