mgutt

Ganz normal in den syslogs

Poste mal die Logs vom Parity Check

Dh der hat den gar nicht bis zum Ende durchgeführt?! SMART Extended Self-test Log Version: 1 (1 sectors) Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 20% 15301 6244436384 # 2 Extended offline Aborted by host 90% 15295 - Oder hast du den abgebrochen?

Für VMs gibt es aber noch eine Einstellung:

Der ist stark genug. Der Zusammenhang leuchtet mir nicht ein. Insbesondere weil Wireshark ja im RAM und nicht auf den HDDs läuft. 🤔

Naja Array stoppen oder bei UD unmounten. Das ist das selbe.

Welche Treiber? Du meinst Plugins? Sollte keine Auswirkungen haben. Weil man kann ja jedes Plugin egal mit welcher Hardware installieren. Wobei ich nicht weiß ob bereits gesetzte Einstellungen da was ausmachen. Aber probieren geht über studieren 😁

Da die Parität angepasst wurde, werden die betroffenen Sektoren mit den selben korrupten Daten überschrieben.

Das kann man nicht auf die Art ermitteln. Du kannst nur die Dateien mit denen aus einem Backup vergleichen. Oder wir versuchen an Hand deiner Logs die IDs der Sektoren zu ermittelt und an Hand derer die betroffenen Dateien.

Wozu braucht der denn die Zertifikate? Läuft OnlyOffice über eine separate Domain?! Das kann nicht gehen, weil du keinen Let's encrypt (LE) Container verwendest (welcher das auch immer sein soll), sondern NPM. Ich weiß aber auch nicht was das bringen soll, weil die LE Zertifikate eh nur 90 Tage gültig sind. Dann müsste man ja alle 90 Tage das Zertifikat kopieren?!

Puuh ist mir zu hoch. @JorgeB So you know why this user is able to manually mount an encrypted disk, but if he assigns it after "New Config" to the array, they are marked as "Unmountable" although the correct password has been obtained? Side note: The user has a new HBA and the HDD ids changed by that. That's the reason why he tried it with a new config.

Naja vermutlich wie bei USB. Der Treiber trennt die Verbindung zur Disk und man kann sie rausziehen. Zieht man einfach so, während noch geschrieben wird, können Daten verloren gehen.

Der Inhalt 2er Sektoren steht auf Pending, weil die Sektor-Checksumme nicht mehr zu den Daten passt. Dadurch hat der Parity Check parallel auch die Parität an die "neuen" Daten angepasst. Aus dem Grund sollte man die Einstellung "Write corrections to parity disk:" deaktivieren. Denn die Parität kann sich vom Prinzip nur ändern, wenn eine Disk kaputte Sektoren hat. Jedenfalls steht noch nicht fest, dass der Sektor verloren ist, weshalb er noch auf "Pending" steht. Erst wenn ein erweiterter SMART Check einen Schreibtest macht, wird SMART den Sektor entweder freigeben oder aufgeben und stattdessen einen Ersatzsektor verwenden. Das ist dann der Reallocated Count. Für die Gesundheit der Platte ist es auf jeden Fall ein schlechtes Zeichen. Ich bin da sehr empfindlich und würde direkt tauschen. Ja, von 2 Sektoren. Ein Sektor ist üblicherweise 512 Bytes groß (siehe unten). Es können wenn "nur" wenige oder keine Dateien betroffen sein, aber ja wenn es von Dateien genutzte Sektoren sind, dann sind diese korrupt. root@Tower:~# for i in /dev/sd?; do echo $i; smartctl -a $i | grep -i physical; done /dev/sda /dev/sdb Sector Size: 512 bytes logical/physical /dev/sdc Sector Size: 512 bytes logical/physical

Am besten beschreib mal im iobroker thread wie du das Backup gemacht hast und wie du es wiederhergestellst. Dann wird Andre (der Entwickler von iobroker) sicher was dazu sagen können.

Appdata auf der Platte? Irgendwelche Ordner/Shares von der Platte in Containern in Benutzung?

Dann hast du die SSD erst eingebaut als Docker schon lief. Docker auf No stellen und den Mover starten. Dann ist alles auf der SSD. Nein. Was aber hilft ist das manuelle Ändern von Container-Pfaden von /mnt/user in /mnt/cache. Aber Achtung. Das hebelt die Prefer-Einstellung aus. Man sollte das also nur in Kombination mit min-free-space nutzen, damit die Container nicht crashen, wenn man sehr viele Dateien auf den Server hochlädt. Auch darf man Docker dann nicht starten, wenn man zb die SSD zb gegen eine größere ersetzen will und die Dateien per Cache yes erstmal auf das Array verschiebt, denn sonst installieren sich die Container komplett neu / es entstehen Inkonsistenzen. Ich empfehle diesen Tweak daher nur erfahrenen Nutzern. Was es bringt? Nun Nextcloud wird locker 100x schneller, wenn MariaDB direkt über /mnt/cache zugreift. Also lohnt sich schon, aber es ist eben mit gewissen Fallstricken verbunden. Ich muss dazu Mal ein Tutorial machen ^^

