O utilizador de origem interpretou a falha como «o Docker não consegue instalar uma imagem após uma reinstalação limpa», mas o resultado do terminal mostrava, na realidade, dois problemas distintos. A execução docker info sem acesso elevado falhou no socket do Docker, enquanto a execução do contentor Mosquitto com privilégios do Docker transferiu com êxito eclipse-mosquitto:latest. O contentor falhou então por um motivo diferente: o bind mount tentou tratar um caminho do anfitrião e um caminho do contentor como tipos incompatíveis de ficheiro/diretório.
Esta distinção é fundamental. Reinstalar o Debian, o CasaOS ou o Docker não corrigirá um bind mount que aponte para o tipo errado de objeto do sistema de ficheiros.
Problema 1: O utilizador normal não conseguiu aceder ao socket do Docker
O primeiro docker info a saída indicava:
permissão negada ao tentar ligar ao socket do daemon do Docker
unix:///var/run/docker.sockIsso significa que o utilizador da shell não tinha permissão para comunicar diretamente com o daemon do Docker. O mesmo comando funcionou com sudo, provando que o daemon estava acessível.
Isto é separado do erro posterior de arranque do Mosquitto.
A imagem do Mosquitto foi transferida com êxito
O Docker comunicou:
Estado: Imagem mais recente transferida para eclipse-mosquitto:latestAssim, o registo, o nome da imagem e a ligação à Internet não eram o problema imediato. A falha ocorreu apenas quando o Docker tentou criar o sistema de ficheiros do contentor e aplicar o bind mount.
O verdadeiro erro foi a montagem entre ficheiro e diretório
O comando tentou mapear:
/etc/mosquitto/mosquitto.conf
→ /mosquitto/config/mosquitto.confO Docker comunicou então:
não é um diretório
Está a tentar montar um diretório num ficheiro (ou vice-versa)?Essa mensagem deve ser interpretada literalmente. Um dos lados do mapeamento não tinha o tipo esperado pelo comando.
Porque é que o -v pode criar automaticamente o tipo errado
A documentação atual do Docker explica uma armadilha comum de -v/--volume: se o caminho de origem não existir, o Docker cria-o automaticamente como um diretório.
Por isso, se /etc/mosquitto/mosquitto.conf não existia anteriormente como um ficheiro real, o Docker poderia criar um diretório com o nome mosquitto.confMontar esse diretório no ficheiro de configuração esperado pelo contentor produz então exatamente o erro observado no tópico de origem.
Utilize o comportamento atual dos bind mounts do Docker para verificar se a origem é um ficheiro ou um diretório antes de iniciar o contentor.
A comunidade passou a mapear os diretórios do Mosquitto
Um autor da resposta partilhou uma definição Compose que mapeava três diretórios persistentes:
- diretório de configuração do anfitrião →
/mosquitto/config - diretório de dados do anfitrião →
/mosquitto/data - diretório de registos do anfitrião →
/mosquitto/log
Isto evita a montagem frágil de um “único ficheiro que pode ainda não existir” e fornece ao Mosquitto uma estrutura persistente normal.
O ficheiro de configuração ainda tem de existir dentro do diretório de configuração
Mapear o diretório não cria automaticamente uma configuração válida do Mosquitto. O autor da resposta disse ao utilizador para colocar mosquitto.conf no diretório de configuração mapeado antes de iniciar o broker.
Numa nova implementação, crie primeiro a configuração como um ficheiro real e, em seguida, monte o respetivo diretório-pai ou utilize a opção mais explícita do Docker --mount sintaxe, que falha em vez de criar silenciosamente um diretório de origem em falta.
A instalação personalizada do CasaOS pode expressar a mesma estrutura sem um comando docker run bruto
A comunidade orientou o utilizador na importação de uma definição Compose através do fluxo de trabalho de aplicação personalizada do CasaOS. Mais tarde, o utilizador instalou um pacote Mosquitto de uma loja de aplicações comunitárias e indicou que funcionou imediatamente.
Esse resultado confirma que o próprio anfitrião Docker conseguia executar o Mosquitto; o problema anterior era de configuração, não uma falha na reinstalação do CasaOS.
Um broker em execução ainda precisa de autenticação MQTT e configuração do listener
O utilizador de origem perguntou então porque é que o Node-RED não se ligava e se o Mosquitto utilizaria automaticamente o nome de utilizador e a palavra-passe do terminal. Não utiliza. A autenticação MQTT é configurada pelo próprio Mosquitto através da respetiva configuração e dos ficheiros de palavras-passe.
Não assuma que um estado verde do contentor significa que o broker está pronto para clientes não autenticados.
O fuso horário foi um detalhe final da configuração do contentor
Depois de instalar um pacote comunitário funcional, o utilizador ainda teve de adicionar o valor de ambiente adequado para o fuso horário. Esse é um detalhe da aplicação/do runtime, não uma prova de outra falha na instalação do Docker.
Perguntas frequentes sobre erros do Docker do Mosquitto
O Docker não conseguiu descarregar o eclipse-mosquitto?
Não. O resultado da origem mostra que a imagem foi descarregada com êxito.
Porque é que o contentor não conseguiu iniciar?
A montagem bind tinha uma incompatibilidade entre ficheiro e diretório em torno de mosquitto.conf.
Porque é que um ficheiro do anfitrião em falta pode tornar-se num diretório com docker -v?
do Docker --volume o comportamento cria a origem do anfitrião em falta como um diretório, o que pode quebrar uma montagem bind de ficheiro para ficheiro.
A reinstalação do CasaOS resolveu o problema?
Não. O utilizador acabou por conseguir depois de utilizar uma configuração correta da aplicação/do contentor.
