February 26, 20251 yr hallo zusammen, einige meiner docker Container starten nach dem update auf unraid 7.0.1 nicht mehr: Error response from daemon: open /var/lib/docker/containers/638ade7f1161a7a036b4497abbf9bb03779f456b2db58b99364c34470555816a/638ade7f1161a7a036b4497abbf9bb03779f456b2db58b99364c34470555816a-json.log: read-only file system hat jemand eine Lösung für dieses Problem? Danke, velvet
February 26, 20251 yr Community Expert 37 minutes ago, velvet said: einige meiner docker Container starten nach dem update auf unraid 7.0.1 nicht mehr: Error response from daemon: open /var/lib/docker/containers/638ade7f1161a7a036b4497abbf9bb03779f456b2db58b99364c34470555816a/638ade7f1161a7a036b4497abbf9bb03779f456b2db58b99364c34470555816a-json.log: read-only file system hat jemand eine Lösung für dieses Problem? Hast Du noch einmal (also in Summe 2 mal) neu gestartet? Starten sie wieder, wenn Du auf 7.0.0 zurück gehst? Ist Dein USB Stick read only? Hat sich bei dem Pool, den der Docker vermutlich nutzt etwas dahingehend verändert? Hast Du das Changelog gelesen? Könnte Dein unbenannter Docker/Container etwas mit den dort erwähnten Veränderunegn für Docker zu tun haben? "As of this release, starting such containers has been disabled. To proceed, disable the Tailscale integration for containers in Host mode or change the Network Type to Bridge or "Custom: eth0/bond0/br0."" Edited February 26, 20251 yr by DataCollector
February 26, 20251 yr 56 minutes ago, velvet said: hat jemand eine Lösung für dieses Problem? read only deuet meist auf volles oder sogar eher defektes Dateisystem hin für dein Docker Image / Directory daher am Besten mal ne diagnostics <<click<< anhängen
February 26, 20251 yr Author ist mit dem update passiert: unter 6.12.15 ca. 15 docker Container - keine Probleme update von 6.12.15 auf 7.0.1 7.0.1 soweit alles ok bis auf das docker ready only problem. Nun bin ich wieder zurück auf 6.12.15 - keine Probleme, docker wieder ok. /velvet
February 26, 20251 yr 7 minutes ago, velvet said: Nun bin ich wieder zurück auf 6.12.15 - keine Probleme, docker wieder ok. liegen deine Dockers zufällig auf einer zfs Platte ? wenn ja, changelogs auch gelesen ? da du anscheinend deine diags nicht zeigen möchtest, Alternativ, bleib bei 6.12 dann
February 27, 20251 yr Author 10 hours ago, alturismo said: liegen deine Dockers zufällig auf einer zfs Platte ? wenn ja, changelogs auch gelesen ? da du anscheinend deine diags nicht zeigen möchtest, Alternativ, bleib bei 6.12 dann nein, alles unter xfs, kein zfs! welche files aus dem diag zip sind den in meinem fall relevant? ich kann diese gerne zur Verfügung stellen. aktuell bin ich wieder auf 6.12 danke, velvet
February 27, 20251 yr Community Expert 4 hours ago, velvet said: welche files aus dem diag zip sind den in meinem fall relevant? ich kann diese gerne zur Verfügung stellen. Da hier unspezifisch gesucht werden muß: (fast) alle. Und auch dann ist kein Erfolg/Lösung garantiert.
February 27, 20251 yr Author On 2/27/2025 at 12:44 PM, DataCollector said: Da hier unspezifisch gesucht werden muß: (fast) alle. Und auch dann ist kein Erfolg/Lösung garantiert. hoffe es hilft! vielen dank! /velvet Edited February 28, 20251 yr by velvet
February 27, 20251 yr 2 hours ago, velvet said: hoffe es hilft! vielen dank! mit der funktionierenden 6.12.15 er jetzt wohl eher nicht da ja kein Fehler vorliegt, daher wäre dies mit der 7er besser gewesen, beim nächsten mal dann.
February 27, 20251 yr 2 hours ago, velvet said: hoffe es hilft! vielen dank! im previous log sieht man zumindest wahrscheinlich einen Auslöser, btrfs Feb 26 15:18:20 data kernel: BTRFS critical (device loop2): corrupt leaf: block=23371907072 slot=93 extent bytenr=115523584 len=16384 inline ref out-of-order: has type 176 offset 7493989779944505798 seq 0x68000000000001c6, prev type 176 seq 0x1c7 Feb 26 15:18:20 data kernel: BTRFS error (device loop2): read time tree block corruption detected on logical 23371907072 mirror 1 Feb 26 15:18:20 data kernel: BTRFS critical (device loop2): corrupt leaf: block=23371907072 slot=93 extent bytenr=115523584 len=16384 inline ref out-of-order: has type 176 offset 7493989779944505798 seq 0x68000000000001c6, prev type 176 seq 0x1c7 Feb 26 15:18:20 data kernel: BTRFS error (device loop2): read time tree block corruption detected on logical 23371907072 mirror 2 Feb 26 15:18:20 data kernel: BTRFS error (device loop2): failed to run delayed ref for logical 114114560 num_bytes 16384 type 176 action 1 ref_mod 1: -5 Feb 26 15:18:20 data kernel: BTRFS error (device loop2: state A): Transaction aborted (error -5) Feb 26 15:18:20 data kernel: BTRFS: error (device loop2: state A) in btrfs_run_delayed_refs:2184: errno=-5 IO failure Feb 26 15:18:20 data kernel: BTRFS info (device loop2: state EA): forced readonly und da dein system Share auf cache_ssd liegt wo die effektiven Docker images liegen ... und dieses ein btrfs cache ist ... wäre dies mein Ansatzm also hat wahrscheinlich nichts mit appdata welches auf cache_nvme /xfs) liegt zu tun, sondern eher da ... mehr geht aber jetzt erst mit v7 diags wenn es Fehler gibt, aber Tipp ... sicher dir mal die wichtigen Daten des btrfs caches weg bevor ... und damit ist nicht /mnt/user/system/docker/ gemeint, das gerne immer skippen bei ner Sicherung.
February 28, 20251 yr Author 16 hours ago, alturismo said: im previous log sieht man zumindest wahrscheinlich einen Auslöser, btrfs Feb 26 15:18:20 data kernel: BTRFS critical (device loop2): corrupt leaf: block=23371907072 slot=93 extent bytenr=115523584 len=16384 inline ref out-of-order: has type 176 offset 7493989779944505798 seq 0x68000000000001c6, prev type 176 seq 0x1c7 Feb 26 15:18:20 data kernel: BTRFS error (device loop2): read time tree block corruption detected on logical 23371907072 mirror 1 Feb 26 15:18:20 data kernel: BTRFS critical (device loop2): corrupt leaf: block=23371907072 slot=93 extent bytenr=115523584 len=16384 inline ref out-of-order: has type 176 offset 7493989779944505798 seq 0x68000000000001c6, prev type 176 seq 0x1c7 Feb 26 15:18:20 data kernel: BTRFS error (device loop2): read time tree block corruption detected on logical 23371907072 mirror 2 Feb 26 15:18:20 data kernel: BTRFS error (device loop2): failed to run delayed ref for logical 114114560 num_bytes 16384 type 176 action 1 ref_mod 1: -5 Feb 26 15:18:20 data kernel: BTRFS error (device loop2: state A): Transaction aborted (error -5) Feb 26 15:18:20 data kernel: BTRFS: error (device loop2: state A) in btrfs_run_delayed_refs:2184: errno=-5 IO failure Feb 26 15:18:20 data kernel: BTRFS info (device loop2: state EA): forced readonly und da dein system Share auf cache_ssd liegt wo die effektiven Docker images liegen ... und dieses ein btrfs cache ist ... wäre dies mein Ansatzm also hat wahrscheinlich nichts mit appdata welches auf cache_nvme /xfs) liegt zu tun, sondern eher da ... mehr geht aber jetzt erst mit v7 diags wenn es Fehler gibt, aber Tipp ... sicher dir mal die wichtigen Daten des btrfs caches weg bevor ... und damit ist nicht /mnt/user/system/docker/ gemeint, das gerne immer skippen bei ner Sicherung. hi, danke für das debugging! ja, richtig meine docker images liegen auf dem BTRFS cache laufwerk. ich sehe das problem nicht. warum funkioniert das unter v6 aber nicht unter v7? ist das so ungewöhlich das docker images auf einem BTRFS cache laufwerk liegen oder warum wird das bei einem upgrade nicht beachtet - egal in welcher form (techn oder zumindes einen hinweis im changelog) ist das nun ein bug in unraid v7 oder ist das mein problem ? /velvet
February 28, 20251 yr 25 minutes ago, velvet said: ist das nun ein bug in unraid v7 oder ist das mein problem ? btrfs cache geht natürlich auch auf v7 was ich davon halte (und viele andere auch) ... Suche oben rechts zu btrfs. also, ich würde so oder so ein Backup mal machen, auch mal scrub durchführen auf dem cache, usw usw ... das sieht halt danach aus als würde es nicht mehr lange gut gehen, bei deinem v7 Update war es dann halt erstmal "read only" gesetzt aufgrund der Fehler. meine Vorgehensweise wäre wenn ich den btrfs cache behalten wollen würde, Daten sichern, Cache Platten formatieren, Daten retour spielen (alles außer ../system/docker/), Dockers neu installieren (Daten bleiben erhalten) vor oder nach dem Upgrade auf v7, die Sicherung würde ich jedoch zeitnah machen
February 28, 20251 yr Author 22 minutes ago, alturismo said: btrfs cache geht natürlich auch auf v7 was ich davon halte (und viele andere auch) ... Suche oben rechts zu btrfs. also, ich würde so oder so ein Backup mal machen, auch mal scrub durchführen auf dem cache, usw usw ... das sieht halt danach aus als würde es nicht mehr lange gut gehen, bei deinem v7 Update war es dann halt erstmal "read only" gesetzt aufgrund der Fehler. meine Vorgehensweise wäre wenn ich den btrfs cache behalten wollen würde, Daten sichern, Cache Platten formatieren, Daten retour spielen (alles außer ../system/docker/), Dockers neu installieren (Daten bleiben erhalten) vor oder nach dem Upgrade auf v7, die Sicherung würde ich jedoch zeitnah machen danke für deine Einschätzung. ich hänge nicht an btrfs - kann auch jedes andere dateisystem sein. was wäre denn geeignet für mein cache laufwerk und was wäre eine gute vorgehensweise zum ändern? - backup - array stoppen - umformatieren - array starten und dann restore / oder restore und dann array starten? (ist das überhaupt möglich?) /velvet
February 28, 20251 yr Solution 16 minutes ago, velvet said: was wäre denn geeignet für mein cache laufwerk und was wäre eine gute vorgehensweise zum ändern? wenn es redundant sein soll würde ich eher zu zfs wechseln, da ich aber ein Freund des single drive cache (xfs) bin mit Backup Strategie ... bin ich der falsche Ansprechpartner dafür und Vorgehensweise 0/ Docker und VM Dienst >> AUS 1/ Backup machen (ohne /mnt/cache_ssd/system/docker/) 2/ Array stop 3/ disks aus cache entfernen (Reihenfolge merken) 4/ in Unassigned devices (unten) Partitionen entfernen (UAD Plus plugin muss installiert sein) 5/ Cache disks wieder zuweisen (gleiche Reihenfolge), formatieren lassen (oder auch als zfs zuweisen) im entsprechenden Format 6/ Array Start 7/ Backup retour spielen 8/ Docker und VM Dienste wieder starten 9/ Dockers neu installieren (Achtung, wenn zfs genommen wird, overlay in Docker Settings umstellen)
February 28, 20251 yr Author 27 minutes ago, alturismo said: wenn es redundant sein soll würde ich eher zu zfs wechseln, da ich aber ein Freund des single drive cache (xfs) bin mit Backup Strategie ... bin ich der falsche Ansprechpartner dafür und Vorgehensweise 0/ Docker und VM Dienst >> AUS 1/ Backup machen (ohne /mnt/cache_ssd/system/docker/) 2/ Array stop 3/ disks aus cache entfernen (Reihenfolge merken) 4/ in Unassigned devices (unten) Partitionen entfernen (UAD Plus plugin muss installiert sein) 5/ Cache disks wieder zuweisen (gleiche Reihenfolge), formatieren lassen (oder auch als zfs zuweisen) im entsprechenden Format 6/ Array Start 7/ Backup retour spielen 8/ Docker und VM Dienste wieder starten 9/ Dockers neu installieren (Achtung, wenn zfs genommen wird, overlay in Docker Settings umstellen) danke, werde ich angehen! ein paar fragen ergeben sich allerdings noch: - warum nicht "/mnt/cache_ssd/system/docker" dann spare ich mir doch den reinstall der container, richtog? oder ist der reinstall der favorisierte weg? - weswegen ist die reihenfolge wichtig, wenn der disk verbund doch neu formatiert wird? vielen dank /velvet
February 28, 20251 yr Just now, velvet said: - warum nicht "/mnt/cache_ssd/system/docker" dann spare ich mir doch den reinstall der container, richtog? weil da sicherlich bereits was defekt ist weil das bei "verzeichnis / directory" ewig dauert und ein reinstall schneller ist daher ja, favorisiert 1 minute ago, velvet said: - weswegen ist die reihenfolge wichtig, wenn der disk verbund doch neu formatiert wird? teste es aus und du wirst es sehen ... kurz, wir lösen den cache ja nicht auf, Unraid erwartet disk_123 in slot 1, disk_456 in slot 2, ... ansonsten, nicht tragisch, wird aber sicherlich dann "new config" benötigt (neu zuweisen und alte "vergessen")
February 28, 20251 yr Author 11 minutes ago, alturismo said: weil da sicherlich bereits was defekt ist weil das bei "verzeichnis / directory" ewig dauert und ein reinstall schneller ist daher ja, favorisiert teste es aus und du wirst es sehen ... kurz, wir lösen den cache ja nicht auf, Unraid erwartet disk_123 in slot 1, disk_456 in slot 2, ... ansonsten, nicht tragisch, wird aber sicherlich dann "new config" benötigt (neu zuweisen und alte "vergessen") Verstehe ich, danke. Ich gebe Rückmeldung ...
February 28, 20251 yr Author Benötige nochmals Hilfe: Ich hänge an dem Punkt format disk. Ich sehe im UD Plus keine Partition, die ich löschen könnte: /velvet
February 28, 20251 yr 1 minute ago, velvet said: Ich hänge an dem Punkt format disk. Ich sehe im UD Plus keine Partition, die ich löschen könnte: das ist vorne im Hauptbildschirm, das ROTE X normal (kommt nur wenn die Platte natürlich nicht mounted ist)
February 28, 20251 yr Author 2 minutes ago, alturismo said: das ist vorne im Hauptbildschirm, das ROTE X normal (kommt nur wenn die Platte natürlich nicht mounted ist) ist sie nicht:
February 28, 20251 yr Author fixed - bin auf 7.0.1 und docker funkioniert auch wieder, wie es soll ich bin allerdings etwas abgewichen; da ich nun den Prozess verstanden habe und btrfs gar nicht so schlecht finde, dachte ich mir lösche ich erst mal das docker.img file und mache dann das update auf 7. mit etwas Glück spare ich mir den restore, dachte ich mir. ich hatte Glück das ursprüngliche Problem war tatsächlich nur das docker.img nach einem reinstall aller docker container war alles ok! @alturismo nochmals vielen dank! grüss, velvet
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.