[Synology Docker]Iobroker startet nicht (no database)

[Finn G.]

@haselchen Wie vielen Leuten willst du noch erzählen wie toll ihr seid und was die anderen alles falsch machen?

Du merkst ja nicht einmal, dass @Homoran nur wegen einem Beitrag persönlich geworden ist. Hier war ja nicht mal Spam oder so. Und hier haben sich die Leute intensiv mit dem genauen Anluegen beschäftig. Es war anscheinend falsch, genau diese Leute um einen Impuls zu bitten. Es wurden all eure Fragen beantwortet. Und ihr geht davon aus, dass man eure Sprache und Abkürzungen versteht. Und wenn man was falsch macht, verweist ihr auf Wiki´s oder Anleitungen.

Es ist nicht das erste mal dass du dich rechtfertigst. In der Sache bringt es nicht. Vermutlich verteidigt ihr euer Baby einfach nur. Könnt ihr euch überhaupt vorstellen, was falsch läuft und. welche Verbesserungen es braucht? Von Selbstkritik, hab ich hier nie was gesehen.

EDIT: falls du es nicht merkst. Genau den ersten Satz habe ich hier als erste Reaktion von jemanden bekommen, der nicht helfen, aber dafür belehren kan.

Und meine Technischen Fähigkeiten reichen aus umd 95% aus der Cloud gegangen zu sein. Nur eMail Server soll man selber nicht machen. Alles andere, und damit meine ich viele andere Docker Systeme, funktionieren vorbildlich. ioBroker, ist das größte Problem. Jahre schon auf dem RasPi und nun Jahre im Docker. Wie gesagt, die anderen Programme funktionieren.

[Codierknecht]

@finn-g
Bevor das hier völlig eskaliert: Hinsetzen, durchatmen, neu anfangen.

Vielleicht fängst Du das Ganze ja völlig falsch an.
Also zunächst alle Images aus dem Container-Manager löschen, die etwas mit ioBroker zu tun haben.
Auch Netzwerke die nur für ioBroker vorhanden sein sollten, können weg.
Und statt mit docker run usw. auf der Kommandozeile würde ich ein Projekt empfehlen. Das ist im Prinzip ein Docker-Compose und wesentlich flexibler.

In das Projekt kommt sowas hier rein:

services:
  iobroker:
    container_name: iobroker
    image: buanet/iobroker:latest
    hostname: iobroker
    volumes:
      - /volume1/docker/iobroker:/opt/iobroker
    ports:
      - "8089:8081"
    environment:
      PACKAGES: "nano"
      AVAHI: "true"
    tty: true
    stdin_open: true
    restart: unless-stopped

Spoiler

Versuch's mal und melde Dich wieder.

Und auch ohne dass es Dir gleich wieder sauer aufstößt: Dieses Forum ist keine 1:1 Betreuung für jeden Individualfall.
Die hier helfenden machen das alles in ihrer Freizeit - aus Spaß an der Freud'.
Also sei bitte ein bisschen Nachsichtig, wenn der Eine oder Andere aufgrund ständig wiederkehrender Fragen (und Doppelposts) mal etwas angesäuert ist.

wenn man was falsch macht, verweist ihr auf Wiki´s oder Anleitungen

Dazu sind die Dinger da. Damit man nach Anleitungen vorgeht (und zwar Schritt für Schritt) und sich die Helferlein nicht zum 100'sten mal mit den gleichen Fragen beschäftigen müssen.

[Homoran]

@finn-g sagte in [Synology Docker]Iobroker startet nicht (no database):

dass @Homoran nur wegen einem Beitrag persönlich geworden ist.

wo bitte bin ich persönlich geworden?
Was sollen diese Unterstellungen?

[Codierknecht]

@Finn-G
Zack ... läuft!

By the way: Ich habe ioBroker bereits zig mal aufgesetzt. Nativ, als Docker, LXC oder sogar unter Windows.
Lief immer out of the box.

[Codierknecht]

Können wir uns jetzt mal auf einen Thread einigen?

Entweder hier, oder dort: https://forum.iobroker.net/topic/77628/scripte-gehen-nicht-mehr-seltsamer-fehler-wie-reparieren

Edit
Das meinte @Homoran übrigens mit

in wie vielen Threads willst du dieses Thema anhängen?

Das ist weder persönlich, noch in irgendeiner Weise als Angriff zu verstehen.
Es gehört seit jeher in allen Foren die ich kenne zur Netiquette: Keine Doppel-/Crossposts.

[Jey Cee]

@codierknecht da kommt nichts mehr, der gute hat sich auch auf Discord gemeldet und dann Lautstark verkündet das er jetzt was anderes als ioBroker nutzt.

Das Problem sei seit Jahren bekannt.
Zitat:

