症状：SSHではリモートMacに入れるのに、docker psがDocker daemonに接続できない。 最短解決策：先に再インストールせず、Docker Desktopの起動状態、同じmacOSユーザーのログインセッション、Docker Context、Socketの順に証拠を確認してください。

この記事は、WindowsやLinuxの端末からSSHまたはVNCでリモートMacを操作し、Docker Desktopを開発・ビルド・イメージ公開に使う人向けです。コンテナ用のmacOSノードを管理するDevOpsエンジニアや、再起動後も無人運用できるか判断したい人にも適しています。

まず故障箇所を4つに分けます

SSHでログインできることが証明するのは、macOSのRemote Loginが機能していることだけです。Docker Desktopのバックエンド、ユーザーセッション、Socket、コンテナネットワークまで正常だとは限りません。AppleのRemote Loginを有効にする公式手順でも、SSHはMacへのリモートアクセス機能として説明されています。

最初の5分で、次のように現象を分類してください。

<
見えている症状先に確認する証拠主な故障層
dockerコマンドが見つからないcommand -v docker、echo "$PATH"CLIのPATHまたはインストール
Docker Desktopが起動していないdocker desktop status、プロセス一覧アプリまたはユーザーセッション
daemonに接続できないdocker context show、Socketの存在Context、Socket、ユーザーの不一致
コンテナは起動するが外部から到達できないdocker ps、ポート、プロキシ設定コンテナネットワーク、公開ポート、認証
Docker Desktop CLIには、起動、停止、再起動、状態確認、ログ取得、診断のサブコマンドがあります。利用できるコマンドはインストール済みバージョンによって異なるため、docker desktop versionも最初に記録します。[Docker Desktop CLIの公式リファレンス](https://docs.docker.com/desktop/features/desktop-cli/)で当日の対応状況を確認してください。

SSH接続後にアプリとCLIの状態を確認します

SSHで入った直後に、いきなりsudo dockerを実行しないでください。Docker Desktop for Macは、通常のmacOSユーザーが起動するアプリであり、コンテナ内のroot権限をMac本体のroot権限と混同することも避ける必要があります。

次の順で、読み取り専用の確認を行います。

whoami
echo "$HOME"
command -v docker
docker --version
docker desktop version 2>/dev/null || true
docker desktop status 2>/dev/null || true
ps aux | grep -i '[d]ocker'
command -v dockerが空なら、Docker Desktop本体より先にCLIのPATHを調べます。Dockerの公式資料では、CLIツールを/usr/local/binまたはユーザー用の$HOME/.docker/binへ置く構成が説明されています。後者を選んだ場合は、シェルのPATHへ追加しないとSSHセッションから見えません。[macOSの権限とCLI配置に関する公式説明](https://docs.docker.com/desktop/setup/install/mac-permission-requirements/)を基準にしてください。 <
確認結果判断次の操作
CLIがないPATHまたはCLI配置の問題VNCでDocker DesktopのCLI設定を確認
statusが停止中Desktop未起動同じユーザーのGUIセッションを確認後、docker desktop start
statusが実行中だがdocker info失敗ContextまたはSocketの問題Context、DOCKER_HOST、Socketを照合
docker info成功、コンテナだけ失敗Desktop本体は稼働ポート、認証、イメージのアーキテクチャを調査

初回認証とユーザーセッションを切り分けます

Docker Desktopの「ログイン時に起動」は、macOSユーザーのログインセッションに関係する設定です。システム全体で常に動く独立したLinux daemonを登録する設定ではありません。AppleのService Managementでも、Login ItemやLaunchAgentはログイン中のユーザーセッションで動作し、LaunchDaemonとは実行コンテキストが異なると説明されています。AppleのService Management資料を確認してください。

そのため、次の状態ではSSHだけで完全な初回起動ができない場合があります。

  • 初回起動時の権限確認がまだ終わっていない
  • Docker Desktopの設定移行画面が表示されている
  • Keychainや補助プロセスの許可をVNC画面で求められている
  • SSHユーザーと、Docker Desktopを起動したGUIユーザーが異なる
  • 再起動後、macOSのユーザーがログインしていない
初回だけはVNCで対象ユーザーへログインし、Docker Desktopを起動して認証と権限確認を完了させます。その後、同じユーザーでSSH接続し、次を実行します。 
docker desktop status
docker desktop restart
sleep 10
docker desktop status
docker info
docker desktop restartが完了しても、docker infoが成功するまでを復旧完了とは扱いません。Docker Desktop CLIの状態表示はアプリの状態を示しますが、CLIが実際にdaemonへ到達できるかはdocker infoで別に確認する必要があります。

ContextとDocker Socketの対応を確認します

SSHでDocker daemonへ接続できない場合、もっとも多い切り分け対象がユーザー、Context、Socketの不一致です。Docker Desktop for Macでは、現在のContextがSocketの参照先を決めます。公式資料では、Docker Desktop起動時にdesktop-linux Contextが設定され、ユーザーごとのSocketを利用する仕組みが説明されています。

次のコマンドで、環境変数による上書きも含めて確認します。

whoami
echo "$HOME"
docker context ls
docker context show
docker context inspect "$(docker context show)"
echo "${DOCKER_HOST:-未設定}"
ls -l "$HOME/.docker/run/docker.sock"
ls -l /var/run/docker.sock 2>/dev/null || true
docker info
<
状態典型的な原因修復方針
DOCKER_HOSTが別ユーザーのパスを指すシェル設定やCIスクリプトの残骸一時的にunset DOCKER_HOSTして再確認
ContextがdefaultのままDesktop起動前、またはContext切り替えdocker context showを確認してDesktop起動後に再試行
ユーザーSocketがないDesktop未起動、別ユーザーで起動VNCで同じユーザーをログインさせる
/var/run/docker.sockだけがない任意Socketリンクを作っていない構成Docker Desktopの設定またはDOCKER_HOSTを確認
sudo dockerだけ成功するrootの環境と通常ユーザーの環境が分裂sudoを外し、対象ユーザーのContextを修正
/var/run/docker.sockを手作業で作れば直るとは限りません。macOSの/var/runは再起動時に内容が消えるため、Docker Desktopの設定で既定Socketリンクを有効にした場合でも、起動時に再作成する仕組みが必要です。公式資料にも、既定Socketリンクを使わない場合はユーザーSocketをDOCKER_HOSTで指定する構成が示されています。無関係なSocketファイルを作るのではなく、変更前に設定を保存し、変更後に新しいSSH接続で検証してください。 
cp "$HOME/.docker/config.json" \
  "$HOME/.docker/config.json.bak.$(date +%Y%m%d%H%M%S)"

unset DOCKER_HOST
docker context show
docker info

権限、認証、ネットワークを別々に検証します

permission deniedという文字だけで、すぐroot権限を追加するのは危険です。Docker Desktopでは、CLIの配置、1024未満の特権ポート、補助プロセス、Keychainに保存されたレジストリ認証、プロキシ設定が別々の境界になります。[Docker公式のmacOS権限説明](https://docs.docker.com/desktop/setup/install/mac-permission-requirements/)では、特権ポート用の補助機能とDocker本体の権限が分けて記載されています。

次のように、最小構成から確認します。

docker run --rm hello-world
docker pull alpine
docker run --rm alpine uname -a

ここで失敗した場合の読み方は次のとおりです。

  • hello-worldの取得前に失敗する：daemon、Socket、レジストリ接続を確認します。
  • 取得時に認証を求められる：対象ユーザーのDocker認証情報とKeychainを確認します。
  • イメージ取得後にポート公開だけ失敗する：1024未満のポートや既存プロセスを確認します。
  • コンテナは動くが外部から接続できない：Mac側の待受、ポート転送、プロキシ、ファイアウォールを分けて調べます。
プライベートレジストリを使う場合、SSHの非対話シェルへ平文トークンを直接書かないでください。CIのシークレット管理機能や、対象ユーザーの認証ストアを使い、ログに資格情報が出ない方法でdocker loginを実行します。

ログを確認する場合は、まずDocker Desktop CLIを使います。

docker desktop logs
docker desktop diagnose

診断コマンドが利用できないバージョンでは、macOSのConsoleやDocker Desktopのログディレクトリを使います。daemon側のログとしては、~/Library/Containers/com.docker.docker/Data/log/vm/init.logが案内されています。Docker公式のトラブルシューティングとdaemonログの確認方法を参照してください。

再インストール前にインストール状態を確認します

アプリが起動しない場合でも、すぐにDocker Desktopを削除しないでください。公式トラブルシューティングでは、アンインストールやデータ初期化によって既存のコンテナ、イメージ、ボリューム、設定が失われる可能性が示されています。まずアプリの場所、CPUアーキテクチャ、macOS対応範囲、ログのエラーを記録します。Docker公式のトラブルシューティング項目で、削除を伴う操作の影響範囲を確認してください。

uname -m
sw_vers
ls -ld /Applications/Docker.app
test -x /Applications/Docker.app/Contents/MacOS/Docker && echo "Docker.app本体あり"

Apple SiliconのMacでは、x86_64向けツールにRosetta 2が必要になるケースがあります。Docker公式インストール要件では、サポート対象のmacOS、最低メモリ要件、Apple Silicon環境でのRosetta 2に関する条件が案内されています。最低要件や既知の問題は更新されるため、インストール前に当日のMac向け公式インストール要件を確認してください。

再インストールへ進む条件は、次のような証拠がそろった場合です。

  • /Applications/Docker.appが欠損または実行不能
  • ログにアプリ破損や起動不能を示す明確なエラーがある
  • macOSとDocker Desktopの対応範囲が一致している
  • 設定、認証情報、Composeファイル、ボリュームのバックアップがある
  • 現在のバージョン固有の既知障害をリリースノートで確認した

再起動後の復旧をチェックリストで判定します

「たまに起動する」と「長期運用できる」は別の評価です。次の手順を、実際のノード再起動後に同じユーザーと同じSSH経路で実施してください。

  • [ ] SSHで対象のmacOSユーザーにログインできる
  • [ ] whoamiとecho "$HOME"が想定ユーザーの値になる
  • [ ] command -v dockerでCLIのパスが確認できる
  • [ ] docker desktop statusが実行中を示す
  • [ ] docker context showが想定Contextを示す
  • [ ] $HOME/.docker/run/docker.sockの有無を確認できる
  • [ ] docker infoがエラーなしで完了する
  • [ ] docker run --rm hello-worldが成功する
  • [ ] 業務用のテストコンテナが起動する
  • [ ] 必要なポートへ、許可された接続元から到達できる
  • [ ] VNCでの手動ログイン、権限確認、設定修復が必要か記録する
  • [ ] 失敗時にdocker desktop logsまたは診断情報を保存できる
<
評価条件運用判断
3点SSH、Desktop、daemon、テストコンテナが再起動後に自動復旧継続運用候補
2点VNCログイン後に復旧し、手順が再現可能半自動運用として採用
1点毎回SocketやContextを手動修正する構成を見直す
0点GUI認証や権限確認がないと復旧しない無人ノードには不適
上の点数は公式の保証値ではなく、運用可否を判断するための社内評価基準です。Docker Desktopがユーザーセッションに依存する構成では、完全なSSH-only運用や、ユーザー未ログイン状態からの無人復旧を前提にしないでください。ログイン時に起動する項目は、macOSの「一般」から「ログイン項目と機能拡張」で管理できますが、ログイン項目とシステムデーモンは同じものではありません。[Appleのログイン項目に関する公式説明](https://support.apple.com/en-mo/guide/mac-help/-mh15189/mac)も併せて確認してください。

リモートMacを長期運用する前に構成を決めます

リモートMacでDocker Desktopを使う場合、Linuxクラウドサーバーのように「OSが起動すればdaemonも必ず無人起動する」と考えないことが重要です。VNCによる初回認証が可能か、同一ユーザーでSSHを使えるか、再起動後にSocketとテストコンテナが戻るかを、契約前または構築前に確認してください。

Apple Silicon向けのコンテナやXcode連携を含む開発環境を比較するなら、MACGPUのリモートMac環境で利用形態を確認し、必要に応じてApple Silicon Macの利用案内も参照できます。接続経路やノードの受け渡し条件が運用要件に合わない場合は、性能より先に復旧手順が成立しません。

現在の構成が手元のMac miniや自前ホストであれば、物理機器を直接管理できる反面、停電、OS更新、ストレージ障害、外部公開経路、VNCやSSHの復旧を自分で維持する必要があります。Linuxクラウドだけで代替する場合は、macOS専用ツールチェーン、Apple Silicon固有のイメージ、Xcode関連の処理を別経路へ逃がさなければなりません。

短期のビルド検証や一時的なコンテナ開発では、VNC、SSH、常時稼働を前提にした実機のリモートMacをMACGPUで借り、今回のチェックリストを納品時の受け入れ条件にする方が、環境構築と復旧作業を分離しやすい選択です。長期の安定した高負荷運用や物理インターフェースが必要な場合は自前のMacが適するため、Docker Desktopの再起動と復旧条件を先に測定してから判断してください。