mgutt

Ich denke nicht, dass das geht, weil das ja die HTTPS Sicherheit untergraben würde. Einfache Lösung: Gültiges SSL Zertifikat. Siehe zB hier: Weiter unten in dem Thread ist dann auch noch ein alternativer Vorschlag mit einem Wildcard-Zertifikat: https://forums.unraid.net/topic/115369-nginx-ssl-zertifikat-https-für-lokal-genutzte-domainscontainer/#comment-1143423 Auf die Art kann man dann unraid.example.com im Proxy auf unraidip:80 zielen lassen und hat Unraid selbst https verschlüsselt.

Shouldn't this default error avoid errors? skip_error_no_such_file_or_directory=1

Ich denke man darf neben dem Eigenverbrauch auch nicht den Widerstand vergessen. Längere Leitungslänge plus evtl schlechtere Verbindungen durch mehrere Stecker, können bei 5V durchaus viel ausmachen. Aus dem Grund hat das Corsair RM550x denke ich auch irgendeine Elektronik auf der Steckerseite vom Mainboard. Ich hatte schon vermutet, das die da erst 3.3V wandeln, aber wissen tue ich es nicht.

Jetzt hätte ich gerade nmap gebraucht. Aber gibt es gar nicht ^^

Ok, dann versuch mal so: dd if="$(find /mnt/disk1 -type f 2>/dev/null | head -n 1)" of=/dev/null count=1 iflag=direct In dem Fall sucht "find" nach einer Datei und genau aus dieser werden die ersten 512 Bytes gelesen. Und iflag erzwingt wie gehabt, dass der RAM genutzt wird und da wir /mnt/disk1 als Quelle nutzen, hoffe ich, dass das diesmal den Counter hochsetzt.

Ja der hat leider mal in einem Video gesagt, dass man Nerd Tools und alle Pakete davon installieren soll. Ziemlicher Unsinn, da die Pakete kein Mensch alle braucht und teilweise gar nicht mehr mit unRAID 6.10 kompatibel sind. Dann hast du in einem Screenshot ein leeres Dashboard gezeigt. Das passiert sehr häufig, wenn der USB Stick oder der RAM voll läuft (was im normalen Betrieb nicht passiert)

Nur eine Idee. Kann man bei AMD die PCIe Version des Chipsatzes auf 2.0 reduzieren? Bzw allgemein alles auf 2.0?

Das wirst du denke ich nur manuell über die Kommandozeile lösen können.

Ist diie IP oder die Namensauflösung gesperrt?

Bitte kein RAM Ballooning einstellen. Min und max jeweils identisch einstellen! Siehe auch:

So, der Server ist wieder auf einem guten Weg. Morgen kommen dann die letzten Säuberungen. Das war wirklich eine harte Nuss und ich muss sagen, dass Lucky Backup echt keiner für Docker nutzen sollte, der das Konzept von appdata nicht verinnerlicht hat. Hier kam dann noch zum Tragen, dass das Ziel eine NTFS Platte war, die keine Linux Permissions kennt. Also so ziemlich alle Container waren vom Prinzip hinüber. Aber BTRFS hat mich mal wieder positiv überrascht und ich denke ich werde meine einzelne NVMe auch auf BTRFS umstellen. Ich konnte nämlich mit btrfs restore, die zwischenzeitlich als NTFS formatierte SSD, vollständig wiederherstellen. Zumindest die Dateien, die vom Mover nicht auf das Array verschoben wurden. Es war nicht mehr erkennbar was passiert war, aber zb Teile vom MariaDB Container wurden wohl vom Mover ins Array verschoben, waren da aber leider nicht mehr auffindbar. Und man hat wieder mal gemerkt, dass die unRAID GUI dringend diese Verbesserung benötigt: Das war nämlich mit ein Grund für die Probleme.

Ich tippe auf 10W nachdem mal meine ich jemand bei einem 4-Bay Gehäuse 5W Eigenverbrauch gemessen hat. Wobei das mit einem kleinen Lüfter war... Ja muss auf jeden Fall mal jemand ausmessen.

Ich habe das Kommando angepasst: dd if=/dev/sde of=/dev/null bs=512 count=1 oflag=direct Durch oflag=direct wird RAM Caching umgangen.

Du hast zahlreiche Fehler in dem Dateisystem. Ich vermute, dass BTRFS versucht diese während dem Mount zu beheben, dafür dann aber kein Platz da ist. Wie hast du denn die Disk hinzugefügt? Ich sehe in den Logs nur sdag sdah sdai sdaj sdak, sdal und sdk, also 7 Disks und keine 8.

Übrigens kannst du auch das knicken. Der Cache ist als eigenständiges Laufwerk gedacht. Dauerhaft Daten ins Array zu verschieben ist das selbe als hätte man keinen Cache (aus Sicht der Performance-Optimierung). Daher entweder RAID1 oder einzelne NVMe, die regelmäßig gesichert wird.

