Your NAS time <date time> does not match your computer time

[MAndreato]

TrueNAS-SCALE-22.12-MASTER-20220625-072905 is running on a Windows 11 Virtualbox host virtual machine in my PC and its localization timezone is set to Italy (GMT+2).
NTP servers are default:

Indirizzi	Burst	IBurst	Prefer	Min Poll	Max Poll
0.debian.pool.ntp.org	false	true	false	6	10
1.debian.pool.ntp.org	false	true	false	6	10
2.debian.pool.ntp.org	false	true	false	6	10

After resuming the PC from standby, the system information panel on dashboard shows "Your NAS time Jun 25, 15:53:51 GMT +02:00 does not match your computer time"; indeed, "Jun 25, 15:53:51 GMT +02:00" is about 20 minutes before the correct time now, in Italy (as shown in Windows).

Maybe this is due to virtualization? But I had not similar problems with others Linux VirtualBox guests.

I looked in the Scale UI Reference Guide but did not found a way to refresh True NAS time, neither manual, neither automatic.

 

[smic717394]

try to set the time manual. first check if the timezone is correct, if so go to shell and use the

Code:

date +%T -s "hh:mm:ss"

command replacing the hh:mm:ss with the correct hours minutes and hours at the time when you run the command.

 

[MAndreato]

try to set the time manual. first check if the timezone is correct, if so go to shell and use the

Code:

date +%T -s "hh:mm:ss"

command replacing the hh:mm:ss with the correct hours minutes and hours at the time when you run the command.

Thanks @smic717394, I did a test.

At Jul 6, 13:31:00 GMT+2 there was no issue on TrueNAS dashboard, then I closed the laptop cover and Windows went standby and same did the virtual machine.

After 50 minutes, at Jul 6, 14:22:00 GMT+2 I reactivated Windows and logged into TrueNAS and found the following warning on the dashboard: "Your NAS time Jul 06, 13:35:30 GMT +02:00 does not match your computer time".

I opened a shell from the system settings menu and typed the following: date +%T -s "14:22:00" --> after logging out and loggin in, the warning was cleared.

After few minutes I repeated the test by letting Windows to standby and resume after 20 minutes --> again, received the warning: "Your NAS time Jul 06, 14:27:54 GMT +02:00 does not match your computer time".
So the "date" command should be issued every time the system resumes from standby.

Is there a way to get TrueNAS automatically tune the clock via NTP when the warning triggers?

 

[elvisimprsntr]

My recollection is Windows prefers to store the CMOS HW clock in local time. TrueNAS and most *nix systems prefer the CMOS HW clock in UTC time

Since you are running TrueNAS as a VM (which is not recommended) on top of a Windows host (which is even worse), when your TrueNAS VM boots or wakes from sleep it gets local time, but since the NTP time is too far skewed from the CMOS HW local clock time, it will not automatically update. There are Windows REGEDIT tweaks to force Windows to store the CMOS HW clock in UTC time.

How to make Windows store time in UTC

If you are dual-booting Windows 10 or 11 and Linux or another operating system that uses UTC to store the system time, you notice that the time is wrong when switching the operating systems. The preferred method to solve the issue is to set Windows to store the time in UTC instead of forcing the...

uilton.com

You are best to run TrueNAS on bare metal rather than as a VM on a Windows host.

 

[MAndreato]

Thanks @elvisimprsntr for the explanation.
I'm running TrueNAS Scale on VirtualBox just for testing before a real installation around this winter (I'm evaluating the hardware, maybe a TrueNAS Mini E... It depends on available $$$ ) --> so I think I can ignore the warning until then.

 

[anodos]

Thanks @elvisimprsntr for the explanation.
I'm running TrueNAS Scale on VirtualBox just for testing before a real installation around this winter (I'm evaluating the hardware, maybe a TrueNAS Mini E... It depends on available $$$ ) --> so I think I can ignore the warning until then.

You can disable alerts.

 

[copz1998]

Interesting, I am experiencing a similar issue that coincides with this thread. I recently updated my CPU and replaced my BIOS battery (older PC). When I rebooted, I entered the day's correct date and time for my timezone (PST). Now, my TrueNAS clock appears correct (see screenshots), but my PC/BIOS clock shows over one day off. Now I am getting sync errors (screenshots) and Plex live TV shows are only running 4-5 minutes before showing a playback error.

The date/time of this post is 10/8/2022 at 0802 hrs, but you will see the "date" command shows the 7th.

I have tried to update the date/clock using the command above, but it does not change the date. Any help is greatly appreciated!

 

[Brennen]

TrueNAS and most *nix systems prefer the CMOS HW clock in UTC time

I am having a similar issue with the date and time error except I'm running truenas scale as my primary os on a dell poweredge t330 system. what exactly is the fix here because not one has really said what need to be done to remove the errors. I did try just setting the time on the bios to be out in the other direction to what truenas says and the error message is gone now but it is a far from ideal solution because when trying to install plex and get a certain error message that seems to be related to the time error from what I have found. Any proper solutions to the date/time errors?

 

