June 23, 20224 yr Hallo zusammen, ich bin noch relativ neu beim System unRaid und auch allgemein bei Linux. Mein Problem ist aber zur Zeit, dass ich unter anderem bei Vaultwarden und CloudberryBackup Probleme mit der richtigen Uhrzeit habe. Vielleicht ist es auch nur ein Logik Problem, was ich bisher nicht richtig verstanden habe. Und zwar wird in der Shell des Hosts (unRaid) und z.B. in der Shell von vaultwarden über den Befehl "date" die korrekte Zeit angezeigt. Wenn ich allerdings in die Diagnostic von vaultwarden gehe, wird mir angezeigt (siehe Anhang), dass die servertime (welche korrekt ist) 15:19 UTC ist, browsertime allerdings 2h zurück ist (weswegen ich kein TOTP nutzen kann, das ist auch der Grund weshalb ich auf der Fehlersuche bin). Bei CloudberryBackup ist mir dann aufgefallen, dass dort ein ähnliches Problem ist. Backup soll um 4 Uhr morgens gemacht werden, wird aber schon um 2 Uhr morgens gestartet. Selbst wenn ich die Zeitzone bei unRaid ändere, ändert das nichts an der Zeit die z. B. in vaultwarden über die diagnostic angezeigt wird. Sowohl servertime, als auch browsertime bleiben identisch. Ich bin mir nicht sicher, an welcher Stelle ich jetzt suchen soll. Habt ihr eine Idee? vg, alex7 Edited June 23, 20224 yr by alex7
June 24, 20224 yr 18 hours ago, alex7 said: Wenn ich allerdings in die Diagnostic von vaultwarden gehe, wird mir angezeigt (siehe Anhang), dass die servertime (welche korrekt ist) 15:19 UTC ist, browsertime allerdings 2h zurück ist (weswegen ich kein TOTP nutzen kann, das ist auch der Grund weshalb ich auf der Fehlersuche bin). Bei CloudberryBackup ist mir dann aufgefallen, dass dort ein ähnliches Problem ist. Backup soll um 4 Uhr morgens gemacht werden, wird aber schon um 2 Uhr morgens gestartet. Ich würd die Frage im Vaultvarden Support Thread stellen. Normalerweise wenn du eine Variable mit dem Key: TZ im Docker Template anlegst mit dem Value: Europe/Berlin oder Europe/Vienna oder was auch immer dann sollte der Container die Richtige Zeit übernehmen. Ich weiß leider nicht ob der Vaultwarden container die variable unterstützt, sollte aber zumindest wenn er Debian basiert ist (ich glaub wenn er Ubuntu basiert ist funktioniert das nicht weil es dort einen Bug gibt meines wissens). Vergiss bitte nicht das unsere Zeitzone normalerweise UTC +2 ist.
June 24, 20224 yr Author Ich habe mir gerade nochmal die Date and Timesettings bei unRaid angeschaut. Es sieht nun bei mir so aus (siehe Bild) Wieso wird die Uhrzeit zwei Stunden im voraus angezeigt? Irgendwo habe ich auch gelesen, dass es evtl. mit dem BIOS zu tun hat, kann das sein? Ich habe das Topic vielelicht falsch benannt, weil es ist anscheinend grundsätzlich ein Problem von unRaid. Wenn ich rein UTC auswähle in der Zeitzone, stimmt die Uhrzeit mit der deutschen Zeit.
June 24, 20224 yr 2 hours ago, alex7 said: Ich habe das Topic vielelicht falsch benannt, weil es ist anscheinend grundsätzlich ein Problem von unRaid. Eher weniger... Momentan haben wir UTC+2 da wir Sommerzeit haben. Wie gesagt ich würde hier eher einen Post im Support Thread von Valtwarden machen anstatt hier und auch eher deinem Browser die Schuld zu schieben weil der die Ziet UTC +0 anzeigt soweit ich von deinem Screenshot sehen kann. Das hat auch eher weniger mit der Zeit des Hosts (Unraid) zu tuhen. Hast du denn schon versucht wie oben beschrieben eine Variable mit TZ zu erstellen?
June 24, 20224 yr Author Also da andere Container auch betroffen sind und die Uhrzeit grundsätzlich falsch läuft in Unraid, denke ich nicht dass der Fehler bei Vaultwarden liegt. Tatsächlich habe ich da schon ein offenes Topic, das ich vor diesem hier gemacht habe. Ursprünglich dachte ich nämlich auch es läge an Vaultwarden. wenn ich in Unraid UTC+1 Europe/Berlin einstelle haben wir zB statt tatsächlich 14 Uhr, 16 Uhr. Stelle ich es auf „UTC - Coordinated Universal Time“ (sprich, ohne Zeitzone) ist die Uhrzeit korrekt in Unraid. Und Ja, die Variable hatte ich schon früh ausprobiert, aber Vaultwarden unterstützt diese wohl nicht. Edited June 24, 20224 yr by alex7
June 24, 20224 yr Community Expert Du hast ja wilde Zeitserver hinterlegt. Mal in den syslogs geschaut, ob es evtl Fehler bei der Verbindung dahin gibt? Meine Einstellungen: Bei dir fällt auf, dass kein CEST als Zeitzone beim Datum steht. Keine Ahnung warum das bei dir anders ist.
June 25, 20224 yr Blöde Frage: Warum tragt Ihr die individuellen Zeitserver in Unraid ein, statt den Router zu verwenden? In meinem Router sind diese eingetragen "time.cloudflare.com; 2.europe.pool.ntp.org" und der Router versorgt dann alle Geräte im eigenen Netz. So muss nicht jedes Gerät nach draußen abfragen.
June 25, 20224 yr 11 minutes ago, hawihoney said: Blöde Frage: Warum tragt Ihr die individuellen Zeitserver in Unraid ein, statt den Router zu verwenden? In meinem Router sind diese eingetragen "time.cloudflare.com; 2.europe.pool.ntp.org" und der Router versorgt dann alle Geräte im eigenen Netz. So muss nicht jedes Gerät nach draußen abfragen. @alex7 hat doch eigene Zeitserver eingetragen, aber das kann auch genau das Problem sein in seinem Fall. Gut das du darauf hingewiesen hast...
June 25, 20224 yr 2 hours ago, ich777 said: hat doch eigene Zeitserver eingetragen, aber das kann auch genau das Problem sein in seinem Fall. Ich glaube wir reden gerade aneinander vorbei. Statt die individuellen Zeitserver in Unraid einzutragen, sehe ich eine solche Konfiguration eigentlich an zentraler Stelle des eigenen Netzwerks - dem Router. Dann trägt man in Unraid, und allen weiteren Geräten im eigenen Netzwerk, nur noch den Router als Zeitserver ein (z.B. Fritzbox 192.168.178.1). Und genau darauf zielte meine OT Frage ab: Wieso sehe ich hier sehr oft im Unraid Server externe Zeitserver? Hat das irgendwelche Vorteile? Ich ging bisher davon aus, dass es eher nachteilig ist.
June 25, 20224 yr 8 minutes ago, hawihoney said: Ich glaube wir reden gerade aneinander vorbei. Statt die individuellen Zeitserver in Unraid einzutragen, sehe ich eine solche Konfiguration eigentlich an zentraler Stelle des eigenen Netzwerks - dem Router. Dann trägt man in Unraid, und allen weiteren Geräten im eigenen Netzwerk, nur noch den Router als Zeitserver ein (z.B. Fritzbox 192.168.178.1). Nein, glaub ich nicht, ich verstehe dich schon. Aber er hat ja, wie du oben in seinem Screenshot siehst, eigene Zeitserver eingetragen, vielleicht liegt dort das Problem... Ich verstehe schon was du damit sagen willst aber vielleicht liefern die Zeitserver die er eingetragen hat die Zeit anders, wie @mgutt schon erwähnte wird bei ihm kein CEST oder sonstiges angezeigt.
June 25, 20224 yr Author Also ich habe das jetzt mal so eingestellt: - in der FRITZ!Box den Zeitserver mal geändert auf ptbtime1.ptb.de - in unraid nur die FRITZ!Box eingetragen - Zeitzone in Unraid „normal“ auf Europe/Berlin+1 Trotz allem ist die Zeit noch zwei Stunden im Voraus. Das wirkt so, als ob er die richtige Zeit bekommt, aber durch die eingestellte Zeitzone NOCHMAL zwei Stunden drauf rechnet. Ich kann es mir aber nicht erklären.
June 25, 20224 yr Community Expert Wie ich777 schon meinte, ist nicht der Zeitserver dein Problem, sondern irgendwas in den Unraid Einstellungen stimmt nicht. Gib mal bitte das alles in der Konsole ein: Das sollte die Zeit deiner Zeitzone zurückgeben: date Das hier sollte die UTC Zeit zurückgeben: date -u Das sind die Dateien, die Unraid verwendet um die Zeitzone des Servers festzulegen: ls -l /etc/localtime* Wir prüfen, dass deren Inhalt identisch ist: md5sum /etc/localtime md5sum /usr/share/zoneinfo/Europe/Berlin Grundeinstellungen zur Sprache des Servers (da sollte nichts relevantes für die Zeitzone bei rauskommen, aber wir fragen es einfach mal ab): printenv | grep -P '(LC|LANG)' Das liest die Zeit vom BIOS aus: hwclock --show Das korrigiert die Zeit vom BIOS (mit --test simuliert es das nur), falls die zu schnell oder zu langsam "tickt": hwclock --verbose --test --date --set
June 25, 20224 yr Community Expert 4 hours ago, hawihoney said: Blöde Frage: Warum tragt Ihr die individuellen Zeitserver in Unraid ein, statt den Router zu verwenden? In meinem Router sind diese eingetragen "time.cloudflare.com; 2.europe.pool.ntp.org" und der Router versorgt dann alle Geräte im eigenen Netz. So muss nicht jedes Gerät nach draußen abfragen. Vermutlich hast du damit nur ein Gerät von vielen an deinen Router gebunden. zB Android nutzt seinen eigenen Zeitserver: https://stackoverflow.com/questions/14381005/is-android-using-ntp-to-sync-time#comment31821643_14523190 Und ich denke mal jedes Gerät hat seine eigenen Werte hinterlegt, statt darauf zu "hoffen", dass der Router das kann. Der Standard-Intervall ist übrigens 17 Minuten: https://stackoverflow.com/a/45244298/318765
June 25, 20224 yr 2 hours ago, mgutt said: Android nutzt seinen eigenen Zeitserver Danke für den Link. Wusste ich noch nicht. Alle anderen Devices gehen aber über den Router bei uns.
June 25, 20224 yr Community Expert 6 hours ago, hawihoney said: Blöde Frage: Warum tragt Ihr die individuellen Zeitserver in Unraid ein, statt den Router zu verwenden? Weil ein neu startender Router (nach Stromausfall) in aller Regel keine Stützbatterie hatte um die Zeit korrekt zu halten. Erst wenn er wieder online ist und sich snchronisiert hat kennt er die aktuelle Zeit. Das ist bei Ausfallsicherung per MultiWAN und ggf. mehreren Routern ungünstig. Meine Primäre Fritzbox mach aktuell nur für eine WAN die Anbindung und hat seit 2 Wochen schon 2 komplette Neustarts hingelegt (aktuell tippe ich auf schwächelndes Netzteil). Meine HardwareFirewall handelt die WAN Anbindungen. 6 hours ago, hawihoney said: In meinem Router sind diese eingetragen "time.cloudflare.com; 2.europe.pool.ntp.org" und der Router versorgt dann alle Geräte im eigenen Netz. Wenn er erreichbar ist und die aktuellen Zeiten hat (also online ohne Stromausfall). 6 hours ago, hawihoney said: So muss nicht jedes Gerät nach draußen abfragen. Kann man so machen.
June 25, 20224 yr Author 7 hours ago, mgutt said: Wie ich777 schon meinte, ist nicht der Zeitserver dein Problem, sondern irgendwas in den Unraid Einstellungen stimmt nicht. Gib mal bitte das alles in der Konsole ein: Das sollte die Zeit deiner Zeitzone zurückgeben: date Das hier sollte die UTC Zeit zurückgeben: date -u Das sind die Dateien, die Unraid verwendet um die Zeitzone des Servers festzulegen: ls -l /etc/localtime* Wir prüfen, dass deren Inhalt identisch ist: md5sum /etc/localtime md5sum /usr/share/zoneinfo/Europe/Berlin Grundeinstellungen zur Sprache des Servers (da sollte nichts relevantes für die Zeitzone bei rauskommen, aber wir fragen es einfach mal ab): printenv | grep -P '(LC|LANG)' Das liest die Zeit vom BIOS aus: hwclock --show Das korrigiert die Zeit vom BIOS (mit --test simuliert es das nur), falls die zu schnell oder zu langsam "tickt": hwclock --verbose --test --date --set @mgutt danke erstmal für die ausführliche Erklärung! Ich habe die Befehle mal ausgeführt. Mir ist aufgefallen, dass bei mir der Pfad zur Zeitzone fehlt. Hast du den manuell eingetragen? root@SERVERv1:~# date Sat Jun 25 21:32:36 CEST 2022 root@SERVERv1:~# date -u Sat Jun 25 19:32:52 UTC 2022 root@SERVERv1:~# ls -l /etc/localtime -rw-r--r-- 1 root root 2298 Jun 25 21:31 /etc/localtime root@SERVERv1:~# md5sum /etc/localtime 7db6c3e5031eaf69e6d1e5583ab2e870 /etc/localtime root@SERVERv1:~# printenv | grep -P '(LC|LANG)' LANG=en_US.UTF-8 LC_COLLATE=C root@SERVERv1:~# hwclock --show 2022-06-25 21:35:33.949605+02:00 root@SERVERv1:~# hwclock --verbose --test --date --set hwclock from util-linux 2.37.4 System Time: 1656185772.186420 Trying to open: /dev/rtc0 Using the rtc interface to the clock. Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2022/06/25 19:36:13 Hw clock time : 2022/06/25 19:36:13 = 1656185773 seconds since 1969 Time since last adjustment is 1656185773 seconds Calculated Hardware Clock drift is 0.000000 seconds 2022-06-25 21:36:12.168237+02:00 Test mode: nothing was changed.
June 25, 20224 yr Community Expert Ändere mal bitte in den Datumseinstellungen die Zeitzone auf eine andere Zone und dann zurück auf Berlin.
June 26, 20224 yr Community Expert 16 hours ago, alex7 said: Mir ist aufgefallen, dass bei mir der Pfad zur Zeitzone fehlt Du hast den Stern vergessen. So: ls -l /etc/localtime* Da der MD5 Hash aber genauso lautet wie bei mir, können wir davon ausgehen, dass auch bei dir Berlin gesetzt wurde. War denn der Wert von "date" deine aktuelle Zeit?
June 26, 20224 yr Author 1 hour ago, mgutt said: Du hast den Stern vergessen. So: ls -l /etc/localtime* Da der MD5 Hash aber genauso lautet wie bei mir, können wir davon ausgehen, dass auch bei dir Berlin gesetzt wurde. War denn der Wert von "date" deine aktuelle Zeit? Du hast recht, die Zeitzone stimmt. root@SERVERv1:/# date Sun Jun 26 15:21:29 CEST 2022 root@SERVERv1:/# date -u Sun Jun 26 13:21:31 UTC 2022 Also 'date' stimmt nicht, das ist schon zwei Stunden voraus. 'date -u' stimmt dagegen. Die BIOS Zeit stimmt auch nicht, die er bei dem Befehl ausgibt, weil er da zwei Stunden drauf rechnet. Ist das mein Problem? Wenn ich ins BIOS gehe und die Zeit prüfe stimmt sie.
June 26, 20224 yr Community Expert 8 minutes ago, alex7 said: Also 'date' stimmt nicht, das ist schon zwei Stunden voraus. 'date -u' stimmt dagegen. Das darf nicht sein. Guckst du: Versuch mal manuell die Zeit anzupassen: ntpdate -s time1.google.com Alternativ im Debug Modus: ntpdate -d -s time1.google.com
June 26, 20224 yr Author So, ich habe beides mal ausprobiert. Leider hat sich nichts geändert. root@SERVERv1:~# date Sun Jun 26 17:11:00 CEST 2022 root@SERVERv1:~# ntpdate -s time1.google.com root@SERVERv1:~# date Sun Jun 26 17:11:13 CEST 2022 root@SERVERv1:~# ntpdate -d -s time1.google.com 26 Jun 17:11:31 ntpdate[17544]: ntpdate [email protected] Fri May 21 19:02:16 UTC 2021 (1) Looking for host time1.google.com and service ntp 216.239.35.0 reversed to time1.google.com host found : time1.google.com transmit(216.239.35.0) receive(216.239.35.0) transmit(216.239.35.0) receive(216.239.35.0) transmit(216.239.35.0) receive(216.239.35.0) transmit(216.239.35.0) receive(216.239.35.0) server 216.239.35.0, port 123 stratum 1, precision -20, leap 00, trust 000 refid [GOOG], root delay 0.000000, root dispersion 0.000107 reference time: e662d95f.9103d310 Sun, Jun 26 2022 15:10:55.566 originate timestamp: e662d95f.9103d313 Sun, Jun 26 2022 15:10:55.566 transmit timestamp: e662f5a9.490d4bcc Sun, Jun 26 2022 17:11:37.285 filter delay: 0.04666 0.04520 0.04550 0.04532 ---- ---- ---- ---- filter offset: -7241.7283 -7241.7286 -7241.7287 -7241.7287 ---- ---- ---- ---- delay 0.04520, dispersion 0.00009, offset -7241.728667 26 Jun 17:11:37 ntpdate[17544]: step time server 216.239.35.0 offset -7241.728667 sec root@SERVERv1:~# date Sun Jun 26 17:11:43 CEST 2022
June 26, 20224 yr Author Also ich bin mir jetzt nicht sicher, ob die letzten Befehle die du mir genannt hast, nach dem Reboot etwas bewirkt haben. Allerdings hatte ich nun parallel noch eine Vermutung und habe den Server von meinem Switch im Serverschrank direkt auf die Fritzbox gesteckt. Und ich habe nach dem Reboot nun tatsächliche die korrekt Zeit Ich gehe mal ganz stark davon aus, dass der Switch das Problem war ich hatte mit einer anderen Anwendung auf meinem PC auch mal das Problem und musste direkt an die Fritzbox. Was letztendlich das Problem auf dem Switch ist, kann ich nicht ganz nachvollziehen. Trotzdem danke ich nochmal allen die etwas beigesteuert haben und speziell nochmal an @mgutt und @ich777 für die Mühe. Ich versuche dann mal den Fehler beim Switch zu suchen.
June 26, 20224 yr Community Expert 17 minutes ago, alex7 said: Was letztendlich das Problem auf dem Switch ist, kann ich nicht ganz nachvollziehen. Sehen tue ich jetzt auch nichts. Weil ich hätte dann erwartet, dass "ntpdate" einen Fehler zurückgibt. Dass dein Datum anders aussieht als bei uns, dürfte übrigens an der Einstellung liegen: Ich denke du hast da explizit DD-MM-YYYY ausgewählt und dadurch fliegt bei dir das "CEST" bei der Darstellung raus. Trotzdem sollte natürlich das Datum richtig angezeigt werden, egal was man da gewählt hat.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.