Synchronize time and Check for Updates not working for TrueNAS 22.12.0

nddj

Dabbler
Joined
Jan 7, 2023
Messages
15
Hi everyone!
The network, dataset, etc. are all set up and functioning properly as a NAS.
However, after a few days of use, I noticed the following error in the System Information on the dashboard.
"Your NAS time Aug 12, 13:03:54, GMT+09:00 does not match your computer time."

When trying to resolve this issue with Synchronize time, I get
"ValidationErrors [EINVAL] system_set_time.new_time: new timestamp requires slewing clock more than maximum allowed value of 30 days. allowed value of 30 days. allowed value of 30 days".

I immediately started investigating on this forum and found people who were off by a few minutes to a day, but no one who was off by several months. (Sorry if I missed something).

The reason it is showing GMT+9 is because I am in Japan, and I considered the possibility that this is happening because I have not set it to UTC, but if that were the case it would not be off by several months...

In addition to this problem, we also discovered that Check for Update does not work.
"TrueNAS was unable to reach update servers."

Is there a solution for these somewhere?
Thanks in advance.



TrueNAS Scale22.12.0

Hardware:
Intel i7 8700K
Crucial DDR4 32GB RAM (non ECC)
Kingston SSD 120GB(for Boot)
Western Digital Red NVMe 1TB
Western Digital Red Plus 8TB×5
Thermaltake TOUGHPOWER PF1 Compact PLATINUM 750W
 

nddj

Dabbler
Joined
Jan 7, 2023
Messages
15
I have the same issue with my TrueNAS Scale 22.12.0
Have you tried anything for this issue?
I'm wondering if I can change the version to 22.02 if I can't find a solution........
 

nddj

Dabbler
Joined
Jan 7, 2023
Messages
15
I have a new finding for this issue. The date rewinds every time you restart. Apparently Aug 07, 22:27:05.
It seems to be set near The cause is completely unknown.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
Try replacing your system's CMOS battery and setting the time correctly in the BIOS.
 

qmcb23YR

Dabbler
Joined
Mar 30, 2020
Messages
12

See if that fixes it. I run this at start-up and haven't had an issue since.

ntp is in a failed state upon upgrading, and continues to be until 'echo "tinker panic 0" | tee -a /etc/ntp.conf' is run and ntp restarted. For whatever reason, 22.02.4 causes a large enough offset for ntp to enter a failed state until it's told to ignore this large offset.
 

nddj

Dabbler
Joined
Jan 7, 2023
Messages
15
Thanks to everyone for their advice. I plan to try it on Saturday. I'll report the results to this thread.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,553
Code:
"ValidationErrors [EINVAL] system_set_time.new_time: new timestamp requires slewing clock more than maximum allowed value of 30 days. allowed value of 30 days. allowed value of 30 days".


There's a bug ticket to add error handling in the webui for that op failing with a validation error (aesthetic issue). Generally though, the reasoning behind having a validation error at all here is that 30 days is a large slew showing something is fundamentally broken (like a failed CMOS battery) and requires some proper investigation / attention by the NAS admin. Honestly, though I added the upper bound thinking I'd probably never see issues where people hit it :)
 

nddj

Dabbler
Joined
Jan 7, 2023
Messages
15
I am reporting this to all of you who are watching the forum.
I first updated the CMOS battery and there was no change due to that. This one did not solve the problem, although it would have made sense to update it itself.
Then I adjusted the time to the current time from the BIOS (UEFI) and was able to fix it using "Synchronize time" from the WebUI. This also enabled the "Check for Updates" to work.
It seems that the root cause of the problem was still a discrepancy of 30 days or more, so it could not be corrected. However, we did not understand why such a large discrepancy occurred.
I will close this issue.
Thank you very much for your advice.
 
Last edited:
Top