mgutt

Ich persönlich halte nichts von den Jxxxx Boards. Habe selbst eines im Backup Server. Der Verbrauch ist nicht besser, man hat wenig SATA Ports und erweitern kann man es auch nicht wirklich. Meistens ist der PCIe Slot auch geschlossen, was den Einbau zb von HBA oder 10G Karten erschwert. Wenn die günstig sind ok, aber nicht zu den aktuellen Preisen. Ja geht genauso Gar keinen Strom geht bei HDDs leider nicht (1 bis 2W im Stillstand). Das können nur SSDs (liegen dann im Milliwatt Bereich). Wenn nicht dafür, wofür sonst ^^

This bug seems to be present for a long time: For me its a daily situation (backups) when symlinks are created. So a manually move is not practical.

Check the first posts how to debug 5xx errors

Soweit ich weiß, gibt es das nicht. Die kannst du nur manuell bei der Plattform prüfen auf der der Container gepflegt wird und selbst dann sind es keine vorgefertigten Texte, sondern du müsstest dich manuell durch die Issues hangeln. Dazu kommt, dass ein Container häufig aus verschiedenen Teilen besteht, die selbst auch wieder eigene Projektseiten haben. Also nehmen wir als Beispiel Nextcloud. Hier könnte folgendes aktualisiert werden: - Betriebssystem - Webserver - PHP + diverse PHP Module - Nextcloud Bei Nextcloud war es mir zb nicht möglich herauszufinden was sich im Container ändert. Nur Nextcloud selbst wird dokumentiert: https://nextcloud.com/changelog/ Denn obwohl das Nextcloud Projekt selbst Releases pflegt: https://github.com/nextcloud/server/releases Wird beim Container nichts veröffentlicht: https://github.com/nextcloud/docker/releases Einfach aus eigenem Interesse habe ich das dann mal selbst versucht nachzuvollziehen: Schaut man sich zb das Alpine (Betriebssystem) Docker Template an, dann sieht man in der ersten Zeile, dass der offizielle PHP Docker mit Alpine 3.15 verwendet wird: https://github.com/nextcloud/docker/blob/master/Dockerfile-alpine.template Klickt man auf die "Uhr" kommt man hier hin und sieht wann was in dem Template geändert wurde: https://github.com/nextcloud/docker/commits/master/Dockerfile-alpine.template Klickt man auf die Änderung "1643", kommt man hier hin: https://github.com/nextcloud/docker/pull/1643 Wir sehen nun, dass im Dezember 2021 die Alpine Version von 3.14 auf 3.15 geändert wurde. Klicken wie nun auf "Checks" kommen wir hier hin: https://github.com/nextcloud/docker/pull/1643/checks Klickt man auf "Images" kommt man hier hin: https://github.com/nextcloud/docker/actions/runs/1523334386 Es scheint also, dass die dort angezeigten Container Versionen wie zb 23.0.0 die neue Alpine Version erhalten haben (mittlerweile gibt es ja 23.0.3). Wobei das ja auch nur "Checks" sind. Was nun genau in Richtung Docker Hub veröffentlicht wurde, kann denke ich keiner sagen. Also alles etwas intransparent.

Deaktiviere testweise mal bei Docker " Host access to custom networks" Steht "preserve custom networks" auf yes? Auch mal deaktivieren. Zeig außerdem mal deine Routen ip route show table all Danach darf sich @Ford Prefect Gedanken machen ^^

Den offiziellen Container kann man wohl auch als FPM ohne Webserver starten. Dann braucht man einen separaten Nginx Container. Aber zugegeben habe ich keine Ahnung wie man das zum Laufen bringt ^^

Versetz das Array mal in den Wartungsmodus und repariere alle Disks (klicken auf Disk1 > xfs_repair). Wenn das nicht hilft, würde ich das mal als Bug melden.

Du hast in jedem Fall kritische Linux Fehler. Also das was du auf dem Bildschirm siehst. Check deine Logs nach Fehlern und lad diese hoch. Ich persönlich würde zu der Zeit keinen Rebuild von Daten machen. Wer weiß ob die Daten dann wirklich in Ordnung sind.

Du verstehst da noch was falsch. Nginx ist der Webserver in dem Wordpress installiert ist. Der lauscht ausschließlich auf Port 8080. Einen Port 80 gibt es nicht. Würdest du nun also den Container im br0 oder Host Netzwerk starten, würde der Container ausschließlich auf Port 8080 reagieren. Wenn du dagegen den Nginx auf 8090 änderst, dann ändert sich rein technisch gar nichts. Nur dass er eben auf 8090 lauscht. Bei Bridge gäbe es dann trotzdem die Weiterleitung, nur eben nicht von 8090 auf 8080, sondern von 8090 auf 8090. Was spricht eigentlich gegen den offiziellen Wordpress Container?

