Hallo,

ich hab ein merkwürdiges Phänomen:

Seit heute beenden sich gewisse Docker Container bzw. lassen sich nicht mehr starten. Es handelt sich dabei um die Container von Paperless NGX, Vaultwarden und Frigate jeweils in der aktuellen Version.

Das Docker File System ist zu 17% belegt - an fehlendem Speicher sollte es also nicht scheitern auch ein df- -h zeigt keine vollen Speicherpfade an. Inodes sind auch ausreichend freie verfügbar.

Frigate versucht ständig neu zu starten beendet sich dann aber immer wieder.

Paperless beendet sich, ohne für mich erkennbare Fehlermeldung mit Exit Code 1 - Edit: Gerade im Log gesehen, dort tauch t auch die MEldung Mo Space left on Device auf. Es ist aber noch Platz da. Kann die NVME auf der das appdata Verzeichnis liegt vielleicht irgendwie schreibgeschützt sein? Kann man das irgendwie überprüfen?

Vaultwarden schreibt im LOG, dass es nicht auf die DB zugreifen kann - die ist aber im Appdata-Verzeichnis vorhanden (db.sqlite3) (wenn ich versuche die mit sqlite3 zu öffnen und ein Backup zu erstellen, bekomme ich die Meldung "No space left on Device".

Ich bin jetzt gerade mit meinem Latein ein wenig am Ende und weiß nicht, was ich noch probieren kann.

Kann jemand von euch helfen?

Edited March 21Mar 21 by Knifte

Nutzt du Docker Image oder Directory? Standard ist Image im BTRFS Format.

Schau mal unter Settings-Docker dort auf Advanced View umstellen.

Evtl. ist das Docker Image defekt bzw. auf Read only.

@cz13

Wie finde ich raus, ob das defekt oder Read Only ist?

3 minutes ago, cz13 said:

Evtl. ist das Docker Image defekt bzw. auf Read only.

Guter Punkt, aber dann wären alle Docker betroffen. Ich habe ihn jetzt so verstanden dass es nur einzelne Container betrifft? Welche betrifft es nicht?

Was ist denn jeweils die Gemeinsamkeit von denen?

Liegen die Verzeichnisse alle am selben Ort?

Haben alle vielleicht gerade automatische Updates bekommen?

Was hast du sonst noch verändert?

…

Ist vielleicht dein Cache read only? (Und die anderen noch laufenden haben gar kein appdata Verzeichnis, welches darauf liegt?

@_alo_

Meine Vermutung ist auch irgendwie, dass der Cache Read-Only ist. Müsste ich doch rausfinden können, wenn ich einfach eine leere Datei anzulegen versuche, oder?

Das sind die anderen Docker und alle haben Verzeichnisse in appdata

4 minutes ago, _alo_ said:

Ist vielleicht dein Cache read only? (Und die anderen noch laufenden haben gar kein appdata Verzeichnis, welches darauf liegt?

Bin jetzt mal über die Konsole auf den Cache gewechselt und habe dort im Backup-Verzeichnis eine Text-Datei erstellt und da was reingeschrieben und die Datei gespeichert. Das hat auch problemlos geklappt.

Im übergeordneten appdata Verzeichnis unter Cache funktioniert das auch. komischerweise auch im Verzeichnis von Vaultwarde. Scheint also doch nicht am Schreibschutz zu liegen, oder?

45 minutes ago, Knifte said:

Es handelt sich dabei um die Container von Paperless NGX, Vaultwarden und Frigate jeweils in der aktuellen Version.

Da fällt mir doch im Screenshot direkt was auf:

Alle drei sind genau die mit tailscale….

Könnte also auch ein anderes Problem (und eine falsche/irreführende Fehlermeldung) sein 😉

@_alo_ das ist mir tatsächlich eben auch aufgefallen. Ich starte das NAS jetzt nochmal neu und teste es mal ohne Tailscale.

Aber das lief ja seit Monaten so - würde mich halt sehr wundern, wenn das auf einmal dazu führt, dass mehrere Docker gleichzeitig nicht mehr funktionieren?

@_alo_ Das Fehlerbild ist das gleiche, wenn ich Tailscale in den Dockern deaktiviere

Aus dem Paperless-Log:

OSError: [Errno 28] No space left on device: '/usr/src/paperless/data/__paperless_write_test_145__'
s6-rc: warning: unable to start service init-system-checks: command exited 1

Diesen Pfad kann ich über die Konsole aber auch gar nicht erreichen:

Edited March 21Mar 21 by Knifte

33 minutes ago, Knifte said:

Diesen Pfad kann ich über die Konsole aber auch gar nicht erreichen:

das ist auch der Pfad innerhalb des dockers und nicht auf dem Host.

dazu müsste der docker laufen, dann könnte man

docker exec paperless-ngx ls -la /usr/src/...

wenn du dir sicher bist das es nicht an tailscale liegt wäre erster Ansatz, Image neu machen.

1/ docker service stop (docker settings page)

2/ docker image löschen

3/ docker service starten > neues image wird erstellt

4/ dockers unter dem docker tab neu erstellen aus templates (add container, oben das dropdown, uer templates) oder previous apps (app store)

Info, settings und Daten bleiben erhalten

start settings liegen auf dem stick, config Daten liegen unter /appdata, im image ist nichts persistent.

wenn du custom networks nutzen solltest, diese müssen dann wieder erstellt werden, sieht aber auf deinem screen nicht danach aus.

Danke @alturismo und @cz13 und natürlich auch @_alo_, das war die Lösung. Jetzt läuft wieder alles.

Edited March 21Mar 21 by Knifte

Hm, jetzt tritt heute das Problem wieder auf.

Woran könnte das denn jetzt liegen?

Wo wird die Docker.img denn gespeichert? Kann das an einem sterbenden USB Stick liegen?

44 minutes ago, Knifte said:

Wo wird die Docker.img denn gespeichert? Kann das an einem sterbenden USB Stick liegen?

eher nicht, auf dem Stick wird dazu nichts gemacht.

woran kann das liegen, gerne wenn die Platte per se in btrfs läuft, so zumindest leider meine Erfahrung, dann zerhaut es auch gerne das darauf liegende Image.

Daher mal vorne angefangen, wo liegt das Image bzw. wie ist der Share /system eingerichtet.

Und davon ab, auch gern gemachter Fehler, bist du dir sicher das kein Docker falsch konfiguriert ist und permanent ins Image schreibt (dieses läuft dann voll ...)

Das sind die 2 Gründe wo meist dafür verantwortlich sind.

Hi und sorry für die späte Rückmeldung,

also, die docker.img liegt bei mir auf dem Cache (eine 2 TB NVME SSD). Diese hat das BTRFS Filesystem. Da sind auch "nur" knapp 200 GB belegt und gut 1,8 TB frei. (Allerdings waren es bis eben umgekehrt, dass da nur noch knapp 200 GB frei waren - wegen der Frigate-Aufzeichnungen. Die habe ich jetzt aber mal weitestgehend gelöscht)

Der Share /system ist wie folgt eingerichtet:

Ins Docker.img schreibt da m.E. nichts - es sind alle docker so konfiguriert, dass die in Appdata speichern:

Ich habe das Plugin "Appdata Backup" laufen, dass ja nachts die Docker stoppt, ein Backup macht und diese dann wieder hochfährt. Das habe ich jetzt auch mal live beobachtet und das funktioniert auch soweit. Ich habe aber dennoch das Gefühl, dass die Docker dann wegen des Zeitstempels immer kurz danach stoppen.

56 minutes ago, Knifte said:

also, die docker.img liegt bei mir auf dem Cache (eine 2 TB NVME SSD). Diese hat das BTRFS Filesystem...

btrfs: hast Du mal geprüft ob das Dateisystem noch in Ordnung ist?

Nein, das habe ich tatsächlich auch noch nicht gemacht. Bin mir grad aber auch nicht sicher, wie man das anstoßen kann.

7 hours ago, Knifte said:

Nein, das habe ich tatsächlich auch noch nicht gemacht. Bin mir grad aber auch nicht sicher, wie man das anstoßen kann.

einen scrub ausführen, siehe Unraid docs.

ansonsten, wenn es eine single cache disk ist, btrfs ... ich weiß man will es nicht hören, aber meine Erfahrung hier war damit leider immer, fehleranfällig ...

daher empfehle ich bei single cache drives immer xfs, und wenn es raid sein soll, muss, ... dann halt zfs.

Schub hab ich letztens gemacht. Das hat keine Fehler gemeldet.

Ich hab’s einfach standardmäßig auf btrfs gelassen. Dann sollte ich es vielleicht mal in Café ändern.

4 hours ago, Knifte said:

Schub hab ich letztens gemacht. Das hat keine Fehler gemeldet.

Ich hab’s einfach standardmäßig auf btrfs gelassen. Dann sollte ich es vielleicht mal in Café ändern.

Nur so zur Info:

Ich vermute Du hast BTRFS im Image (Default) und BTRFS auf der SSD/Cache (manuell gewählt).

Ich stimme alturismo zu und bin kein Fan von BTRFS (aufgrund der vielen hier auch gemeldeten unspezifischen Fehler, die sich dann als BTRFS Problem herausstellten).

Single Disks und Array. xfs

Verbund von Disks: zfs

Wenn Deine Docker Imagedatei mit defaulteinstellungen erstellt wurde ist die auch BTRFS. Ich habe auch diese bei mir auf xfs umge- und dann neu erstellt.

So, ich habe heute mal alles gesichert und von btrfs auf xfs umgestellt. Mal schauen, wie es sich entwickelt.

Was mir dabei aber aufgefallen war:

Ich hab Home Assistant als VM unter Unraid laufen und wollte die (in Dateiform) gesicherte VM wieder irgendwie einbinden, aber das ist mir nicht gelungen.

Hab dann die VM neu aufgesetzt und ein Backup eingespielt.

Geht das irgendwie eleganter? Sorry, hat mit dem ursprünglichen Topic nichts mehr zu tun.

9 hours ago, Knifte said:

Geht das irgendwie eleganter? Sorry, hat mit dem ursprünglichen Topic nichts mehr zu tun.

die VM Parameter sind unter /system/libvirt/...

die VM an sich ist unter /domains/vn_name//...

wenn beides aus einem backup restored wurde sollte die auch einfach wieder starten.

Ich hatte einfach alles aufs Array kopiert.

Dann muss ich mich nochmal mit dem Thema Backup der VM etc. auseinandersetzen.

29 minutes ago, Knifte said:

Ich hatte einfach alles aufs Array kopiert.

passt ja, außer das dann die disk halt immer up ist bei VM.

sofern du nicht "manuell" umgestellt hast von /mnt/user auf /mnt/cache... greift auch alles was auf dem array liegt.

Bewusst umgestellt habe ich nichts.

Aber es lief nicht einfach so weiter. Wo könnte ich das denn genau nachschauen was ich da im Zweifel wo eingestellt habe?

9 hours ago, Knifte said:

Aber es lief nicht einfach so weiter. Wo könnte ich das denn genau nachschauen was ich da im Zweifel wo eingestellt habe?