テクノロジー · 実用ガイド
Docker が資格情報ヘルパーを見つけられない？設定・実行ファイル・呼び出し元を追跡する
Docker が読んだ設定と選んだ docker-credential-*、そして同じユーザー、WSL、sudo、サービスが実行できるかを証明してからストアを変更します。
このエラーが示すのは壊れたパスワードではなく実行できないプログラムです。Docker は docker-credential-desktop や docker-credential-gcloud などを選びましたが、Docker を起動したプロセスが実行できません。config.json の削除や credsStore の誤記は呼び出しを隠しても、安全なストアまで無効にすることがあります。
元のファイルを保持し、実際に読まれた設定と対象レジストリの項目を確認し、接尾辞を docker-credential-<接尾辞> に変換します。同じユーザー、シェル、sudo、WSL、サービスから見えるかを調べ、証明できた境界だけを直します。
呼び出し元と有効な設定を固定する
失敗した正確なコマンドとレジストリを記録し、whoami、HOME、DOCKER_CONFIG、シェルまたはサービス、sudo と WSL の有無を確認します。編集前に config.json を非公開でバックアップし、auth、トークン、ヘルパー出力をログへ貼らないでください。
秘密でない選択構造だけを確認します。対象レジストリの credHelpers を先に見て、次に credsStore を見ます。root、サービス、別の Windows/WSL ユーザーなら、その呼び出し元のファイルを調べます。
設定値を一つの実行ファイルへ変換する
credHelpers が対象に gcloud を選ぶなら docker-credential-gcloud、credsStore が desktop なら docker-credential-desktop が期待されます。接尾辞は Docker が実行する名前であり、推測したパッケージ名ではありません。
同じ呼び出し環境から command -v、type -a、または同等の方法で正確なファイルを探します。無い場合は、古い Docker Desktop ブリッジと意図した単独ヘルパーを区別してから導入やリンクを検討します。
PATH 障害とヘルパー内部障害を分ける
バージョンや一覧など、秘密を表示しない文書化済みの確認を使います。公式の get テストが返す Secret は機密として扱い、共有ログへ保存しません。
シェルが起動できなければ導入か PATH を修復します。起動後にキーチェーン、pass、gpg、Desktop ブリッジ、クラウド認証のエラーが出るなら Docker 設定の変更を止め、そのヘルパーを調査します。
証明した最小の境界だけを直す
レジストリキーや接尾辞の誤りは狭い設定修正、公式ヘルパーの欠落は正確なバイナリの復元、ユーザー、root、WSL、サービスの差は実際のプロセスの HOME、DOCKER_CONFIG、PATH をそろえることで直します。
credsStore を credStore に変える恒久策は使いません。後者は有効なストアキーではなく無視されます。別の文書化済み認証方式を意図して選ぶ場合だけ、設定を削除または置換します。
元の経路を再試行して成功を定義する
同じシェル、サービス、CI、WSL を新しく起動し、同じレジストリに対する元の Docker コマンドを実行します。ヘルパー実行エラーが消え、意図したストアへ到達し、別ユーザーや設定の偶然ではないことが成功条件です。
予期しないコピーが選ばれる、設定がすぐ再生成される、sudo や自動化だけで再発する場合は停止し、呼び出し元の一覧を比較し直します。所有者と対応ヘルパーが分かるまで資格情報を削除しません。