Und hier bei diesem ext4 Problem. ioBroker kennt das Problem seit Jahren und gibt keine Info darüber aus. Lässt alle Synology User da rein fallen. Hätte ich das gewusst, hätte ich das damals getan oder in der Zwischenzeit umgestellt. Toller Service ioBroker.

Naja hätte er sich ernsthaft damit beschäftigt wüsste er dass das Problem auch Benutzer anderer Projekte, wie PiHole, auf der Synology haben, aber eben auch nicht alle.
Und wenn man sich da so durchließt hat es immer was mit verbogenen rechten zu tun, aber eine Pauschale Lösung gibt es wohl auch nicht.
Manche haben die Docker Konfiguration angepasst, andere haben die Container Rechte (privileged) entfernt und wiederum andere scheinen das Problem gelöst zu haben in dem sie dem Container mehr Rechte gegeben haben.

Ganz sicher ist jeden falls das es nichts mit dem verwendeten Dateisystem zu tun hat. Immerhin bezieht sich der erste Suchtreffer bei mir auf BTRFS als Dateisystem.
Am Ende ist es schwer zu sagen was die Ursache ist, vielleicht ein Update wie er behauptet oder er hat irgendwo unbedarft rumgespielt und dabei versehentlich etwas geändert.
Meiner Erfahrung nach ist zweiteres in 80% der Fälle die Ursache, das wollen die meisten nur nicht hören.

[Thomas Braun]

@jey-cee sagte in [Synology Docker]Iobroker startet nicht (no database):

Ganz sicher ist jeden falls das es nichts mit dem verwendeten Dateisystem zu tun hat.

Ausschließen kann man es aber auch nicht. Die capabilities mussen in den 'extended attributes' des Dateisystems verfügbar und aktiviert sein. Das ist aber eigentlich seit Jahren immer der Fall. Könnte allerdings sein, das bei älteren NAS-Systemen das nicht aktiviert ist. Als reine Datenhalde braucht es das ja nicht.

All major Linux file systems including Ext4, Btrfs, ZFS, and XFS support extended attributes. The kernel allows to have extended attribute names of up to 255 bytes and values of up to 64 KiB, but Ext4 and Btrfs might impose smaller limits, requiring extended attributes to be within a "filesystem block".

https://wiki.archlinux.org/title/Extended_attributes

[Jey Cee]

@Thomas-Braun Ich Präzisiere das mal: Es wurde behauptet das es explizit an ext4 liegt.
Deine Aussage stützt ja das es nicht nur bei ext4 Auftretten kann, sondern auch bei anderen Dateisystemen.

[Thomas Braun]

@jey-cee

Da der 'Kunde' @Finn-G oder PaulOWL oder PaulOldenburg und welche Nicks er in der Vergangenheit noch so verbraten hat aber davon überzeugt ist, das wir alle keine Ahnung hätten und bewusst die 'Kunden' mit einer Synology nicht informieren, das der ioBroker da ein bekanntes Problem seit Jahren mitschleppt ist mir das aber auch ehrlich gesagt komplett egal...

[Codierknecht]

@jey-cee sagte in [Synology Docker]Iobroker startet nicht (no database):

Meiner Erfahrung nach ist zweiteres in 80% der Fälle die Ursache, das wollen die meisten nur nicht hören.

Dem würde ich mich mal anschließen.
Das sind die Anwender, die sich wutentbrannt beim Entwickler melden:
A: "Deine Software hat 'nen Bug ... hab 'ne Fehlermeldung bekommen"!
E: "Und? Was steht drin?"
A: "Weiß ich nicht - hab' ich weggeklickt"

Das Problem ist die Erwartungshaltung.
Wenn man sich schon darüber beschwert, dass man Anleitungen lesen soll, hat man seine halbgaren Kenntnisse vermutlich aus dubiosen YT-Filmchen. Einmal angeguckt und dann versucht nachzubauen. Dabei aber etwas übersehen oder falsch verstanden.
Die landen dann hier und erwarten eine persönliche 1:1 Betreuung bis das (selbst produzierte) Problem behoben ist. Und natürlich Mechanismen in der Software, die solches Verhalten künftig verhindert oder zumindest davor warnen ... aber pronto.

Da ich jetzt ein DSM 7.2 als VM unter Proxmox laufen habe, kann ich das gerne mal testen.
Aber ich bin mir fast sicher, dass der Container mit allen möglichen Dateisystemen funktioniert. Ist halt ein relativ neues DSM. Und das Dateisystem der virtuellen Platten wir wohl auch keine Macken produzieren.
Aber auch auf meinem "alten" DSM 6 lief das jahrelang völlig problemlos. Ich meine es wäre dort ext4 gewesen.

Wenn der Kollege eh weg ist, kann ich mir das aber auch sparen. Soll er von mir aus mit einem anderen System glücklich werden. Reisende soll man nicht aufhalten.
... bis er unter anderem Nick hier wieder auftaucht
Fehler einzugestehen ist eben auch nicht jedem gegeben.