Dev Container内のファイルがroot所有になっていた——原因不明のまま解決した話
何が起きたか
VS CodeのDev Container環境で、既存のファイルを編集・保存しようとしたらエラーが出ました。
Failed to save 'xxx.md': Unable to write file '...'
コンテナ内で ls -la を確認すると、こういう状態になっていました。
-rw-r--r-- 1 root root 3343 May 28 07:57 05_devcontainer_container_name_fix.md
-rw-r--r-- 1 root root 6419 May 28 08:06 02_terraform_s3_backend_chicken_egg.md
...
-rw-r--r-- 1 vscode vscode 15613 May 28 11:51 011_lambda_canary_deploy_terraform_github_actions.md
root 所有のファイルが大量にあり、現在のログインユーザーである vscode から書き込めない状態でした。
タイムスタンプを見ると、root 所有のファイルは May 28 02:15〜08:06 に集中して生成されており、vscode 所有の 011_...md だけが 11:51 と明らかに後から作られたものでした。
解決策
まず権限を修正して、とりあえず作業できる状態に戻しました。
sudo chown vscode:vscode docs/zenn/*.md
再発防止として、.devcontainer/devcontainer.json に以下を追加しました。
"postCreateCommand": "sudo chown -R vscode:vscode /workspaces"
コンテナ再構築のたびに所有者をリセットするようにしておけば、同じ問題は起きにくくなります。
原因の仮説（真相は不明）
なぜ root 所有のファイルが大量に生成されたのか、はっきりした原因は特定できていません。
ただ、いくつかの仮説が考えられます。
仮説①: Claude DesktopのMCPサーバーがrootで動作していた
このプロジェクトではClaude DesktopのMCPサーバー（filesystemサーバー）をDev Container内で動かしており、大量のドキュメント読み込みとファイル生成をClaude Desktopに任せていました。
MCPサーバーが root ユーザーで動作していた場合、生成されるファイルはすべて root 所有になります。
devcontainer.json の remoteUser が正しく設定されていても、MCPサーバーのプロセスが別ユーザーで起動している可能性は排除できません。
仮説②: remoteUser 未設定でrootとして作業していた時期があった
devcontainer.json に remoteUser: "vscode" を設定していなかった時期にコンテナを起動していた場合、Dockerのデフォルト動作でrootとしてログインします。
その状態でファイルを作成・編集していれば、root 所有のファイルが積み上がっていきます。
タイムスタンプのパターン（02:15〜08:06 はroot、11:51 はvscode）は、この時期に remoteUser の設定を追加してコンテナを再構築したことを示している可能性があります。
仮説③: API制限による中途半端な停止
Claude Desktopに大量の作業を任せていた途中で、APIの利用制限に当たって処理が止まりました。
その時点でDev Containerの設定変更や devcontainer.json の修正が完了していなかった場合、中途半端な状態でファイルが残った可能性があります。
結局のところ
3つの仮説が組み合わさっている可能性もあります。今回が初めてこの問題が起きたのは、Claude Desktopに大量のファイル操作を任せたことが引き金になったのではという感覚はあるものの、確証はありません。
MCPサーバーをコンテナ内で動かす際は、どのユーザーでプロセスが起動しているかを意識しておく必要があります。Claude Desktopのような外部エージェントにファイル操作を大量に任せる場合は、終了後に所有者確認をする習慣をつけておくのが無難かもしれません。
# 作業後の確認コマンド
ls -la <作業ディレクトリ> | grep root
root 所有のファイルが出てきたら早めに chown で直しておくと、後で保存エラーに気づいて慌てずに済みます。
Discussion