Um den Cache wirst du nicht herum kommen. UD ist nur ein Plugin und kein direkter Bestandteil von unRAID. Daher ist es auch gar nicht vorgesehen da Shares abzulegen. Müsste man alles von Hand machen.

SSD Cache Pool und danach das machen: https://forums.unraid.net/topic/120495-solved-nextcloud-extrem-langsam/ Ja Nein Nein USB Backup Platten oder Netzlaufwerke mounten

Steht hier im Abschnitt "commands": https://forums.unraid.net/topic/98070-reduce-power-consumption-with-powertop/

Was zeigt Shares > Appdata > Inhalt anzeigen > Location? Welche Cache Einstellung hat Appdata? Spielt keine Rolle. Die Docker sind weg, weil das docker.img weg ist. Man kann aber jeden Docker jederzeit wieder starten. Wichtig ist allerdings, dass appdata die Container-Daten enthält. Das selbe gilt übrigens auch bei den VMs. Ist das libvirt.img weg, zeigt unRAID die VMs nicht mehr an. Spielt aber auch keine Rolle, wenn man die vdisks Images noch hat. Also was enthalten die jeweiligen Festplatten? Und nein, du schaust nicht über irgendeinen Client, sondern direkt über die WebGUI was da jeweils drauf ist. Das verstehe ich nach wie vor nicht. Sei mal dahingestellt, dass der Mover nichts verschieben kann, aber warum ist dann die SSD leer? Die hast du doch dann neu formatiert oder wie?! Wie kamst du eigentlich zu der Annahme, dass der Mover nach x Tagen immer noch arbeitete?

Ich dachte mcelog unterstützt kein AMD?! https://forums.unraid.net/topic/72419-amd-processor-family-21-mcelog-does-not-support-processor/

Wie jetzt. Also doch erst effizient ab 6.1 ?!

Jetzt wo du es sagst. Ich erinnere mich ^^

Im Plex Forum lese ich viel von nervigen Bugs (Farbfehler usw) beim Transcodieren. Also da ist noch einiges im Argen mit dem Treiber. Es ist auch kein offizieller Container verfügbar, sondern von einem User, der den dann angepasst hat. Siehe: https://forums.plex.tv/t/got-hw-transcoding-to-work-with-libva-vaapi-on-ryzen-apu-ryzen-7-4700u/676546/1 https://forums.plex.tv/t/feature-request-add-support-for-amds-video-core-next-encoding/226861 Liest sich im Grunde genauso gruselig wie in deinem Link ^^ Wenn bei einem RAID1 Pool zB eine NVMe die Biege macht, sollte ja in der Theorie die zweite weiter gehen. Vermutlich crasht aber der Server oder das BTRFS RAID ist einfach kaputt. Kennen wir ja. Jedenfalls hast du dann ja immer noch die Möglichkeit vor dem Mounten das kaputte Device zu entfernen oder die noch heile NVMe zu formatieren und alles aus deinem Backup wiederherzustellen, bevor du das Array startest. Dass der Server bei zwei Pools eine geringere Downtime hat, kann ich bei deinem Konzept nicht erkennen?! Tatsächlich wäre die Downtime so geringer: Zwei Pools mit jeweils einer NVMe. Die zweite lässt du jede Nacht bei gestoppten Docker und VM 1:1 syncen. So könntest du jederzeit ohne große Ausfallzeit auf den Stand von letzter Nacht zurück, in dem du den Master-Pool löschst und den Backup-Pool umbenennst. Damit hätte man aber nicht den Vorteil eines permanenten Schutzes eines RAID1.

Dann versuch es mal mit Einzelkommandos statt powertop auto tune. Kein Ahnung warum auto tune die eine Platte überspringt. Eventuell erkennt powertop eine Inkompatibilität?! Teste es wenn auf jeden Fall mit gestopptem Array.

Nein kann man nicht, weil Unraid nur den root-User auf seine GUI lässt. Der Weg über den Docker mit deinem Root-Passwort ist so, als würdest du deine Haustür aufschließen und ein Fremder hält sie den ganzen Tag auf, damit der Postbote seine Pakete in den Flur stellen kann. Das kann gut gehen, muss aber nicht. Wenn überhaupt sollte man sowas meiner Ansicht nach als Plugin + Docker umsetzen. Ein Plugin liest dann die Infos über entsprechende Shell-Kommandos aus und schreibt sie an Ort X und der Docker nutzt diesen Ort und stellt die Infos über eine Web-API bereit. Das wirkt zwar komplexer, ist es aber eigentlich nicht, weil man kein Programm schreiben muss, was sich auf einer GUI anmeldet und sicherer wäre es sowieso.