SOLVED Failed to query time from myserver.mydomain.net

[lokimon]

I think I have successfully joined my freenas to my samba4 ad.

I can create shares, and assign users from the domain to those shares.

But I have an alert that I can't seem to get rid of.

[2019/01/11 17:32:06] (DEBUG) ServiceMonitorService.validate_time():83 - [ServiceMonitorThread] Failed to query time from myserver.mydomain.net.: (No response received from myserver.mydomain.net)
[2019/01/11 17:32:06] (DEBUG) ServiceMonitorService.run():194 - [ServiceMonitorThread] AD domain is not in connectable state. Delaying further checks.

This alert fires every minute.

I'm not sure what freenas/ad integration uses to query time but, net time seems to work.

root@freenas[/var/log]# net time -S myserver.mydomain.net
Fri Jan 11 11:51:03 2019

Any ideas?
Thanks in advance for any and all help.

 

[lokimon]

The answer was to run ntp on the samba server as well.

 

[NasCon]

The answer was to run ntp on the samba server as well.

Do you mean to run the NTP service on the FreeNas system? I can't find that service in the system services.

 

[anodos]

No. NTP service doesn't run on the FreeNAS server. This is more of an issue with how AD monitoring works in 11.2. It finds a DC and tries to check time (to make sure that clockskew is within acceptable margins). This is reworked in 11.3 so that we use DNS to find the DC with the PDC emulator FSMO role and validate time against it. It might be possible to configure a Samba AD domain such that the server with this role isn't also an NTP server, but I believe this is fundamentally a misconfiguration.

 

[NasCon]

Thanks for the info. However I still do not know how to prevent this error. Should I install NTP on my freenas using the CLI or something? I thought the upgrade to 11.3 countered this problem, but after a week or two the problem is coming back...

 

[anodos]

Thanks for the info. However I still do not know how to prevent this error. Should I install NTP on my freenas using the CLI or something? I thought the upgrade to 11.3 countered this problem, but after a week or two the problem is coming back...

I don't understand what your problem is? 11.3 is currently alpha so there are probably different problems every day with it.

 

[NasCon]

Slip of the keys... I meant 11.2 U3 of course ;-)
My problem is that Freenas fails to query time from the (Windows) DC.
That's what this thread is about, not?

EDIT:
I see U4 is out. I'll upfate and see how it goed, but there is nothing on this issue in the releasenotes.

 

[anodos]

Slip of the keys... I meant 11.2 U3 of course ;-)
My problem is that Freenas fails to query time from the (Windows) DC.
That's what this thread is about, not?

EDIT:
I see U4 is out. I'll upfate and see how it goed, but there is nothing on this issue in the releasenotes.

If the clockskew is too great then it may be better to just set the time manually on the freenas server.
May 9 2019 5 PM would be date 201905091700

 

[NasCon]

If the clockskew is too great then it may be better to just set the time manually on the freenas server.
May 9 2019 5 PM would be date 201905091700

I understand that thanks for the tip.
But I think that is no solution, but more of a workaround.
The real question is, why is my FreeNAS not timesyncing with the DC? Since my PC's are, I think the problems lays withing FreeNAS somewhere.
However I have seen no timesync errors in U4 as of new yet

 

[anodos]

I understand that thanks for the tip.
But I think that is no solution, but more of a workaround.
The real question is, why is my FreeNAS not timesyncing with the DC? Since my PC's are, I think the problems lays withing FreeNAS somewhere.
However I have seen no timesync errors in U4 as of new yet

Depending on how large the clock skew between the servers are, it may take quite some time to synchronize (if ntpd allows it at all). This is a security mechanism. If they're really far off, it's almost always better (especially during initial deployment) to just force them to be approximately the same and let ntp do the rest.