I'm facing a persistent issue getting NTP to work on my TrueNAS SCALE server (latest kernel version is 5.15.131+truenas). The system time is currently being kept "correct" because I've set the RTC (BIOS) to UTC and TrueNAS is configured with the America/Sao_Paulo timezone, but the NTP service itself is not synchronizing.
The Problem:
The sudo ntpq -p command in the TrueNAS shell consistently shows all configured NTP servers with:
refid: .INIT.
st: 16
reach: 0
delay, offset, jitter: 0.000
This occurs even after restarting the NTP service (sudo systemctl restart ntp) and waiting a considerable amount of time.
What I've Already Checked/Done:
Date and Timezone: The system date is correct (e.g., Wed May 28 16:06:25 -03 2025) after setting the BIOS RTC to UTC. The timezone in TrueNAS is correctly set to America/Sao_Paulo.
TrueNAS Network Connectivity:
Can ping external IPs (e.g., 8.8.8.8).
Can resolve DNS names and ping NTP servers (e.g., ping a.st1.ntp.br works and resolves the IP correctly).
IP, netmask, default gateway (192.168.3.1), and primary DNS server (192.168.3.1) settings in TrueNAS appear correct.
NTP Servers Tested:
Tried using standard Brazilian servers (a.st1.ntp.br, direct IPs like 200.160.7.186, 200.20.186.76, 201.49.148.135).
* Tried using pool servers (pool.ntp.br, 0.pool.ntp.br, etc.).
Tried international servers (Google, Facebook, Apple, Microsoft) by both hostname and direct IP.
The result in ntpq -p is always the same: reach 0.
ntp.conf Configuration: I've verified /etc/ntp.conf, and it is being correctly populated with the servers I configure in the GUI. Problematic restrict directives for the servers have been removed.
Comparative Test with Windows PC on the Same Network:
A Windows 10 PC on the same subnet as the TrueNAS CAN get responses from the same NTP servers (e.g., a.st1.ntp.br) using the command w32tm /stripchart /computer:a.st1.ntp.br /samples:5 /dataonly. This suggests that UDP port 123 is not blocked for the entire network by the ISP.
Local Router Firewall:
I have access to a Huawei AX2 router on the network. Its main firewall has been disabled, and the IPv4/IPv6 filter lists are empty (no active blocking rules). Other sections like "NAT Services" and "Remote Control" don't seem relevant to outbound NTP blocking.
TrueNAS Firewall:
In the TrueNAS GUI (Network -> Global Configuration), "Outbound Network" is set to "Allow All". I haven't found an obvious "Firewall" section with active outbound rules in TrueNAS that could be blocking.
NTP Logs (journalctl -u ntp):
Logs show ntpd starting and the kernel reporting kernel reports TIME_ERROR: 0x4041: Clock Unsynchronized, but there are no explicit network error messages (timeout, connection refused, etc.) when trying to contact the servers. It simply fails to establish synchronization.
Questions for the Forum:
Has anyone experienced a similar situation where NTP fails on TrueNAS but works on other devices on the same network?
Are there other deeper configurations or logs within TrueNAS Scale I should check to diagnose why ntpd isn't reaching the servers (even though ping works)?
Any suggestions on how to convince an IT team or ISP that the block might be on their end, even with ping working?
Thanks for any help or insights you might have! I'm running out of options.
Thanks for the suggestion about chrony! I double-checked my TrueNAS SCALE system (kernel 5.15.131+truenas) to see which time synchronization service is active. It appears to be using the traditional ntpd (from the ntp.service) and not chrony. Here's the output from my shell when I tried to check for chrony and then listed the active ntp service and process:
Linux truenas 5.15.131+truenas #1 SMP Fri Oct 13 19:46:10 UTC 2023 x86_64
TrueNAS (c) 2009-2023, iXsystems, Inc.
All rights reserved.
TrueNAS code is released under the modified BSD license with some
files copyrighted by (c) iXsystems, Inc.
For more information, documentation, help or support, go here:
http://truenas.com
Welcome to TrueNAS
Last login: Wed May 28 16:06:23 -03 2025 on pts/2
Warning: the supported mechanisms for making configuration changes
are the TrueNAS WebUI, CLI, and API exclusively. ALL OTHERS ARE
NOT SUPPORTED AND WILL RESULT IN UNDEFINED BEHAVIOR AND MAY
RESULT IN SYSTEM FAILURE.
admin@truenas[~]$ chronyc sources
zsh: command not found: chronyc
admin@truenas[~]$ sudo systemctl restart chrony
[sudo] password for admin:
Failed to restart chrony.service: Unit chrony.service not found.
admin@truenas[~]$ sudo journalctl -u chrony
-- No entries --
admin@truenas[~]$ sudo systemctl list-units --type=service | grep -E 'ntp|time|chrony'
ntp.service loaded active running Network Time Service
user-runtime-dir@950.service loaded active exited User Runtime Directory /run/user/950
admin@truenas[~]$ ps aux | grep -E 'ntpd|chronyd'
ntp 782461 0.0 0.0 74988 3976 ? Ssl 16:05 0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -c /etc/ntp.conf -u 114:119
admin 819839 0.0 0.0 5268 708 pts/3 S+ 17:06 0:00 grep -E ntpd|chronyd
admin@truenas[~]$ chronyd
zsh: command not found: chronyd
admin@truenas[~]$
My mistake too, I hadn't realized my current version was that out of date! Thanks for pointing out it's an EOL version.
My immediate plan is to update the server to a supported TrueNAS SCALE version (likely Dragonfish 24.04.x or newer).
Once that's done, I'll first identify which time synchronization service the new version is using (whether it's still ntpd or if it has switched to chronyd). Then, I'll re-run the appropriate diagnostics (e.g., ntpq -p for ntpd, or chronyc sources for chronyd) if the time synchronization issue persists, and I'll report back with the new findings. Thanks!
I wanted to come here and thank everyone who tried to help me with the date and time synchronization (NTP) problem I was facing.
After many attempts and your help (and a bit of a nudge I received here!), I realized that the root cause of much of the instability was that I was running a very outdated version of TrueNAS. I apologize for not noticing this sooner and perhaps making you waste time on a problem that was ultimately my responsibility.
The good news is that I performed the update to the latest version, and now on TrueNAS Cobia, the process has resolved the issues I was facing! The system is stable, NTP is synchronizing perfectly (and with the correct date, lol).
My sincere thanks for your patience and willingness to help the community. And it also serves as a lesson on the importance of always keeping our systems up to date!
Hola tengo un problema similar quiero conectar el truenas al active directory pero me sale el mismo error de ntp ya corregi la hora en el programa en el server intente ponerlo manual pero la linea de comandos me dice que la linea es incorrecta e visto video tras video pero en ningun lado te dan soluciones al error porque a ellos no les aparece el error
Entiendo que estás teniendo problemas con NTP al intentar conectar tu TrueNAS a Active Directory, y sé lo frustrante que puede ser cuando los tutoriales no muestran el error exacto que uno encuentra. Los problemas de sincronización de tiempo son críticos para Active Directory.
Nos gustaría ayudarte a identificar la causa de tu problema. Para poder hacerlo, ¿podrías compartir con nosotros la salida de tu shell (terminal)?
Específicamente, necesitamos ver:
Los comandos exactos que estás usando para configurar o verificar NTP y la hora (por ejemplo, timedatectl, chronyc sources -v, ntpq -p, o los comandos que usaste para intentar poner la hora manual).
Los mensajes de error exactos que recibes cuando intentas ejecutar esos comandos o al intentar unirte al Active Directory.
Con esta información, podremos tener una idea más clara de lo que está sucediendo en tu sistema y ofrecerte sugerencias más precisas.
Adicionalmente (Adendo):
Sería útil saber qué versión de TrueNAS (Core o SCALE) estás utilizando. Te comento esto porque, en mi caso particular, muchos problemas que tuve relacionados con NTP se resolvieron simplemente actualizando mi servidor TrueNAS a la última versión estable disponible. A veces, las versiones más antiguas pueden tener bugs o configuraciones NTP diferentes (por ejemplo, usar ntpd en lugar de chrony o viceversa en SCALE) que se corrigen en las actualizaciones. ¡Vale la pena verificar si estás al día!
Esperamos tu respuesta con los detalles para poder ayudarte mejor.
