I upgraded to 6.7.2 a few weeks ago and found that my Mythtv docker wasn't recording things at the right time.  I looked at the time in the docker and it was way off.  I then looked in settings on Unraid and found it's clock was way off too.  I reset the clock on Unraid a few times to no avail.  I also replaced my BIOS battery and it is still going off each day.  Any ideas on how to get it straightened out?

Your server should use ntp to synchronise to network time servers. Go to Settings -> Time and Date and check the settings there. You can turn on help for guidance but it should be fairly obvious what to set. Here's what mine looks like:

 

 

If the time hasn't synchronised after a few hours post your diagnostics.

Thanks for the reply!!!  I appreciate your help.  I have also tried setting the NTP servers.  Here is what it looks like.  When I check it in a few hours, it will be WAY off again.  I have also attached the Diagnostics file you requested.  Thanks again for your help.

 

weltoraid-diagnostics-20191118-1619.zip

Your settings look good and I've checked that your four selected time servers respond at least to a ping. I'm seeing a lot of this in your syslog:

Nov 15 16:49:36 WeltoRaid emhttpd: shcmd (2897): /etc/rc.d/rc.ntpd stop
Nov 15 16:49:36 WeltoRaid root: Stopping NTP daemon...
Nov 15 16:49:36 WeltoRaid emhttpd: shcmd (2898): date -s '2019-11-15 19:37:16'
Nov 15 19:37:16 WeltoRaid root: Fri Nov 15 19:37:16 MST 2019
Nov 15 19:37:16 WeltoRaid emhttpd: shcmd (2899): hwclock --utc --systohc --noadjfile
Nov 15 19:37:19 WeltoRaid emhttpd: req (6): timeZone=America%2FPhoenix&USE_NTP=no&newDateTime=2019-11-15+19%3A37%3A16&setDateTime=Apply&csrf_token=****************
Nov 15 19:37:19 WeltoRaid emhttpd: shcmd (2900): ln -sf /usr/share/zoneinfo/America/Phoenix /etc/localtime-copied-from
Nov 15 19:37:19 WeltoRaid emhttpd: shcmd (2901): cp /etc/localtime-copied-from /etc/localtime
Nov 15 19:37:19 WeltoRaid emhttpd: shcmd (2902): /usr/local/emhttp/webGui/scripts/update_access
Nov 15 19:37:19 WeltoRaid sshd[1834]: Received signal 15; terminating.

Is that you manually setting the time? It appears to be being done via an ssh connection, rather than through the GUI. Each time it happens the ntp daemon is stopped. Normally the daemon runs continuously, gently adjusting the local time to keep it in step with your chosen time servers. It can't do that if it keeps being stopped. You can check your server's time relationship with the chosen time servers (peers) by issuing the ntpq -pn command at the console:

root@Mandaue:~# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l  12d   64    0    0.000    0.000   0.000
+193.150.34.2    74.156.100.179   2 u  892 1024  377   11.125    3.108   2.431
*178.79.160.57   85.199.214.98    2 u  637 1024  377   11.877    4.189   3.639
+129.250.35.251  249.224.99.213   2 u  280 1024  377    9.139    4.037   3.405
+212.71.248.69   206.189.118.143  3 u  374 1024  377   10.701    3.439   2.243
root@Mandaue:~#

If you use watch ntpq -pn instead you can monitor the situation in real time, updated every two seconds. Press CTRL-C to exit. The -p option means show the state of the connections with the peers and the -n option means use IP addresses instead of domain names. The five rows are one for the local host and one each for the chosen peers or ntp servers. The one with the * in the first column is the peer to which we are most closely synchronised and the ones with a + are under consideration as potential replacements. The column marked 'st' indicates the stratum or layer the peer occupies in relation to other time servers. Left to its own devices our local host would sit in stratum 10 - a rather lowly position, as its internal clock is unreliable. Three of the four peers are in stratum 2 and the fourth is in stratum 3 so by being synchronised with a startum 2 peer, 178.79.160.57 our local host is elevated to stratum 3, the layer below that peer. The stratum 2 peer will, in turn, be referenced to a stratum 1 peer - probably with a GPS receiver. The column marked "when" shows how many seconds ago the peer was last polled. The column marked 'reach' is an important one. The number 377 is an octal value, representing eight bits, all set to 1: 11111111. When the peer is polled those eight bits are shifted one place to the left and the least significant one is replaced with a 1 if the poll was successful, a 0 if it was unsuccessful. So ideally, you would always see 377 in that column, except for a short time after the daemon has started up. Once it has been running for a while anything less than 377 indicates one or more polls that failed to get a response. How often is a peer polled? Well, that depends on the column marked 'poll'. The peer won't be polled again until the value in the 'when' column exceeds the value in the 'poll' column.

 

