原文のユーザーはこの失敗を「クリーンインストール後にDockerがイメージをインストールできない」と解釈しました。しかし、ターミナル出力には実際には2つの別々の問題が示されていました。次を実行すると docker info 昇格した権限なしではDockerソケットへのアクセスに失敗しましたが、Docker権限でMosquittoコンテナを実行すると、正常にプルできました。 eclipse-mosquitto:latest。その後、コンテナは別の理由で失敗しました。バインドマウントが、ホストパスとコンテナパスを互換性のないファイル／ディレクトリの種類として扱おうとしたためです。
この違いは重要です。Debian、CasaOS、またはDockerを再インストールしても、間違った種類のファイルシステムオブジェクトを指すバインドマウントは修正されません。
問題1：通常のユーザーはDockerソケットにアクセスできなかった
最初の docker info 出力は次のとおりでした。
Dockerデーモンソケットへの接続中に権限が拒否されました
unix:///var/run/docker.sockこれは、シェルユーザーにDockerデーモンへ直接アクセスする権限がなかったことを意味します。同じコマンドは次の状態で正常に動作しました。 sudo、デーモン自体に到達できたことを証明しています。
これは、後で発生したMosquittoの起動エラーとは別の問題です。
Mosquittoイメージのダウンロードは正常に完了しました
Dockerは次のように報告しました。
Status: eclipse-mosquitto:latest の新しいイメージをダウンロードしましたしたがって、レジストリ、イメージ名、インターネット接続が直接の問題だったわけではありません。失敗は、Dockerがコンテナのファイルシステムを作成してバインドマウントを適用しようとしたときにのみ発生しました。
本当のエラーはファイルとディレクトリのマウントの不一致でした
コマンドは次のマッピングを試みました。
/etc/mosquitto/mosquitto.conf
→ /mosquitto/config/mosquitto.confその後、Dockerは次のように報告しました。
ディレクトリではありません
ディレクトリをファイルにマウントしようとしていますか（またはその逆ですか）？このメッセージは文字どおりに受け取るべきです。マッピングの片側が、コマンドで想定されていた種類ではありませんでした。
-vで間違った種類が自動的に作成される理由
現在のDockerドキュメントでは、-v/--volumeに関する簡単に陥りやすい落とし穴が説明されています。ソースパスが存在しない場合、Dockerはそれを自動的にディレクトリとして作成します。
したがって、 /etc/mosquitto/mosquitto.conf 実際のファイルとしてまだ存在していなかったため、Dockerは次の名前のディレクトリを作成できました。 mosquitto.confそのディレクトリをコンテナが想定する設定ファイルにマウントすると、元のスレッドで確認されたものとまったく同じエラーが発生します。
コンテナを起動する前に、Dockerの現在のバインドマウントの動作を使用して、ソースがファイルかディレクトリかを確認してください。
コミュニティはMosquittoのディレクトリをマッピングする方式に切り替えました。
回答者は、3つの永続ディレクトリをマッピングするCompose定義を共有しました。
- ホスト側の設定ディレクトリ →
/mosquitto/config - ホスト側のデータディレクトリ →
/mosquitto/data - ホスト側のログディレクトリ →
/mosquitto/log
これにより、まだ存在しない可能性がある「単一ファイルの不安定なマウント」を避け、Mosquittoに通常の永続レイアウトを使用させられます。
設定ファイルは設定ディレクトリ内にも存在する必要があります
ディレクトリをマッピングしても、有効なMosquitto設定が自動的に作成されるわけではありません。回答者はユーザーに次の場所へ配置するよう伝えました。 mosquitto.conf ブローカーを起動する前に、マッピングされた設定ディレクトリ内へ
新しくデプロイする場合は、まず設定を実際のファイルとして作成し、その親ディレクトリをマウントするか、Dockerのより明示的な --mount 構文では、存在しないソースディレクトリを黙って作成せず、エラーになります。
CasaOSのカスタムインストールでは、生のdocker runコマンドを使わずに同じ構成を指定できます
コミュニティは、CasaOSのカスタムアプリケーションワークフローを通じてCompose定義をインポートする手順をユーザーに案内しました。その後、ユーザーはコミュニティアプリストアからMosquittoパッケージをインストールし、すぐに動作したと報告しました。
この結果から、Dockerホスト自体はMosquittoを実行できたことが確認できます。以前の問題は設定であり、CasaOSの再インストールに失敗したことではありません。
ブローカーが起動していても、MQTT認証とリスナー設定は必要
その後、ソースのユーザーはNode-REDが接続できない理由と、Mosquittoが端末のユーザー名／パスワードを自動的に使用するのかを尋ねました。自動的には使用しません。MQTT認証は、設定ファイルとパスワードファイルを通じてMosquitto自体で設定します。
コンテナのステータスが緑色だからといって、認証なしのクライアントに対してブローカーの準備ができているとは限りません。
タイムゾーンはコンテナ設定の最後の詳細
動作するコミュニティパッケージをインストールした後も、ユーザーは適切なタイムゾーン環境値を追加する必要がありました。これはアプリケーション／ランタイムの詳細であり、別のDockerインストール失敗の証拠ではありません。
Mosquitto DockerエラーFAQ
Dockerはeclipse-mosquittoのダウンロードに失敗したのですか？
いいえ。ソースの出力から、イメージは正常にダウンロードされたことが分かります。
コンテナの起動に失敗したのはなぜですか？
バインドマウントで、ファイルとディレクトリの不一致が発生していました。 mosquitto.conf.
docker -vでは、存在しないホスト側ファイルがどのようにディレクトリになるのですか？
Dockerの --volume この動作により、存在しないホスト側のソースがディレクトリとして作成され、ファイル間のバインドマウントが壊れることがあります。
CasaOSを再インストールすると問題は解決しましたか？
いいえ。ユーザーは最終的に、正しいアプリケーション／コンテナ設定を使用して問題を解決しました。
