Everything posted by alex7
-
zusätzilche NIC aktivieren
ahhh check jetzt hab ich das auch kapiert mit dem "bind to vfio ..." button ;D zudem habe ich versehentlich die NICs miteinander verwechselt danke dir
-
zusätzilche NIC aktivieren
Also ich hatte VMs generell deaktiviert. Ich habe es jetzt mal aktiviert und hatte da mal irgendwann zwei Test VMs erstellt, allerdings war dort keine spezifische Schnittstelle zugeordnet. Ich muss mal die Tage schauen ob die Onboard NIC evtl im BIOS deaktiviert ist, oder würde sie dann gar nicht erst in unraid zu sehen sein?
-
zusätzilche NIC aktivieren
Ach, ich habe glaube ich gerade über einen anderen Thread, bei dem es um Netzwerkabbrüche geht, vermutlich zufällig das "Problem" entdeckt. Dort wurde das Bonding erwähnt und bei mir war das aktiv und daher wurde das zweite Interface vermutlich nicht unter den Netzwerk Einstellungen angezeigt. Ich werde das gleich mal testen Edit: Also das Kabel war vorher schon verbunden mit dem Switch, und es zeigt auch einen Link an. Allerrdings wird weiterhin das zweite Interface nicht in den Netzwerk Einstellungen angezeigt. Sollte das nicht hier aufgelistet werden?
-
zusätzilche NIC aktivieren
Moin zusammen, ich habe eine zweite NIC in mein Unraid Server eingebaut bzw. war dort von Anfang an vorhanden. Ich würde diese gerne aktivieren, allerdings finde ich keinen Punkt wo ich das erledigen kann. Kann mir jemand einen Tipp geben wo ich mal nachschauen sollte oder was ich vielleicht übersehen haben könnte? vg
-
AMP - ASKA Gameserver
Okay sorry für den Thread, es läuft wohl doch alles so wie es soll. Ich habe auch nichts besonderes jetzt eingestellt. Die Ports von mir stimmten schon, auch wenn ich sie von außen nicht erreiche. Der Server ist erreichbar, aber eben nur über den Ingame Gameserver Browser. Ich musste nur alle 30 Seiten einmal durchblättern weil es keine Filter oder direct connect gibt.
-
AMP - ASKA Gameserver
hi zusammen, ich würde gerne einen aska gameserver über amp starten. soweit läuft er auch, allerdings nicht im container modus. ports habe ich auch freigegeben, aber aus irgendwelchen gründen, kann ich sie von aussen nicht erreichen. die option "exclude from firewall" hatte ich mal getestet, allerdings hilft das auch nicht wirklich. hat bereits jemand mal einen server über unraid in amp erstellt und auch erreichbar gemacht? bzw. hat noch jemand eine idee was ich prüfen könnte? merkwürdig finde ich auch, dass wenn der server läuft, keine ip angezeigt wird: vg
-
Nginx Proxy Manager - https -> https mit eigenem Zertifikat
Danke für eure Antworten. Ich habe mir Zoraxy mal angeschaut und dann nochmal recherchiert. Es gibt beim Nginx Proxy Manager den Reiter "Advanced" um eigene Config-Einstellungen vorzunehmen. Ich bin bei der Recherche dann auf diese Config gestoßen (bezogen auf mein Beispiel): location / { proxy_pass https://abc.def.xy:8000; proxy_ssl_verify off; proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; } Hiermit kann ich nun das Zertifikat auf beim Proxy Host ignorieren und mein eigenes über den Reverse Proxy einbinden. Über den ersten Eintrag "location /" könnte man noch auf Subfolder verweisen.
-
Nginx Proxy Manager - https -> https mit eigenem Zertifikat
Hallo zusammen, weiß jemand ob bzw. wie ich einen neuen Host beim Nginx Proxy Manager anlegen kann, bei dem die Zieladresse bereits ein eigenes/selbst ausgestelltes Zertifikat besitzt, ich selbst aber über den NPM ein anderes Zertifikat mitgeben möchte? als Beispiel: mein Zielhost ist nur über https://abc.def.xy:8000 mit einem selbst ausgestellten Zertifikat zu erreichen. Durch den NPM möchte ich nun aber den Server gerne per https://neu.test.de mit einem eigenen Zertifikat erreichbar machen. VG
-
Zweite NIC wird nicht angezeigt
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
-
Zweite NIC wird nicht angezeigt
Ich hoffe man kann es darauf erkennen, hab das Screenshot auf dem Handy erstellt. Sind beide rot markiert
-
Zweite NIC wird nicht angezeigt
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
-
nextcloud container start probleme
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
-
cron for user root /usr/bin/run-parts /etc/cron.daily 1> /dev/null
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?
-
Korrekte Uhrzeit in docker containern
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.
-
Korrekte Uhrzeit in docker containern
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
-
Korrekte Uhrzeit in docker containern
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.
-
Korrekte Uhrzeit in docker containern
Das habe ich aus Frust mind. schon 5-10 mal gemacht 😞
-
Korrekte Uhrzeit in docker containern
@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.
-
Korrekte Uhrzeit in docker containern
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.
-
Korrekte Uhrzeit in docker containern
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.
-
Korrekte Uhrzeit in docker containern
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.
-
Korrekte Uhrzeit in docker containern
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