MinIO接続拒否エラーの解決 — NetDrive

セルフホストのMinIOクラスターにNetDriveを接続しTestをクリックすると、緑のチェックマークの代わりに「Connection refused」と表示される。ドライブはマウントされず、エラーからは問題がエンドポイントなのか、認証情報なのか、間のネットワーク経路なのか判断できない。ほぼ必ず、次の3つのいずれかに行き着く。ポート番号の誤り、ファイアウォールの遮断、コンソールURLとAPI URLの取り違えだ。

セルフホストのS3互換ストレージをドライブとしてマウント

NetDrive を使えば Google Drive、OneDrive、S3、SFTP、WebDAV などが Windows と macOS でネイティブドライブとして表示されます — 同期も、まるごとダウンロードも不要です。

• MinIOおよびあらゆるS3互換エンドポイントに接続
• Testボタンでマウント前に接続を検証
• 同じ接続項目でWindowsとmacOSの両方に対応

WindowsmacOS

NetDriveをダウンロード →

無料トライアル。永久ライセンスとサブスクリプションプランあり。

「Connection Refused」が認証情報エラーではなくネットワークエラーである理由

「Connection refused」は、NetDriveがAccess KeyやSecret Keyを確認する段階に到達する前に発生する。エンドポイント自体へのTCP接続そのものが拒否されている状態であり、NetDriveが試みたアドレスとポートでは何も待ち受けていないか、マシンとMinIOサーバーの間の何かが積極的にブロックしている。これは、NetDriveがMinIOに到達しMinIOが拒否したことを意味する「Access Denied」とは異なる失敗モードだ。「Connection refused」が表示された場合は、まずネットワーク経路を修正すること。このレイヤーが機能しない限り、認証情報の問題はそもそも表面化しない。

確認1: コンソールポートとAPIポートの違い

MinIOは2つの独立したポートで2つのサービスを動かしている。S3 API(デフォルト9000)とWebコンソール(デフォルト9001)だ。NetDriveが必要とするのはAPIポートであり、Endpointフィールドにコンソールポートを指定すると、接続が完全に拒否されるか、まったく別のサービスに接続してしまう。

1. Open NetDrive → MinIOドライブの歯車アイコンをクリックして設定を開く。
2. Endpointフィールドが:9001ではなくhttp://192.168.1.50:9000のようになっていることを確認する。
3. MinIOインスタンスがAPIにどのポートを使用しているか不明な場合は、MINIO_API_PORT環境変数か、サーバー起動時に使われた--addressフラグを確認する。コンソールには通常、独立した--console-addressフラグが使われている。

確認2: ファイアウォールとDockerのポート公開設定

ポート番号が正しいにもかかわらず「Connection refused」が出る場合は、NetDriveとMinIOホストの間の何かが接続をブロックしている。

• Dockerデプロイ: コンテナが実際にポートを公開しているか確認する。docker run -p 9000:9000 ...や、compose ファイル内の同等の設定だ。ポートが公開されていないMinIOコンテナは、docker ps上では正常に見えてもホスト外からは到達できない。
• ホストのファイアウォール: Linuxではufw statusまたはiptables -Lで、インバウンド9000をブロックするルールがないか確認する。MinIOをホストするWindows Serverでは、Windows Defender ファイアウォールのインバウンドルールを確認する。
• ネットワークセグメンテーション: NetDriveがMinIOホストと異なるVLANやサブネット上で動作している場合は、両者間のルーティングでそのポートが許可されているか確認する。オフィスでサーバーがワークステーションと別セグメントに置かれている場合によく見られる盲点だ。

問題がNetDrive側かネットワーク側かを切り分ける簡単な方法として、同じマシンからブラウザを開きhttp://<endpoint>:9000/minio/health/liveにアクセスしてみる。ブラウザからも接続できない場合、問題はNetDriveの設定ではなく、完全にネットワーク経路側にある。

確認3: 自己署名証明書を使うHTTPSエンドポイント

MinIOエンドポイントが自己署名証明書または内部CA証明書を使うリバースプロキシの背後でhttps://を利用している場合、一部のTLSハンドシェイク失敗が証明書警告ではなく一般的な接続失敗として表面化することがある。NetDriveを実行しているマシンから証明書チェーンが有効であることを確認する。内部CAの場合、そのマシンの信頼ストアにCA証明書がインストールされている必要がある。診断手順として、内部ネットワーク上で一時的にhttp://でテストし、エンドポイントとポート自体は正しいことを確認したうえで、証明書が信頼された時点でHTTPSを再度有効にする。

接続の再テスト

ポート、ファイアウォール、証明書の問題が解決したら次を行う。

1. Open NetDrive → Drive ManagerでMinIOドライブを選択する。
2. Endpointを再入力し、Path styleが有効になっていることを確認して(セルフホストのMinIOではほぼ常に、仮想ホスト形式のアドレッシングではなくこちらが必要)、Testをクリックする。
3. 緑のチェックはTCPとTLSの両レイヤーが機能していることを意味する。それでもドライブがマウントされない場合、残る原因はほぼ常に接続性ではなく認証情報かバケットの権限だ。

まとめ

MinIOドライブでの「Connection refused」は、ほとんどの場合ネットワーク層の問題だ。ポート番号の誤り、ファイアウォールやDockerの公開ルールによるアクセス遮断、あるいはHTTPSエンドポイントでの証明書の未信頼のいずれかである。まずポートとファイアウォールを確認すること。これらが大半のケースを占めるため、認証情報に問題があると決めつける前にここから取り組もう。セットアップ手順全体についてはMount MinIO on Windows with NetDriveまたはMount MinIO on macOS with NetDriveを参照してほしい。接続には成功したもののアクセスが拒否される場合は、Fix S3 Access Denied Errors with NetDriveが認証情報とポリシー側の問題をカバーしている。

— Steve, NetDrive