Korrekt. Sprichst du denn überhaupt von einer Wiederherstellung oder läuft nur ein Parity Check? Sicher? Liegt wirklich alles auf dem Cache, wie zb libvirt?

Das ist das Problem: NGINX_HTTP_PORT_NUMBER: Port used by NGINX for HTTP. Default: 8080 NGINX_HTTPS_PORT_NUMBER: Port used by NGINX for HTTPS. Default: 8443 In der Doku wird 80 auf 8080 verlinkt und 443 auf 8443: docker run -d --name wordpress -p 80:8080 -p 443:8443 Du machst es aber andersherum bzw hast vermutlich gedacht der Container lauscht auf 80 und 443. Dh du musst 8090 auf 8080 und 4390 auf 8443 verlinken. Dann würde es gehen. Oder du versuchst mit den beiden Variablen die Standardports zu ändern.

Hier in der Doku wird /bitnami und nicht /bitnami/wordpress verlinkt. Bitte alles mit Appdata cleanup löschen und noch mal versuchen. https://github.com/bitnami/bitnami-docker-wordpress-nginx docker run -d --name wordpress -p 80:8080 -p 443:8443 \ --env WORDPRESS_PASSWORD=my_password \ --network wordpress-tier \ --volume /path/to/wordpress-persistence:/bitnami \ bitnami/wordpress-nginx:latest

Das ist in jedem Fall dein Problem. Hast du mehrere Ethernet Interfaces der selben IP Range zugewiesen? Was gibt ifconfig zurück?

VMs im Array laufen zu lassen ist tödlich für die Performance. Kommt noch ein Parity Check dazu, kann man nur noch zuschauen und warten. Fazit: Du brauchst einen SSD Pool für die VMs Desweiteren solltest du eine XFS Reparatur für alle Disks durchführen. Dazu das Array im Wartungsmodus (Maintenance) starten, auf "Disk1" klicken und den Parameter entfernen. Steht aber auch im Hilfetext.