So what I would do is stop manually setting the time for a while, open a console or ssh session and run watch ntp -qn and check for something connecting and remotely setting the time and stopping the ntp daemon.

 

 

Thank you so much for your help.  To answer your question directly, I am not manually resetting the time via SSH.  I have reset it manually a bunch of times via settings in unraid because it was just wrong.  Actually I just logged in and my clock on my computer shows this...

 

Unraid shows this...

 

I had not touched it since I sent you the screen shot the other day.  I just reset the time in unraid.  When you switch "Use NTP: Yes" to "Use NTP: No," it does the manual reset you see in the logs.  After resetting the clock at about 6:52 AM and working on the system for a few minutes I noticed that it is already 5 minutes behind.  I am attaching another diag file too.

 

This seems to be interesting...

Nov 20 01:00:51 WeltoRaid sshd[24763]: Received signal 15; terminating.
Nov 20 01:00:52 WeltoRaid sshd[25822]: Server listening on 0.0.0.0 port 22.
Nov 20 01:00:52 WeltoRaid sshd[25822]: Server listening on :: port 22.
Nov 20 01:00:53 WeltoRaid emhttpd: shcmd (14138): /etc/rc.d/rc.ntpd stop
Nov 20 01:00:53 WeltoRaid ntpd[24808]: ntpd exiting on signal 1 (Hangup)
Nov 20 01:00:53 WeltoRaid ntpd[24808]: 127.127.1.0 local addr 127.0.0.1 -> <null>
Nov 20 01:00:53 WeltoRaid ntpd[24808]: 3.82.177.91 local addr 192.168.0.151 -> <null>
Nov 20 01:00:53 WeltoRaid ntpd[24808]: 216.229.4.66 local addr 192.168.0.151 -> <null>
Nov 20 01:00:53 WeltoRaid ntpd[24808]: 184.105.182.16 local addr 192.168.0.151 -> <null>
Nov 20 01:00:53 WeltoRaid ntpd[24808]: 162.159.200.123 local addr 192.168.0.151 -> <null>
Nov 20 01:00:53 WeltoRaid root: Stopping NTP daemon...
Nov 20 01:00:53 WeltoRaid emhttpd: shcmd (14139): date -s '2019-11-20 06:51:34'
Nov 20 06:51:34 WeltoRaid root: Wed Nov 20 06:51:34 MST 2019
Nov 20 06:51:34 WeltoRaid emhttpd: shcmd (14140): hwclock --utc --systohc --noadjfile
Nov 20 06:51:41 WeltoRaid crond[1683]: time disparity of 351 minutes detected

 

That time disparity is really strange... Does that just mean that the time in unraid is 351 minutes off from the HWclock?

weltoraid-diagnostics-20191120-1413.zip

Start your server in safemode and check if this makes any change

So, at this point I rebooted the server and found that the clock in the bios was off by about 7 hours.  I set that clock are rebooted into normal mode.  I will update this tomorrow with my results.  Bonienl, what difference would safe mode make?  I don't understand why that would make a difference.  I am more than willing to try but what do you suggest?  Reboot in Safemode and set the clock then reboot in normal mode?  I appreciate your input, just looking for some clarification. 

Safe Mode disables Plugins/Dockers and in the simplistic terms runs the bare minimum. Sometimes things we add change our settings. 

Good catch on the Battery in the Bios. I had a 24hour glitch once because I selected the wrong day. Lol