Ich habe noch Power on auf always gesetzt. So kann ich den Server per smarter Steckdose starten oder wenn warum auch immer die USV ausfällt, geht der Server nach Stromzufuhr wieder an.

Der Standard ist "virtio-net". Der Netzwerk-Adapter is langsamer als "virtio". Eventuell hat das ja auch einen Einfluss auf das RAM-Caching. Als letztes Mittel könnte man noch eine RAM-Disk erstellen, aber erstmal würde ich prüfen ob es nicht auch "automatisch" geht, wie es ja normalerweise der Fall sein sollte.

Which is normal as you have installed two PCI cards which do not sleep (as the command causes a crash) and the full C-State support for AMD is not available by now (needs Unraid 6.11): https://forums.unraid.net/topic/121551-erlaubt-der-neue-linux-kernel-stromsparende-amd-server/#comment-1140416 Test which card causes the problem (remove one by another) and replace it. Or maybe test the command through Ubuntu to verify if the problem is only present in Unraid. Test each component separately. Which means, measure without all HDDs and PCIe cards, then measure only with the 2.5G card, then measure with the SATA card... until you know which component is the reason for your high power consumption. If your power consumption is high even without all the cards and disks, then your mainboard+CPU is the problem, which wouldn't surprise me as its AMD, which does not allow efficient builds and the Athlon is only produced in an inefficient 14nm node: https://en.wikichip.org/wiki/amd/athlon/200ge As an example, Synology's Ryzen NAS has one of the worst power consumptions of all models: https://www.computerbase.de/2022-06/synology-ds1522-nas-amd-ryzen-test/3/#abschnitt_lautstaerke__leistungsaufnahme:~:text=Dauereinsatz zu Buche.-,Leistungsaufnahme,-HDDs im Ruhezustand But even Intel lost their focus on power efficiency after releasing the 10th gen and it became even worse with the 11th gen. The most efficient builds are still only possible with with 8th and 9th gen. And of course you should never add cards if the same feature is available on a motherboard. So your perfect board would be the Gigabyte W480M (8x SATA, 2x M.2 and 1x 2.5G ethernet port), which allows a 10 to 15W build.

Der Fehler liegt an dem Wert in dieser Variable: Das Wort "url-base" gegen "/" ersetzen: und der Container läuft. Siehe auch: https://github.com/linuxserver/docker-booksonic-air/issues/3 Dh der von @linuxserver.io vorgegebene Wert ist falsch. Leider konnte ich nicht herausfinden, wo Linuxserver.io seine Templates liegen hat, sonst hätte ich eine Korrektur gepostet, aber ich habe bereits im Support-Thread danach gefragt: https://forums.unraid.net/topic/40407-repo-linuxserverio-docker-repo/

Where is the location of the Unraid container templates of @linuxserver.io? I want to create a pull request for the Booksonic-Air template.

ioBroker macht gerne mal bei der Wiederherstellung Probleme. Das liegt aber auch nicht an Unraid, sondern an ioBroker. Erst die Tage wieder davon gelesen: https://forums.unraid.net/topic/101016-support-buanet-iobroker/?do=findComment&comment=1144905 Da wäre dann eben auch die Frage was bei ioBroker daneben geht. Also was sagen die Logs.

Your SATA expansion card and evern maybe the ethernet port: https://forums.unraid.net/bug-reports/stable-releases/pci-power-control-auto-for-unused-ethernet-device-kills-server-r2013/ Verify it by executing the commands on the first post one by another until the server crashes (powertop executes the same commands). Please don't start the array while testing, else it would force a parity check after the crash.

In dem Thread gibt es diverse Tipps, wie man hinter den eigentlichen Fehler kommt: https://forums.unraid.net/topic/110245-support-nginx-proxy-manager-npm-official/#comment-1011152:~:text=Debug Server Errors 5xx Ich fasse die wichtigsten Punkte noch mal auf Deutsch zusammen: 1. Schritt wäre zu prüfen ob man NPM erreichen kann. Das geht einfach in dem man seine öffentliche IPv4 im Browser über "http" öffnet: http://1.2.3.4 Dann MUSS man die Willkommensseite von NPM sehen können: 2. Nun prüfen wir ob NPM in der Lage ist den Ziel-Container zu erreichen. Man startet die Konsole von NPM: Und führt folgenden Befehl aus: curl -sS http://container_ip:container_port >/dev/null && echo "Container is reachable" Wenn zB "curl: (7) Failed to connect to 192.168.178.10 port 32400: No route to host" erscheint, dann kann NPM den Container nicht erreichen. Nach diversen Support-Fällen in dieser Richtung weiß ich, dass der häufigste Grund für diesen Fehler ist, dass zB NPM im br0 Netzwerk und der Ziel-Container zB im host-Netzwerk läuft. Docker erlaubt diese Konstellation nicht, weshalb die Unraid-Entwickler einen Workaround in den Docker-Einstellungen anbieten: Die Alternative dazu ist, dass man alle Container nur in br0 oder alle nur in Host betreibt.