Der Quellbenutzer interpretierte den Fehler als „Docker kann nach einer sauberen Neuinstallation kein Image installieren“, aber die Terminalausgabe zeigte tatsächlich zwei getrennte Probleme. Das Ausführen von docker info ohne erhöhte Berechtigungen schlug beim Docker-Socket fehl, während das Ausführen des Mosquitto-Containers mit Docker-Berechtigungen erfolgreich Folgendes herunterlud: eclipse-mosquitto:latest. Der Container schlug dann aus einem anderen Grund fehl: Der Bind-Mount versuchte, einen Hostpfad und einen Containerpfad als inkompatible Datei-/Verzeichnistypen zu behandeln.
Diese Unterscheidung ist entscheidend. Eine Neuinstallation von Debian, CasaOS oder Docker behebt keinen Bind-Mount, der auf den falschen Typ eines Dateisystemobjekts verweist.
Problem 1: Der normale Benutzer konnte nicht auf den Docker-Socket zugreifen
Die erste docker info die Ausgabe lautete:
Berechtigung verweigert beim Versuch, eine Verbindung zum Docker-Daemon-Socket herzustellen
unix:///var/run/docker.sockDas bedeutet, dass der Shell-Benutzer keine Berechtigung hatte, direkt mit dem Docker-Daemon zu kommunizieren. Derselbe Befehl funktionierte mit sudo, was beweist, dass der Daemon erreichbar war.
Dies ist unabhängig vom späteren Mosquitto-Startfehler.
Das Mosquitto-Image wurde erfolgreich heruntergeladen
Docker meldete:
Status: Neueres Image für eclipse-mosquitto:latest heruntergeladenDas Registry, der Image-Name und die Internetverbindung waren also nicht das unmittelbare Problem. Der Fehler trat erst auf, als Docker das Container-Dateisystem erstellte und den Bind-Mount anwendete.
Der eigentliche Fehler war das Einbinden von Datei und Verzeichnis
Der Befehl versuchte, Folgendes zuzuordnen:
/etc/mosquitto/mosquitto.conf
→ /mosquitto/config/mosquitto.confDocker meldete anschließend:
kein Verzeichnis
Versuchen Sie, ein Verzeichnis in eine Datei einzubinden (oder umgekehrt)?Diese Meldung sollte wörtlich genommen werden. Eine Seite der Zuordnung hatte nicht den vom Befehl erwarteten Typ.
Warum -v automatisch den falschen Typ erstellen kann
Die aktuelle Docker-Dokumentation erklärt eine häufige Falle bei -v/--volume: Wenn der Quellpfad nicht existiert, erstellt Docker ihn automatisch als Verzeichnis.
Wenn also /etc/mosquitto/mosquitto.conf nicht bereits als echte Datei vorhanden war, konnte Docker ein Verzeichnis namens mosquitto.confDas Einbinden dieses Verzeichnisses in die vom Container erwartete Konfigurationsdatei erzeugt dann genau den im ursprünglichen Thread beschriebenen Fehler.
Verwenden Sie das aktuelle Verhalten von Docker bei Bind-Mounts, um vor dem Start des Containers zu überprüfen, ob die Quelle eine Datei oder ein Verzeichnis ist.
Die Community wechselte dazu, Mosquitto-Verzeichnisse einzubinden
Ein Community-Mitglied teilte eine Compose-Definition, die drei persistente Verzeichnisse zuordnete:
- Host-Konfigurationsverzeichnis →
/mosquitto/config - Host-Datenverzeichnis →
/mosquitto/data - Host-Protokollverzeichnis →
/mosquitto/log
Dadurch wird der fehleranfällige Mount einer „einzelnen Datei, die möglicherweise noch nicht existiert“ vermieden und Mosquitto erhält eine normale persistente Struktur.
Die Konfigurationsdatei muss weiterhin im Konfigurationsverzeichnis vorhanden sein
Das Einbinden des Verzeichnisses erstellt nicht automatisch eine gültige Mosquitto-Konfiguration. Der Benutzer wurde aufgefordert, mosquitto.conf in das zugeordnete Konfigurationsverzeichnis kopieren, bevor Sie den Broker starten.
Bei einer neuen Bereitstellung sollten Sie die Konfiguration zunächst als echte Datei erstellen und anschließend ihr übergeordnetes Verzeichnis einbinden oder Dockers ausführlicheres --mount Syntax, die statt stillschweigend ein fehlendes Quellverzeichnis zu erstellen, fehlschlägt.
Die benutzerdefinierte Installation von CasaOS kann dasselbe Layout ohne einen direkten docker-run-Befehl abbilden
Die Community führte den Benutzer durch den Import einer Compose-Definition über den Workflow für benutzerdefinierte Anwendungen von CasaOS. Später installierte der Benutzer ein Mosquitto-Paket aus einem Community-App-Store und berichtete, dass es sofort funktionierte.
Dieses Ergebnis bestätigt, dass der Docker-Host selbst Mosquitto ausführen konnte; das frühere Problem war eine Konfigurationssache und keine fehlgeschlagene Neuinstallation von CasaOS.
Ein laufender Broker benötigt weiterhin MQTT-Authentifizierung und eine Listener-Konfiguration
Der Benutzer fragte anschließend, warum Node-RED keine Verbindung herstellte und ob Mosquitto automatisch den Terminal-Benutzernamen und das Passwort verwenden würde. Das ist nicht der Fall. Die MQTT-Authentifizierung wird von Mosquitto selbst über seine Konfiguration und Passwortdateien eingerichtet.
Gehen Sie nicht davon aus, dass ein grüner Containerstatus bedeutet, dass der Broker für nicht authentifizierte Clients bereit ist.
Die Zeitzone war ein abschließendes Detail der Containerkonfiguration
Nach der Installation eines funktionierenden Community-Pakets musste der Benutzer noch den passenden Zeitzonenwert als Umgebungsvariable hinzufügen. Das ist ein Detail der Anwendung/Laufzeitumgebung und kein Hinweis auf einen weiteren Fehler bei der Docker-Installation.
FAQ zu Docker-Fehlern bei Mosquitto
Ist Docker beim Herunterladen von eclipse-mosquitto fehlgeschlagen?
Nein. Die Ausgabe der Quelle zeigt, dass das Image erfolgreich heruntergeladen wurde.
Warum konnte der Container nicht gestartet werden?
Beim Bind-Mount lag ein Konflikt zwischen Datei und Verzeichnis vor bei mosquitto.conf.
Warum kann eine fehlende Host-Datei mit docker -v zu einem Verzeichnis werden?
von Docker --volume Dieses Verhalten erstellt die fehlende Host-Quelle als Verzeichnis, wodurch ein Datei-zu-Datei-Bind-Mount fehlschlagen kann.
Hat die Neuinstallation von CasaOS das Problem behoben?
Nein. Der Benutzer hatte letztlich Erfolg, nachdem er eine korrekte Anwendungs-/Containerkonfiguration verwendet hatte.
