ntpdate stellt die Uhrzeit nicht ein

English Allgemein
1

Ich verwende QuTS hero h6.0.1.3564.
Obwohl ich gültige NTP-Pakete vom Server zurückbekomme (ich habe timer.jku.at, pool.ntp·org, time.google·com und weitere ausprobiert), werden die Pakete von ntpdate nicht interpretiert. [Das letzte . ersetzt, um zu verhindern, dass die fqdn als Link angezeigt wird]

Ein tcpdump zeigt:
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 (sekundäre Referenz), Poll 3 (8s), Präzision -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

Aber $ ntpdate -b -d pool.ntp·org sagt:
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 Do, 7. Feb 2036 7:28:16.000
originate timestamp: 00000000.00000000 Do, 7. Feb 2036 7:28:16.000
transmit timestamp: ee1c7388.985cf984 Di, 4. Aug 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]: kein geeigneter Server für die Synchronisierung gefunden

Da tcpdump antworten sieht und interpretiert, kann es sich nicht um ein DNS- oder Firewall-Problem handeln.

Hat jemand eine Idee, wie ich das Problem lösen kann?

2

Könntest du zunächst prüfen, ob die Systemzeit deines NAS deutlich von der aktuellen Uhrzeit abweicht? Ein großer Unterschied kann zu Synchronisationsproblemen mit NTP führen. Versuch, die Uhrzeit des NAS näher an die tatsächliche Zeit zu setzen und schau, ob das hilft.

Wenn das Problem weiterhin besteht, könntest du auch prüfen, ob ein Computer im selben Netzwerk das gleiche Problem hat? Das würde uns helfen, die Ursache einzugrenzen. Danke!

3

Ich habe die Zeit mit meinem Desktop synchronisiert, bevor ich versucht habe, ntp zu nutzen. Mein Desktop verwendet dieselbe ntp-Quelle (timer.jku.at), daher unterscheiden sich die Zeiten momentan um weniger als eine Sekunde. Außerdem sollte die Option -b ntpdate dazu veranlassen, die Zeit unabhängig von der Differenz direkt zu setzen.
Ich habe mehrere Linux-VMs im selben Subnetz, und keine von ihnen hat Probleme dabei, die ntp-Zeit von timer.jku.at abzurufen. Die meisten laufen mit chrony, aber ich habe auf zweien zusätzlich ntpdate 4.2.8_p18 installiert und getestet (sollte nah genug dran sein, denke ich), und das funktioniert ebenfalls.

4

Könntest du uns mitteilen, ob du versucht hast, über die GUI zu arbeiten oder ob du die Befehle direkt eingegeben hast? Außerdem wäre es hilfreich, wenn du uns das vollständige Konsolenprotokoll des Befehls $ ntpdate -b -d pool.ntp.org schicken könntest — insbesondere den „[…]“-Abschnitt, der in deinem Beitrag ausgelassen wurde. Vielen Dank!

5

Mir wurde das Problem bewusst, als ich benachrichtigt wurde, dass der automatische tägliche Lauf fehlgeschlagen war. ([Allgemeine Einstellungen] Zeit konnte nicht mit dem NTP-Server „timer.jku.at“ synchronisiert werden.) Daraufhin ging ich zu Allgemeine Einstellungen → Zeit und klickte auf die Schaltfläche Verbindung testen, was ebenfalls scheiterte.
Dann begann ich, im Terminal zu recherchieren.
Hier ist die vollständige Ausgabe von $ 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)
Suche nach Host pool.ntp.org und Dienst ntp
78.41.116.149 rückwärts zu time1.funkfeuer.at
Host gefunden: 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 abgewiesen: keine Daten
86.59.113.124: Server abgewiesen: keine Daten
152.53.132.244: Server abgewiesen: keine Daten
162.159.200.123: Server abgewiesen: keine Daten
server 78.41.116.149, port 123
stratum 0, präzision 0, leap 00, trust 000
refid [78.41.116.149], delay 0.00000, dispersion 64.00000
übertragen 4, im Filter 4
Referenzzeit: 00000000.00000000 Do, 7. Feb 2036 7:28:16.000
Ursprungstimestamp: 00000000.00000000 Do, 7. Feb 2036 7:28:16.000
Übertragungszeitstempel: ee2026d1.ca1df3e9 Fr, 7. Aug 2026 11:41:37.789
Filterverzögerung: 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
Verzögerung 0.00000, Dispersion 64.00000
Offset 0.000000

server 86.59.113.124, port 123
stratum 0, präzision 0, leap 00, trust 000
refid [86.59.113.124], delay 0.00000, dispersion 64.00000
übertragen 4, im Filter 4
Referenzzeit: 00000000.00000000 Do, 7. Feb 2036 7:28:16.000
Ursprungstimestamp: 00000000.00000000 Do, 7. Feb 2036 7:28:16.000
Übertragungszeitstempel: ee2026d1.fd51b457 Fr, 7. Aug 2026 11:41:37.989
Filterverzögerung: 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
Verzögerung 0.00000, Dispersion 64.00000
Offset 0.000000

server 152.53.132.244, port 123
stratum 0, präzision 0, leap 00, trust 000
refid [152.53.132.244], delay 0.00000, dispersion 64.00000
übertragen 4, im Filter 4
Referenzzeit: 00000000.00000000 Do, 7. Feb 2036 7:28:16.000
Ursprungstimestamp: 00000000.00000000 Do, 7. Feb 2036 7:28:16.000
Übertragungszeitstempel: ee2026d2.308472c5 Fr, 7. Aug 2026 11:41:38.189
Filterverzögerung: 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
Verzögerung 0.00000, Dispersion 64.00000
Offset 0.000000

server 162.159.200.123, port 123
stratum 0, präzision 0, leap 00, trust 000
refid [162.159.200.123], delay 0.00000, dispersion 64.00000
übertragen 4, im Filter 4
Referenzzeit: 00000000.00000000 Do, 7. Feb 2036 7:28:16.000
Ursprungstimestamp: 00000000.00000000 Do, 7. Feb 2036 7:28:16.000
Übertragungszeitstempel: ee2026d2.63b77092 Fr, 7. Aug 2026 11:41:38.389
Filterverzögerung: 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
Verzögerung 0.00000, Dispersion 64.00000
Offset 0.000000

  1. Aug 11:41:40 ntpdate[1758]: kein Server geeignet für Synchronisation gefunden
6

Das Hinzufügen der IP-Adresse des NTP-Servers zu Systemsteuerung → Sicherheit → Zulassen/Sperren-Liste → „Nur Verbindungen aus der Liste zulassen“ löst das Problem.

Aber das wirft zwei Fragen auf:
Warum wird NTP-Verkehr nicht verfolgt und zugelassen, wenn er einer vom NAS gesendeten Anfrage entspricht?
Warum habe ich die Antwort im tcpdump gesehen?