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

[undrpaidtekmnky]

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.

While this may work, it's only masking the issue. As stated previously, when TrueNAS is reading the time from your BIOS, if you are attempting to set it to your timezone(in BIOS) you will always run into this problem. The time in BIOS HAS to be set to UTC. Linux doesn't understand time zones, so unlike a Windows system, it doesn't see the correct time and date. To actually solve the issue, the time in BIOS must be set to UTC. Once you go in and set it correctly, the error will disappear permanently(or at the very least until the information in BIOS is overwritten, or reset).

 

[TheBearJew]

While this may work, it's only masking the issue. As stated previously, when TrueNAS is reading the time from your BIOS, if you are attempting to set it to your timezone(in BIOS) you will always run into this problem. The time in BIOS HAS to be set to UTC. Linux doesn't understand time zones, so unlike a Windows system, it doesn't see the correct time and date. To actually solve the issue, the time in BIOS must be set to UTC. Once you go in and set it correctly, the error will disappear permanently(or at the very least until the information in BIOS is overwritten, or reset).

Oh my gosh. Makes sense now!!!!

So I had some wonderful Saturday morning time to fiddle with it more. But it seems like your correct.

1. I went into the BIOS to change to UTC time (I'd like to note for anybody here, my BIOS is 2014, and doesn't have the option to set AS UTC, so what I did was just put in what the UTC time is). Example: right now in Los Angeles its 11-5-2022 11:00am. But UTC time is 11-5-2022 6:00pm. So I set the BIOS to 11-5-2022 6:00pm.
2. Upon boot, TrueNas did not throw any errors
3. Plex did have an issue starting up, so in the Plex docker container. I clicked Edit -> Plex Configuration -> Plex Timezone. And I had to change that from Los Angeles to UTC Timezone.
4. Everything is working beautifully.

Thanks everybody. Have a great Saturday

Nathaniel

 

[jgreco]

The time in BIOS HAS to be set to UTC. Linux doesn't understand time zones, so unlike a Windows system, it doesn't see the correct time and date.

This is a mis-statement of the issue. As I've explained before, the PC BIOS does not support timezones. What you are thinking of as a "timezone" in Linux is a userland display affectation; UNIX/FreeBSD/Linux derive timezones from the TZ environmental variable or an /etc/ file, which is how two different login sessions can have completely different timezones. The underlying UNIX time is based off time_t, the number of seconds since the epoch (1/1/1970), and every UNIX system on the planet is supposed to have the same value for time_t. Timezones are merely used to print out a local representation of the time. The problem is that the BIOS has no idea what the local timezone is, so the time set in the system RTC is kinda useless.

 

[serverstonemonkey]

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.

I had the same issue. This command fixed it for me. Setting the bios clock did not do anything for me, but the above command solved the issue for me.

 

[kchap]

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.

There is a clash between how windows and linux view the RTC so I'm not sure how to resolve this when running TrueNAS in a windows environment.

However, I was getting this message Your NAS time <date time> does not match your computer time running on directly on a Xeon motherboard. The solution is set the MB RTC to UTC. This can be done via the BIOS bit I used the hwclock command. I used local time +- UTC offset so the command was:

hwclock --set --date "yyyy-mm-dd hh:mm:ss<+|->hh:mm"

 

[qmcb23YR]

Adding another vote to 'this seems to be an issue caused by 22.02.4'.

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.

 

[Ryckk]

Wow! That was a rabbit hole! Tried everything unsuccessfully until I got to qmcb23YR and the 'echo "tinker panic 0" | tee -a /etc/ntp.conf' solution. Thankyou so much! I have 2 nas's running 22.12.2 and it was just the older model (X9SCM-F) that had a problem.

 

[Rubisrik]

Adding another vote to 'this seems to be an issue caused by 22.02.4'.

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.

Thank you for the tip, but how do you make that work (newby here). Copy/Paste in shell?

 

[richardm1]

I've just run into this time zone issue with a virtualized SCALE install.

It's not impossible that something is wrong with my setup. However, this is the ONLY VM in my homelab with timekeeping issues. The time in SCALE is correct but the UTC offset is wrong. My hacky workaround lies in the VM's vmx file:

Code:

rtc.diffFromUTC = -14400

14,400 seconds offsets EDT from UTC.

 

[jgreco]

So.... your hypervisor is using EDT time? If so, that's wrong. Use UTC on every UNIX system, and set the PC BIOS to UTC as well.

 

[richardm1]

So.... your hypervisor is using EDT time? If so, that's wrong. Use UTC on every UNIX system, and set the PC BIOS to UTC as well.

No, ESXi uses UTC and it's not configurable.

 

[Patrick M. Hausen]

No, ESXi uses UTC and it's not configurable.

Then just remove the hack from your VMX file, let the VM clock run in UTC, too, and set the correct local timezone in the TrueNAS UI.

 

[jgreco]

No, ESXi uses UTC and it's not configurable.

ESXi uses UTC if the BIOS is set to UTC and NTP is configured. Otherwise it doesn't. I guess there's a minor quibble there over whether it is "configurable".