alex7

Okay das hat schon geholfen, ty Tatsächlich war es vorher nicht angehakt und es wurde trotzdem nicht angezeigt, deshalb dachte ich, ich hau mal die Haken da rein Aber sieht jetzt gut aus, danke dir

Ich hoffe man kann es darauf erkennen, hab das Screenshot auf dem Handy erstellt. Sind beide rot markiert

Hallo zusammen, ich habe einen komplett neuen Server für meine Unraid Platten. Ich habe nun die klassische onboard NIC und eine zusätzliche Netzwerkkarte. Beim ersten Boot hat er auch direkt die Netzwerkkarte erkannt und als "Main-NIC" genutzt. Die zweite wird in der "System-Device" Übersicht auch erkannt, sofern ich das so deuten kann. Allerdings wird sie in der Übersicht "Network Settings" nicht angezeigt. Muss ich sie erst noch irgendwo aktivieren? # vg

Hallo zusammen, ich habe seit dem unraid update auf 6.12 probleme den nextcloud container zu starten. wenn ich den port ändere funktioniert es, wenn ich ihn wieder zurücksetze auf 443 kommt folgende fehlermeldung: docker run -d --name='nextcloud' --net='bridge' -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -e HOST_HOSTNAME="SERVERv1" -e HOST_CONTAINERNAME="nextcloud" -e 'PUID'='99' -e 'PGID'='100' -e 'UMASK'='022' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='https://[IP]:[PORT:443]' -l net.unraid.docker.icon='https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/nextcloud-logo.png' -p '443:443/tcp' -v '/mnt/user/nextcloud/':'/data':'rw' -v '/mnt/user/appdata/nextcloud':'/config':'rw' 'lscr.io/linuxserver/nextcloud:26.0.2-ls246' 887f42836aec88aa07f23bb344fd556e785b67741a63ac85ef6d9c5c88f7a92e docker: Error response from daemon: driver failed programming external connectivity on endpoint nextcloud (661efd68fcff40c402a1bb8c05fe7fa74685606f7f46b9d48efec2d397a5ed77): Error starting userland proxy: listen tcp4 0.0.0.0:443: bind: address already in use. The command failed. Ich hatte jetzt mal pauschal alle container gestoppt, in denen 443 vorkommt, egal ob sie im container oder in unraid gemappt sind. hat jemand eine idee, vielleicht auch wo ich genauer nach nach der ursache schauen kann? vg

Same here. I thought it came from the plugin "Nerdpack". But I had already uninstalled this and still have the problem. So I installed and uninstalled Nerdpack again. But made no change. Do you have Nerdpack or did you have installed it before?

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.

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

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.

Das habe ich aus Frust mind. schon 5-10 mal gemacht 😞

@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.

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.

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.

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.

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