Keine Ahnung. Ich kenne den Fall nicht. Ich würde vermutlich erst mal nach "br0" suchen. Hier nachdem ich auf meinem Testserver den Docker-Dienst gestartet habe: Apr 15 16:57:59 Tower ool www[16287]: /usr/local/emhttp/plugins/dynamix/scripts/emcmd 'cmdStatus=Apply' Apr 15 16:57:59 Tower emhttpd: Starting services... Apr 15 16:57:59 Tower emhttpd: shcmd (654): /etc/rc.d/rc.avahidaemon restart Apr 15 16:57:59 Tower root: Stopping Avahi mDNS/DNS-SD Daemon: stopped Apr 15 16:57:59 Tower avahi-daemon[3751]: Got SIGTERM, quitting. Apr 15 16:57:59 Tower avahi-dnsconfd[3760]: read(): EOF Apr 15 16:57:59 Tower avahi-daemon[3751]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.178.67. Apr 15 16:57:59 Tower avahi-daemon[3751]: Leaving mDNS multicast group on interface lo.IPv6 with address ::1. Apr 15 16:57:59 Tower avahi-daemon[3751]: Leaving mDNS multicast group on interface lo.IPv4 with address 127.0.0.1. Apr 15 16:57:59 Tower avahi-daemon[3751]: avahi-daemon 0.8 exiting. Apr 15 16:57:59 Tower root: Starting Avahi mDNS/DNS-SD Daemon: /usr/sbin/avahi-daemon -D Apr 15 16:57:59 Tower avahi-daemon[16784]: Found user 'avahi' (UID 61) and group 'avahi' (GID 214). Apr 15 16:57:59 Tower avahi-daemon[16784]: Successfully dropped root privileges. Apr 15 16:57:59 Tower avahi-daemon[16784]: avahi-daemon 0.8 starting up. Apr 15 16:57:59 Tower avahi-daemon[16784]: Successfully called chroot(). Apr 15 16:57:59 Tower avahi-daemon[16784]: Successfully dropped remaining capabilities. Apr 15 16:57:59 Tower avahi-daemon[16784]: Loading service file /services/sftp-ssh.service. Apr 15 16:57:59 Tower avahi-daemon[16784]: Loading service file /services/ssh.service. Apr 15 16:57:59 Tower avahi-daemon[16784]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.178.67. Apr 15 16:57:59 Tower avahi-daemon[16784]: New relevant interface br0.IPv4 for mDNS. Apr 15 16:57:59 Tower avahi-daemon[16784]: Joining mDNS multicast group on interface lo.IPv6 with address ::1. Apr 15 16:57:59 Tower avahi-daemon[16784]: New relevant interface lo.IPv6 for mDNS. Apr 15 16:57:59 Tower avahi-daemon[16784]: Joining mDNS multicast group on interface lo.IPv4 with address 127.0.0.1. Apr 15 16:57:59 Tower avahi-daemon[16784]: New relevant interface lo.IPv4 for mDNS. Apr 15 16:57:59 Tower avahi-daemon[16784]: Network interface enumeration completed. Apr 15 16:57:59 Tower avahi-daemon[16784]: Registering new address record for 192.168.178.67 on br0.IPv4. Apr 15 16:57:59 Tower avahi-daemon[16784]: Registering new address record for ::1 on lo.*. Apr 15 16:57:59 Tower avahi-daemon[16784]: Registering new address record for 127.0.0.1 on lo.IPv4. Apr 15 16:57:59 Tower emhttpd: shcmd (655): /etc/rc.d/rc.avahidnsconfd restart Apr 15 16:57:59 Tower root: Stopping Avahi mDNS/DNS-SD DNS Server Configuration Daemon: stopped Apr 15 16:57:59 Tower root: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon: /usr/sbin/avahi-dnsconfd -D Apr 15 16:57:59 Tower avahi-dnsconfd[16793]: Successfully connected to Avahi daemon. Apr 15 16:57:59 Tower emhttpd: shcmd (663): /usr/local/sbin/mount_image '/mnt/user/docker/' /var/lib/docker 20 Apr 15 16:57:59 Tower emhttpd: shcmd (665): /etc/rc.d/rc.docker start Apr 15 16:57:59 Tower root: starting dockerd ... Apr 15 16:57:59 Tower kernel: Bridge firewalling registered Apr 15 16:57:59 Tower avahi-daemon[16784]: Joining mDNS multicast group on interface docker0.IPv4 with address 172.17.0.1. Apr 15 16:57:59 Tower avahi-daemon[16784]: New relevant interface docker0.IPv4 for mDNS. Apr 15 16:57:59 Tower avahi-daemon[16784]: Registering new address record for 172.17.0.1 on docker0.IPv4. Apr 15 16:58:00 Tower avahi-daemon[16784]: Server startup complete. Host name is Tower.local. Local service cookie is 995490093. Apr 15 16:58:00 Tower rc.docker: created network br0 with subnets: 192.168.178.0/24; Apr 15 16:58:01 Tower avahi-daemon[16784]: Service "Tower" (/services/ssh.service) successfully established. Apr 15 16:58:01 Tower avahi-daemon[16784]: Service "Tower" (/services/sftp-ssh.service) successfully established. Dann dürfte irgendwas defekt sein. Sei es die Installation oder der Stick selbst. Ich würde den Stick sichern und neu installieren und das Config Verzeichnis wiederherstellen. Normal ist das jedenfalls nicht was du da hast.

Nein, sollte da sein, denn du hast es aktiviert: Hast du den Server schon mal neu gestartet? Ansonsten mal die Logs checken.

Das gibt es nur, wenn man das Netzwerk "br0" auswählt.

Du hast in den Netzwerkeinstellungen das Bridging abgewählt. Dadurch wird das br0 Netzwerk entfernt, was deine Container verwendet haben.

Deswegen nutzt man nicht /dev/sdX sondern /dev/disk/by-id/<ID>

Ich spreche von powertop oder selbst zugewiesenen Stromsparregeln wie AHCI DIPM. Dadurch geht der Slot selbst schlafen.

Interface rules missing until network-rules.cfg has been created manually:

Um welche Hardware geht es? Energiesparmechanismen aktiv? Sieht man sie mit lsblk?

Dann ist dein Problem vermutlich einfach die Strahlung. Die funken ja so ziemlich alle auf 2.4GHz. Selbst die Störungsstrahlung von USB3 Buchsen und SSDs. Am besten mit Verlängerungen arbeiten.

Plex braucht eine GPU. Eine der VMs auch?

Beides würde die Fehler beheben (Parity Check mit ausgewählter Korrektur). Egal Jo. Ist ganz normal XFS (oder BTRFS, je nachdem was du ausgewählt hast). Paragon hat wohl ein Tool um XFS in Windows zu öffnen, aber am einfachsten ist denke ich ein Ubuntu Bootstick bzw ein Unraid Stick mit Testlizenz. Wenn die Hardware nicht mitspielt ist das echt nervig. Selbst irgendwas flashen, alte Hardware, kein ECC RAM... Da kann schon einiges an Fehlern resultieren.