mgutt

Das zeigt an wie voll das docker.img ist oder wenn du Directory nutzt, wie voll der Datenträger ist, wo der Ordner liegt.

Keine Ahnung warum, aber die Logs in dem ZIP sind unvollständig. Es gibt eine syslog.txt von 04 bis 06 Uhr vom 22.08 und eine von 13 bis 14 Uhr vom 21.08. Und dafür, dass die so abgeschnitten sind, enthalten sie gefühlt Millionen Fehler. Das hier flutet zB die Logs: Aug 21 14:19:38 myunraid ntfs-3g[17754]: ntfs_attr_pread error reading '/Medien/Filme UHD/*/*.mkv' at offset 6188072960: 4096 <> -1: Input/output error Aug 21 14:19:38 myunraid ntfs-3g[17754]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error und das: Aug 22 06:14:39 myunraid emhttpd: error: share_luks_status, 5995: Operation not supported (95): getxattr: /mnt/user/Transcode Aug 22 06:14:39 myunraid emhttpd: error: share_luks_status, 5995: Operation not supported (95): getxattr: /mnt/user/appdata Aug 22 06:14:40 myunraid emhttpd: error: share_luks_status, 5995: Operation not supported (95): getxattr: /mnt/user/Plex Da syslogs sensible Daten enthalten können, wenn man sie selbst kopiert, würde ich vorschlagen, dass du die syslog mal komplett auf den USB Stick kopierst, da runterlädst und mir per PN zusendest: cp /var/log/syslog /boot/logs/syslog_copy.txt Tatsächlich fehlen mir da die Erfahrungswerte. Im Array ist das der Fall. Da erscheint dann "Missing". @ich777 Sollten beim Pool fehlende Disks nach einem Reboot nicht als "Missing" angezeigt werden? Wenn die Ursache für das "Missing" nur ein Sync-Fehler ist, dann erscheint zwar "Missing" als Benachrichtigung, aber damit ist nicht gemeint, dass die Disk fehlt, sondern, dass das BTRFS RAID nicht mehr vollständig ist, da eine der beteiligten Disks falsche Daten zurückgeliefert hat. Dh eigentlich wurde sie aus dem RAID rausgeworfen. Ich bin nicht sicher ob Unraid solche Fälle in der GUI korrekt darstellt. Die Frage ist auch ob sie wirklich komplett rausgeworfen wurde oder ihr nur bei bestimmten Sektoren nicht vertraut wird. Auch hier fehlen mir die Erfahrungswerte um das genauer bewerten zu können. @JorgeB Do you know why his Diagnostic ZIP does not include the full syslog? It includes only two syslog files which are cut after a short period of time (2 hours from two different days).