[rr5050]

I've tried this in both of these:
TrueNAS-SCALE-22.02.4
TrueNAS-SCALE-22.12-BETA.1

22.02.4: datetime sync on install but never after.

22.12-BETA.1: NO datetime sync on install and never after either.
Weirdly "system settings > general > localization" actually syncs both date & time after install, but if I go to shell for timedatectl it still shows wrong - as well as dashboard also indicates that date & time is wrong.

Beta has a section of NTP listings in the GUI (system settings > general > NTP servers), but there's still no sync.

This has been installed on hardware, so truenas has not been virtualized.

There are no settings or anything I can see that is blocking NTP sync in the router, and as we can see below here that it does sync during the install, but never after.



-----------------------------

Before install in BIOS:
- Set date and time to something completely wrong
-----------------------------

After fresh install (22.02.4) (system settings > shell):
root@truenas[~]# timedatectl
Local time: Sun 2022-10-09 07:29:15 PDT
Universal time: Sun 2022-10-09 14:29:15 UTC
RTC time: Sun 2022-10-09 14:29:15
Time zone: America/Los_Angeles (PDT, -0700)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no
-----------------------------

Result:
- BIOS has been updated with correct date and UTC time
- i.e. the install did sync with internet to get correct date and time
- from output above we can see that system clock sync and NTP service is not turned on.
-----------------------------

Reboot into BIOS:
- Set date and time to something completely wrong
-----------------------------

Reboot to start TrueNAS again:
Dashboard shows:
Your NAS time Nov 09, 11:18:47, GMT+01:00 does not match your computer time

-----------------------------

Checking in shell again:
root@truenas[~]# timedatectl
Local time: Wed 2022-11-09 02:21:08 PST
Universal time: Wed 2022-11-09 10:21:08 UTC
RTC time: Wed 2022-11-09 10:21:08
Time zone: America/Los_Angeles (PST, -0800)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no
-----------------------------

Result:
- A restart did NOT sync correct date and time from internet
- Leave it on, and re-checking again later shows no change (i.e. it does not sync correct date and time at a later stage either)

-----------------------------
Content of the NTP config file looks like it have correct information (this is from a fresh install of TrueNAS, so has not been modified):

root@truenas[~]# nano /etc/ntp.conf

server 0.debian.pool.ntp.org iburst maxpoll 10 minpoll 6
server 1.debian.pool.ntp.org iburst maxpoll 10 minpoll 6
server 2.debian.pool.ntp.org iburst maxpoll 10 minpoll 6
restrict default ignore
restrict -6 default ignore
restrict 127.0.0.1
restrict -6 ::1
restrict 127.127.1.0
restrict 0.debian.pool.ntp.org nomodify notrap nopeer noquery
restrict 1.debian.pool.ntp.org nomodify notrap nopeer noquery
restrict 2.debian.pool.ntp.org nomodify notrap nopeer noquery
-----------------------------

 

[kriegalex]

I also have issues with a bare metal install on a QNAP. I saw the error on my first install, and the time was off by X hours, so I went into the BIOS and changed the time to be stored as GMT(UTC) instead of GMT+X. Then in TrueNAS, the time seemed correct but the message was still there. Now the day after, the time is off by ~30 seconds and the message is still there.

I just tried now to sync the time using the date command but it didn't change anything.

date +%T -s "hh:mm:ss"

It is annoying because it seems that the charts don't work properly

 

[elvisimprsntr]

Excessive clock drift can be caused by low CMOS battery. New CR2032's are ~3.3v. Using a voltmeter, place positive lead on the installed battery and the negative lead on the chassis. Replace if less than ~3.0v

 

[copz1998]

Excessive clock drift can be caused by low CMOS battery. New CR2032's are ~3.3v. Using a voltmeter, place positive lead on the installed battery and the negative lead on the chassis. Replace if less than ~3.0v

Thanks, but I installed a new CMOS battery recently with the upgraded CPU.

 

[JohanKarlsson]

I think we all found a bug in TN Scale 22.02.4

I installed TN Scale on a new Intel NUC (so no battery clock issues).

In the TN Scale GUI under System Settings/General, I see under Localization
the date format 13 Oct 2022 and
the time 20:54:16 and
time zone Europe/Brussels

Under :TN Scale/System Settings/General/NTP servers three ntp servers are listed
Address Burst IBurst Prefer Min Poll Max Poll
0.debian.pool.ntp.org false true false 6 10
1.debian.pool.ntp.org false true false 6 10
2.debian.pool.ntp.org false true false 6 10

In my Dashboard, I see the message that "Your NAS time Oct 14, 05:15:54, GMT+02:00 does not match your computer time."

When I ssh into the TN Scale server, I get this:

