Użytkownik źródłowy zinterpretował błąd jako „Docker nie może zainstalować obrazu po świeżej reinstalacji”, ale dane wyjściowe terminala faktycznie pokazywały dwa odrębne problemy. Uruchomienie docker info bez podwyższonych uprawnień nie powiodło się z powodu problemu z gniazdem Dockera, podczas gdy uruchomienie kontenera Mosquitto z uprawnieniami Dockera pomyślnie pobrało eclipse-mosquitto:latest. Kontener zakończył następnie działanie z innego powodu: montowanie bind próbowało potraktować ścieżkę na hoście i ścieżkę w kontenerze jako niezgodne typy — plik i katalog.
To rozróżnienie ma kluczowe znaczenie. Ponowna instalacja Debiana, CasaOS lub Dockera nie naprawi montowania bind wskazującego niewłaściwy typ obiektu systemu plików.
Problem 1: Zwykły użytkownik nie mógł uzyskać dostępu do gniazda Dockera
Pierwsze docker info dane wyjściowe zawierały:
odmowa dostępu podczas próby połączenia z gniazdem demona Dockera
unix:///var/run/docker.sockOznacza to, że użytkownik powłoki nie miał uprawnień do bezpośredniej komunikacji z demonem Dockera. To samo polecenie zadziałało z sudo, co dowodziło, że sam demon był osiągalny.
To osobna kwestia od późniejszego błędu uruchamiania Mosquitto.
Obraz Mosquitto został pobrany pomyślnie
Docker zgłosił:
Status: Pobrano nowszy obraz dla eclipse-mosquitto:latestZatem rejestr, nazwa obrazu i połączenie z Internetem nie były bezpośrednią przyczyną problemu. Błąd wystąpił dopiero wtedy, gdy Docker próbował utworzyć system plików kontenera i zastosować montowanie bind.
Prawdziwy błąd dotyczył montowania pliku zamiast katalogu lub odwrotnie
Polecenie próbowało zmapować:
/etc/mosquitto/mosquitto.conf
→ /mosquitto/config/mosquitto.confDocker zgłosił następnie:
nie katalogiem
Czy próbujesz zamontować katalog w miejscu pliku (lub odwrotnie)?Ten komunikat należy rozumieć dosłownie. Jeden z elementów mapowania nie był typem oczekiwanym przez polecenie.
Dlaczego -v może automatycznie utworzyć niewłaściwy typ
Aktualna dokumentacja Dockera wyjaśnia częstą pułapkę z -v/--volume: jeśli ścieżka źródłowa nie istnieje, Docker automatycznie utworzy ją jako katalog.
Jeśli więc /etc/mosquitto/mosquitto.conf nie istniał już jako rzeczywisty plik, Docker mógł utworzyć katalog o nazwie mosquitto.confZamontowanie tego katalogu w miejscu oczekiwanego pliku konfiguracyjnego kontenera powoduje dokładnie ten sam błąd, który pokazano w wątku źródłowym.
Użyj bieżącego działania montowań bind w Dockerze, aby sprawdzić, czy źródło jest plikiem, czy katalogiem, przed uruchomieniem kontenera.
Społeczność przeszła na mapowanie katalogów Mosquitto
Osoba udzielająca odpowiedzi udostępniła definicję Compose, która mapowała trzy trwałe katalogi:
- katalog konfiguracji na hoście →
/mosquitto/config - katalog danych na hoście →
/mosquitto/data - katalog logów na hoście →
/mosquitto/log
Pozwala to uniknąć niestabilnego montowania „pojedynczego pliku, który może jeszcze nie istnieć” i zapewnia Mosquitto zwykły, trwały układ katalogów.
Plik konfiguracji nadal musi istnieć w katalogu konfiguracji
Samo zamapowanie katalogu nie tworzy automatycznie prawidłowej konfiguracji Mosquitto. Osoba udzielająca odpowiedzi poinformowała użytkownika, aby umieścił mosquitto.conf do zamapowanego katalogu konfiguracji przed uruchomieniem brokera.
W przypadku nowego wdrożenia najpierw utwórz konfigurację jako rzeczywisty plik, a następnie zamontuj jego katalog nadrzędny lub użyj bardziej jednoznacznego mechanizmu Dockera --mount składnię, która kończy się błędem zamiast po cichu tworzyć brakujący katalog źródłowy.
Niestandardowa instalacja w CasaOS może odwzorować ten sam układ bez bezpośredniego polecenia docker run
Społeczność przeprowadziła użytkownika przez importowanie definicji Compose za pomocą procesu niestandardowej aplikacji w CasaOS. Później użytkownik zainstalował pakiet Mosquitto ze społecznościowego sklepu z aplikacjami i zgłosił, że od razu działał.
Ten rezultat potwierdza, że sam host Dockera był w stanie uruchomić Mosquitto; wcześniejszy problem dotyczył konfiguracji, a nie nieudanej ponownej instalacji CasaOS.
Działający broker nadal wymaga konfiguracji uwierzytelniania MQTT i nasłuchiwania
Następnie użytkownik zapytał, dlaczego Node-RED nie nawiązał połączenia oraz czy Mosquitto będzie automatycznie używać nazwy użytkownika i hasła z terminala. Nie będzie. Uwierzytelnianie MQTT jest konfigurowane przez samego Mosquitto za pomocą jego konfiguracji i plików haseł.
Nie zakładaj, że zielony status kontenera oznacza, iż broker jest gotowy na nieuwierzytelnionych klientów.
Strefa czasowa była ostatnim szczegółem konfiguracji kontenera
Po zainstalowaniu działającego pakietu społecznościowego użytkownik nadal musiał dodać odpowiednią wartość zmiennej środowiskowej strefy czasowej. Jest to szczegół konfiguracji aplikacji/środowiska uruchomieniowego, a nie dowód kolejnej awarii instalacji Dockera.
Najczęstsze pytania dotyczące błędów Dockera Mosquitto
Czy Docker nie zdołał pobrać eclipse-mosquitto?
Nie. Dane źródłowe pokazują, że obraz został pomyślnie pobrany.
Dlaczego kontener nie uruchomił się?
W dowiązaniu bind występowała niezgodność typu plik–katalog dotycząca mosquitto.conf.
Dlaczego brakujący plik na hoście może stać się katalogiem przy użyciu docker -v?
Dockera --volume Takie zachowanie tworzy brakujące źródło na hoście jako katalog, co może zakłócić dowiązanie bind typu plik–plik.
Czy ponowna instalacja CasaOS rozwiązała problem?
Nie. Użytkownik ostatecznie uzyskał działające rozwiązanie po zastosowaniu prawidłowej konfiguracji aplikacji/kontenera.