Ebenfalls im Guide ergänzt: Wer weiter auf BTRFS setzt, der hat evtl das Problem, dass er die Zugriffe auf /var/lib/docker/btrfs/subvolumes keinem Container zuordnen kann. Dann diesen Befehl ausführen: for f in /var/lib/docker/image/btrfs/layerdb/mounts/*/mount-id; do echo $(dirname $f | xargs basename | cut -c 1-12)' (Container-ID) > '$(cat $f)' (BTRFS subvolume ID)'; done && docker ps -a

Check deine Logs. Da steht drin worauf Unraid wartet. Kann es sein, dass du ein rsync oder rclone Script im Hintergrund aktiv hattest? Falls ja: https://forums.unraid.net/topic/112502-use-the-stop-file-to-kill-processes-which-prevent-shutdown/ while [ $(pkill -xc rsync) != "0" ]; do logger -t stop "rsync killed"; sleep 2; done while [ $(pkill -xc rcloneorig) != "0" ]; do logger -t stop "rclone killed"; sleep 2; done

Dann würde er die Docker und VM Tabs nicht sehen. Startet man aber das Array und hat es noch nicht formatiert, dann ist das tatsächlich möglich. Siehe auch hier: https://forums.unraid.net/topic/112755-docker-service-failed-to-start/?tab=comments#comment-1026340

Stell den Share beim Cache auf "Yes" und starte den Mover. Oder ist der bereits auf "Yes"? Dann starte den Mover. Wobei die Backupdatei ja eh kaputt sein dürfte, soll heißen, lösch die einfach. Um solche Probleme zu verhindern, solltest du auf den Cache Pool klicken und einen Minimum Free Space hinterlegen, der größer ist als das größte Backup von Acronis. Falls das zu viel ist, solltest du Acronis auf einen Share schreiben lassen, der keinen Cache nutzt (No). Außerdem sollte man keine Shares auf "Only" stellen. "Only" kann bei voller SSD nicht aufs Array ausweichen. Nutze stattdessen "Prefer". Aber das hilft wie gesagt nicht, wenn die Backupdatei schlicht zu groß für die SSD ist. Wachsende Backupdateien sind für den Cache ein Problem, da er nicht absehen kann wie groß die Datei wird (daher ist Minimum Free Space so wichtig) und während dem Schreiben kann eine Datei nicht aufs Array verschoben werden. Bitte beachte außerdem, dass dein Backup-Konzept scheinbar nicht gegen Ransomware hilft.

Jede Wette, dass du vergessen hast das Array zu formatieren (auf Main runterscrollen und bestätigen).

Sounds like you are using ASPM (NVMe) or ALPM (SATA). This means, because of my code your SSD went the very first time in sleep state and this kills your BTRFS RAID (should not happen = nvme firmware or bios bug). Check your logs for errors.

Hast du auch wirklich nur "subdomain" und nicht "subdomain.duckdns.org" hingeschrieben? Du kannst den Link übrigens auch im Browser öffnen. Auch dann muss deine IP aktualisiert werden. Also zB so: https://www.duckdns.org/update?domains=foobar,foobaz&token=dein-langer-token&ip=123.123.123.123 Auf die Art bekommst du vielleicht eher raus wo das Problem ist.

Erstmal müssen wir deine Logs sichten. Wir brauchen jetzt also deine Tools > Diagnostics ZIP.

I updated the above code. Now it automatically syncs the RAM-Disk every 30 minutes. You can change it in the Go file to a lower value if you like to. The location of your docker.img is irrelevant. You can even use a docker directory, which is a method I recommend as it reduces write amplification.

Nein, das funktioniert dann nicht mehr. Das selbe gilt natürlich auch für /mnt/cache/appdata, womit man die CPU ja ebenfalls entlastet. Damit nun andere Shares, die auf den selben Cache Pool schreiben können, diese nicht vollschreiben und damit den Betrieb von Docker gefährden, sollte man beim Cache Pool einen Minimum free space definieren: Dieser Wert gilt nur bei /mnt/user, während man mit /mnt/cache weiterschreiben kann. So hat /mnt/cache/system/docker und /mnt/cache/appdata noch genug Platz bis der Mover die SSD eh wieder leert. Ich habe übrigens 100GB eingestellt, da ich beim parallelen Rippen von mehreren Blu-Rays manchmal 70 bis 90GB "nachschreibe". Blu-Ray Rips sind bekanntlich große MKV Dateien und wie groß die schlussendlich werden, kann Unraid natürlich nicht wissen und die Minimum Free Space Regel greift immer nur beim Erstellen der Datei. Soll heißen wenn von 1000GB gerade 899GB belegt sind, könnte ich theoretisch einen 500GB großen Rip hochladen und er würde, obwohl er nicht auf die SSD passt, auf dieser erstellt werden (und dann im Fehler enden). Erst wenn 900GB belegt sind, werden neue Dateien direkt auf dem Array erstellt.

Wenn du keinen Server Absturz / Hard Reset hattest, dann hast du warum auch immer ein Verbindungsproblem oder Defekt bei einer VM NVMes. Der erste Schritt wäre ein Scrub um die Fehler zu korrigieren. Im nächsten Schritte solltest du deine syslog nach "nvme" bzw "btrfs" sichten. Da müssen Fehler zu sehen sein. Solche Fehler haben immer wieder mal User. Die Ursachen sind da extrem unterschiedlich. Manche hatten defekte NVMes, obwohl neu, andere defekte M.2 Slots, obwohl neues Board, andere vermuteten Überhitzungsprobleme, wieder andere haben Probleme mit ASPM und mussten das im BIOS deaktivieren usw. Es gibt auch User, die schlussendlich auf einzelne XFS Laufwerke gewechselt haben und regelmäßig die Daten ins Array sichern, weil sie sonst keine Lösung gefunden haben. Keine Ahnung ob das auch manchmal vom Board abhängt. An Unraid liegt das jedenfalls nicht. BTRFS macht da einen sauberen Job und meldet ganz klar, wenn die gelesenen Daten einfach nicht mehr stimmen. Und das aufs Bit genau.

Solange du von Disk zu Disk oder Share zu Share kopierst, nein. Wie die Cache-Einstellung und die Pfade zusammenhängen: Cache Yes oder Prefer Öffnet man den Pfad /mnt/user/Virtualization, sieht man den Inhalt von /mnt/vms_nvme/Virtualization und /mnt/diskX/Virtualization Cache Only Öffnet man den Pfad /mnt/user/Virtualization, sieht man nur den Inhalt von /mnt/vms_nvme/Virtualization, selbst wenn es Dateien in /mnt/diskX/Virtualization geben sollte. Cache No Öffnet man den Pfad /mnt/user/Virtualization, sieht man nur den Inhalt von /mnt/diskX/Virtualization, selbst wenn es Dateien in /mnt/vms_nvme/Virtualization geben sollte. Nein wird er nicht, weil das normalerweise nicht passiert. Aus dem Grund hat zB @ich777 beim Krusader Container nur /mnt/user hinterlegt. Und alle, die Container anbieten wissen das. Es kann also eigentlich nur zu diesem Problem kommen, wenn der Anwender die Konfiguration eines Containers verändert oder in der Kommandozeile unterwegs ist und eigentlich sollte man sowas nur machen, wenn man auch weiß was man tut. Ansonsten kann man sich ja eigentlich denken, dass es keine gute Idee ist eine Datei mit sich selbst zu überschreiben.

Übrigens, die P2 wurde heimlich auf QLC umgestellt: https://www.computerbase.de/2021-08/crucial-p2-ssd-wechsel-auf-qlc-nand-senkt-leistung-in-der-praxis-massiv/

Du musst dir wirklich Gedanken über Backups machen.

Shell? ^^ Stand das BIOS auf UEFI? Ich denke das kommt nur wenn CSM / Legacy deaktiviert ist.

War nur eine Idee ob eine VM evtl die NVMe als Hardware nutzen will. Mach mal bitte das mit allen Pools: btrfs dev stats /mnt/<name-des-Pools>

Du kannst in der FB auf Custom umstellen und dann mehrere URLs hinterlegen. Das meinte ich mit Leerzeichen: https://www.ip-phone-forum.de/threads/7490-dyndns-mit-einem-zweiten-host.310630/#post-2435204 Der Aufbau der DuckDNS URL ist so: https://www.duckdns.org/update?domains=${domain}&token=${token}&ip=${ipv4}&ipv6=${ipv6} Einfach entsprechend mit den Fritz!Box Variablen füllen. Den Container brauchst du dann nicht.

Die Parity enthält keine Dateien, sondern ein Rechenergebnis, das sich aus den Inhalten aller Platten ergibt. Eine Art "Quersumme". Die Parity wird live aktualisiert. Also wenn du Dateien von irgendeiner Platte löschst, wird auch die Parity im selben Moment aktualisiert und enthält diese Löschung. Die Parity hilft also nicht, wenn Dateien gelöscht werden, sondern sie hilft nur, wenn eine Platte kaputt geht. Eventuell hilft dir diese Erklärung das besser zu verstehen: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?tab=comments#comment-1021986

Ja halt SSD leer machen, aber wie das geht weißt du ja denke ich. Ansonsten gibt es da nichts zu beachten. Entweder sie geht oder nicht. Ich hatte mal die IronWolf probiert, aber da bootet das Board dann einfach nicht mehr.

Passiert das auch, solange die VMs nicht laufen?

Da da Intel steht, gehe ich mal von der Firmware in der CPU aus, also ein Microcode Update oder so. Das kann schon durchaus wichtig sein, aber ob es mit dem RAM zusammenhängt?! Du solltest einfach die Shell selbst auswählen. Das geht doch bestimmt, wenn du beim Booten in das Boot-Menü wechselst. Also nicht BIOS, sondern F10 oder F12 oder was das BIOS auch immer verlangt. Ansonsten einfach den USB Stick ziehen. Ohne Datenträger kommt doch dann die Shell oder nicht?

Ging das nicht mit Leerzeichen? Du kannst übrigens auch in Unraid den DuckDNS Container installieren. Der kann das auch (wobei die Fritz!Box wirklich nur 1x die URL aufruft, wenn sich die IP ändert).

Wenn das außerhalb der Unraid Welt auch ohne geht.... naja, aber wenn man sich erst mal daran gewöhnt hat ^^