# timedatectl
Local time: Fri 2022-10-14 05:15:14 CEST
Universal time: Fri 2022-10-14 03:15:14 UTC
RTC time: Fri 2022-10-14 03:15:14
Time zone: Europe/Brussels (CEST, +0200)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no

Did you notice the NTP Service? It says n/a!

Also interesting is the output below:
# systemctl status ntp
● ntp.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2022-10-14 04:57:44 CEST; 21min ago
Docs: man:ntpd(8)
Main PID: 577630 (code=exited, status=255/EXCEPTION)

Oct 14 04:57:34 nuc ntpd[577630]: Listen normally on 10 kube-dummy-if [fe80::8459:56ff:fe7d:442%9]:123
Oct 14 04:57:34 nuc ntpd[577630]: Listen normally on 11 vethf6b703cd [fe80::cced:80ff:fe0f:1274%10]:123
Oct 14 04:57:34 nuc ntpd[577630]: Listen normally on 12 vethf93faeb1 [fe80::f489:f6ff:fe8e:a50e%11]:123
Oct 14 04:57:34 nuc ntpd[577630]: Listen normally on 13 veth8b358729 [fe80::6817:adff:fea9:e3af%12]:123
Oct 14 04:57:34 nuc ntpd[577630]: Listening on routing socket on fd #30 for interface updates
Oct 14 04:57:34 nuc ntpd[577630]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Oct 14 04:57:34 nuc ntpd[577630]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Oct 14 04:57:34 nuc systemd[1]: Started Network Time Service.
Oct 14 04:57:44 nuc systemd[1]: ntp.service: Main process exited, code=exited, status=255/EXCEPTION
Oct 14 04:57:44 nuc systemd[1]: ntp.service: Failed with result 'exit-code'.


The correct time on my computer is Fri Oct 13 21:22:41
Entering the cli command date gives Fri Oct 14 05:22:41 CEST 2022

The clock in BIOS (UEFI) is equal to the correct time on my computer.

Sine this is a vanilla install of TN Scale, I assume this is a bug in TN Scale 22.02.4?

Johan

 

[copz1998]

Thank you, Johan

You provided a more eloquent explanation than I did. Well said and my issue mirrors yours. Hopefully a "fix" is forthcoming.

 

[anodos]

Did you notice the NTP Service? It says n/a!

This just means that systemd-networkd isn't being used. This is non-issue. C.F. manpage for `timedatectl`.

It's better to understand why ntpd isn't running, but I have a feeling that it's due to excessive clock slew. If hardware clock is wildly off, ntpd won't try to fix it. Looks like it's roughly 5-6 hours into the future.

Depending on particulars of hardware involved, you may have to use newer kernel (e.g. BlueFin BETA) to have consistent time keeping for hardware clock.

 

[Ahchoo]

I ran into the same issue as you all today after installing 22.02.04. I found that the NTP service was in a failed state as well.

I ran,

date -s 2022-10-14 15:34:00

To get my clock close to real time. Now, with the time close to the real time, I restarted NTP with...

systemctl restart ntp

Everything is working working perfectly now.

 

[anodos]

I ran into the same issue as you all today after installing 22.02.04. I found that the NTP service was in a failed state as well.

I ran,

date -s 2022-10-14 15:34:00

To get my clock close to real time. Now, with the time close to the real time, I restarted NTP with...

systemctl restart ntp

Everything is working working perfectly now.

I added API for backend to set clock and opened ticket for webui to offer allowing to set server time based on time on current client if slew is greater than 300 seconds.

 

[undrpaidtekmnky]

Manually setting the date and time WILL work, however, the issues starts at a BIOS level. TrueNAS Scale is looking for UTC time in your BIOS. If you have it set to local time, you will run into the problems everyone has been describing. Simply setting your system BIOS clock to UTC time will fix the issue completely. As far as I know, this is due to Linux expecting UTC time from your BIOS, as opposed to any bug in TrueNAS Scale itself.

 

[Patrick M. Hausen]

Correct. Every Unix system runs its clock in UTC.

 

[TheBearJew]

Hi Everybody,

I've run into the same problem. I just wanted to give back to the community and post my findings.

1. I've been having the same issues as above.
   1. To single out the issues, I have replaced my motherboard battery
   2. Make sure system time is correct in the Bios. (It wasn't, but I did change it).
2. Upon boot, I still have the same "NAS time does not match computer time" error on the home page.
3. I tried to manually sync this using the terminal but it still is throwing me an error.
4. Because I've had Truenas for a while, I was able to set the system to boot from the 22.02.3 boot image.
5. Lo and behold, the error is gone.

After searching the Release Documentation here it seems that there is a known issue in 22.02.4

• NAS-115869 NTP service broken when DHCP provides NTP servers.

Until the next update, my solution is to run the 22.02.3 image.

Have a wonderful day, hope this helps somebody.