ntpdate fails to adjust the time

English General
1

I am on QuTS hero h6.0.1.3564.
Even though I get valid ntp packets back from the server (I tried timer.jku.at, pool.ntp·org, time.google·com and more) the packets are not interpreted by ntpdate. [Replacing the last . to avoid the fqdn to be set as a link]

A tcpdump shows:
16:19:52.599055 IP (tos 0x90, ttl 58, id 59855, offset 0, flags [DF], proto UDP (17), length 76)
162.159.200.123.123 > 140.78.96.43.44965: NTPv4, length 48
Server, Leap indicator: (0), Stratum 3 (secondary reference), poll 3 (8s), precision -26
Root Delay: 0.019332, Root dispersion: 0.000167, Reference-ID: 10.224.8.4
Reference Timestamp: 3994841982.467231570 (2026/08/04 16:19:42)
Originator Timestamp: 3994841992.595168680 (2026/08/04 16:19:52)
Receive Timestamp: 3994841998.402424755 (2026/08/04 16:19:58)
Transmit Timestamp: 3994841998.402487656 (2026/08/04 16:19:58)
Originator - Receive Timestamp: +5.807256074
Originator - Transmit Timestamp: +5.807318975

But $ ntpdate -b -d pool.ntp·org says:
4 Aug 16:19:45 ntpdate[5622]: ntpdate 4.2.8p10.1@1.3728-o Wed Jul 22 18:16:06 UTC 2026 (1)
Looking for host pool.ntp·org and service ntp
78.41.116.149 reversed to time1.funkfeuer.at
host found : time1.funkfeuer.at
4 Aug 16:19:45 ntpdate[5622]: Port 0: 1001
4 Aug 16:19:45 ntpdate[5622]: Port 1: 123
transmit(78.41.116.149)
transmit(94.199.174.89)
transmit(152.53.15.127)
transmit(162.159.200.123)
[…]
server 162.159.200.123, port 123
stratum 0, precision 0, leap 00, trust 000
refid [162.159.200.123], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
originate timestamp: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
transmit timestamp: ee1c7388.985cf984 Tue, Aug 4 2026 16:19:52.595
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

4 Aug 16:19:54 ntpdate[5622]: no server suitable for synchronization found

Since tcpdump sees and interprets replies it can not be a dns or firewall issue.

Any ideas how to address this issue?

2

Could you first check whether your NAS’s system time differs significantly from the actual current time? A large gap can cause NTP synchronization issues. Try setting the NAS’s time closer to the actual time and see if that helps.

If the problem persists, could you also check whether a computer on the same network experiences the same issue? That would help us narrow things down. Thank you!

3

I have synced the time with my desktop before trying to use ntp. My desktop uses the same ntp source (timer.jku.at), so times at the moment differ by less than a second. Also the option -b should tell ntpdate to step the time no matter how big the difference.
I have a few linux VMs in the same subnet and none of them have problems fetching ntp time from timer.jku.at. Most run chrony but I installed an tested ntpdate 4.2.8_p18 (should be close enough I guess) on two of them and that also works.

4

Could you let us know whether you’ve tried operating through the GUI, or whether you’ve been entering the commands directly? Also, could you provide us with the full console log of the $ ntpdate -b -d pool.ntp.org command — specifically the [...] portion that was omitted in your post? Thanks!

5

I became aware of the problem when I was notified that the automatic daily run failed. ([General Settings] Failed to synchronize time with the NTP server “timer.jku.at”.) Then I went to General Settings → Time and clicked the Test Connection button, which failed as well.
Then I began to investigate on the command line.
Here is a complete output of $ ntpdate -b -d pool.ntp.org
7 Aug 11:41:31 ntpdate[1758]: ntpdate 4.2.8p10.1@1.3728-o Wed Jul 22 18:16:06 UTC 2026 (1)
Looking for host pool.ntp.org and service ntp
78.41.116.149 reversed to time1.funkfeuer.at
host found : time1.funkfeuer.at
7 Aug 11:41:31 ntpdate[1758]: Port 0: 1001
7 Aug 11:41:31 ntpdate[1758]: Port 1: 123
transmit(78.41.116.149)
transmit(86.59.113.124)
transmit(152.53.132.244)
transmit(162.159.200.123)
transmit(78.41.116.149)
transmit(86.59.113.124)
transmit(152.53.132.244)
transmit(162.159.200.123)
transmit(78.41.116.149)
transmit(86.59.113.124)
transmit(152.53.132.244)
transmit(162.159.200.123)
transmit(78.41.116.149)
transmit(86.59.113.124)
transmit(152.53.132.244)
transmit(162.159.200.123)
transmit(78.41.116.149)
transmit(86.59.113.124)
transmit(152.53.132.244)
transmit(162.159.200.123)
78.41.116.149: Server dropped: no data
86.59.113.124: Server dropped: no data
152.53.132.244: Server dropped: no data
162.159.200.123: Server dropped: no data
server 78.41.116.149, port 123
stratum 0, precision 0, leap 00, trust 000
refid [78.41.116.149], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
originate timestamp: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
transmit timestamp: ee2026d1.ca1df3e9 Fri, Aug 7 2026 11:41:37.789
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 86.59.113.124, port 123
stratum 0, precision 0, leap 00, trust 000
refid [86.59.113.124], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
originate timestamp: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
transmit timestamp: ee2026d1.fd51b457 Fri, Aug 7 2026 11:41:37.989
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 152.53.132.244, port 123
stratum 0, precision 0, leap 00, trust 000
refid [152.53.132.244], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
originate timestamp: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
transmit timestamp: ee2026d2.308472c5 Fri, Aug 7 2026 11:41:38.189
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 162.159.200.123, port 123
stratum 0, precision 0, leap 00, trust 000
refid [162.159.200.123], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
originate timestamp: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
transmit timestamp: ee2026d2.63b77092 Fri, Aug 7 2026 11:41:38.389
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

7 Aug 11:41:40 ntpdate[1758]: no server suitable for synchronization found

6

Adding the ntp servers IP address to Control Panel → Security → Allow/Deny List → “Allow connections from the list only” solves the problem.
But this begs two questions:
Why is ntp traffic not tracked and allowed in, if it matches a request sent by the NAS?
Why did I see the reply in tcpdump?