Windowsのアップデートで勝手に再起動された後、PowerShellからwslを開くと、毎回こんな表示が出るようになりました。
wsl: Processing /etc/fstab with mount -a failed.
原因は、この環境でCodexの補助ファイル用に追加されていたマウント設定が、Cドライブの準備より先に実行されることでした。Linux側のフォルダを、WSL内のWindows側のパスから参照するための個別設定です。
修正したのは、/etc/fstabのその1行です。オプションのbind,nofailにnoauto,x-systemd.automountを追加し、Cドライブの準備後、対象パスへアクセスした時にsystemdがマウントする設定へ変えました。
設定の変更後、Ubuntuを完全停止して起動し直すと警告が出なくなりました。 通常のwsl起動と、実際に使っているフォルダのマウントまでCodexで確認しました。
変更するのは、fstabのこの1行
私の環境はWSL 2.7.13.0、Ubuntu 24.04です。/etc/wsl.confではsystemd=trueが設定されていました。今回の変更は、Linux側のフォルダを/mnt/c/...へつなぐbindマウントがある構成を対象にしています。
以下のコードとログは、ユーザー名を公開用の例へ置き換えています。linuxuserはWSL側、winuserはWindows側のユーザーフォルダ名です。それぞれ自分のパスに合わせて読み替えます。
変更前はこうでした。
/home/linuxuser/.cache/codex-wsl-arg0 /mnt/c/Users/winuser/.codex/tmp/arg0 none bind,nofail 0 0
変更後はこうです。
/home/linuxuser/.cache/codex-wsl-arg0 /mnt/c/Users/winuser/.codex/tmp/arg0 none bind,noauto,nofail,x-systemd.automount 0 0
noautoでWSL起動時のmount -aからこの行を外し、x-systemd.automountでアクセス時のマウントをsystemdに任せます。この組み合わせでは、systemd側の自動マウントは起動対象になります。systemd.mountの公式資料
1. バックアップを取り、該当行を編集する
WSLのターミナルで、変更前のファイルを保存してから編集します。バックアップ名は既存のファイルと重ならないものを使います。
sudo cp -a /etc/fstab /etc/fstab.before-codex-automount
sudo nano /etc/fstab
対象行のオプションを上の設定へ変更して保存します。systemctl daemon-reloadでsystemdに設定を読み直させ、findmnt --verifyでfstabの記述を確認します。
sudo systemctl daemon-reload
sudo findmnt --verify --verbose
findmntでエラーや警告が出た場合は、その内容を直してから次へ進みます。
2. Windows側からUbuntuを終了し、起動し直す
設定を保存して、もう一度wslを実行するだけでは、この手順は完了しません。Ubuntu自体を完全停止します。
対象のUbuntu上で動くシェルや開発サーバーも終了するため、先に作業を保存します。 PowerShellでディストリビューション名を調べ、対象だけを終了・起動します。私の環境の名前はUbuntu-24.04です。
wsl -l -v
wsl --terminate Ubuntu-24.04
wsl --distribution Ubuntu-24.04
exitでシェルを閉じても、WSL自体が動き続ける場合があります。ここでは、Microsoftが案内する--terminateで対象のUbuntuを停止します。
3. 警告が出ないことと、マウント先を確認する
起動時のfstabエラーが消えたかを見てから、WSL内で対象のパスへアクセスします。
ls -ld /mnt/c/Users/winuser/.codex/tmp/arg0/.
findmnt --mountpoint /mnt/c/Users/winuser/.codex/tmp/arg0
findmntは、指定した場所に何がマウントされているかを調べるコマンドです。マウント元に/home/linuxuser/.cache/codex-wsl-arg0を含むext4の行が出れば、意図したLinux側のフォルダへつながっています。
復元が必要なら、WSL内でバックアップを戻します。その後、作業を保存して手順2の停止・起動を行います。
sudo cp -a /etc/fstab.before-codex-automount /etc/fstab
sudo systemctl daemon-reload
起動後のmountは成功していた
最初は「Windowsのアップデートで再起動されたからかも」と考えていました。WSL内で、fstabの設定をまとめてマウントするsudo mount -avを実行しました。続けてecho $?で直前のコマンドの終了コードを調べると、0でした。
出力自体は問題ないのでexitしてWindows側からもう一度wslを実行すると、同じエラーが出ます。そこで、Codexに原因調査と修正を依頼しました。AIは便利だね。
/etc/fstabに有効な設定は、先ほどのCodex用bindマウント1件だけでした。Linux側のフォルダを、WSL内の/mnt/c/...というパスからも同じ内容として使う設定です。
原因は、Cドライブが見える前のマウントだった
Codexは、Linuxの起動やサービスの動作ログを読むjournalctlで、起動時のエラーを調べました。次のコマンドで、起動時のマウントエラーをログから探しました。
journalctl -b --no-pager --grep='mount point does not exist|ConfigMountFsTab|/bin/mount failed'
WSLでは、Ubuntuを停止・起動しても過去のエラーがこのログに含まれる場合があります。修正後の確認は、手順3の起動時の表示とマウント状態で行います。
ログに出ていたのは、このエラーでした。ユーザー名を置換した抜粋です。
/mnt/c/Users/winuser/.codex/tmp/arg0: mount point does not exist.
起動時には、マウント先が見つかっていませんでした。
手元と同じWSL 2.7.13の実装では、/etc/fstabを処理してからWindowsドライブを自動マウントします。今回の設定は、Cドライブの下にあるパスを、その準備より先に使おうとしていました。起動後には手動のマウントが成功した理由も、この順番で説明できます。
途中で、マウント先フォルダを自動作成する方法も試しましたが、必要だったのはCドライブの準備後にマウントすることでした。そこで、フォルダ作成の追加をやめ、systemdに任せる設定へ変更しました。
再起動後、エラーは解消した
設定を変えた後も、動いているUbuntuに入り直すだけでは、同じ警告が表示されました。そこで対象のUbuntuをwsl --terminate Ubuntu-24.04で完全停止し、起動し直しました。
2026年10月18日、Codexが実際の作業環境で次を確認しました。
- WindowsのPowerShellから引数なしの
wslを実行しても、fstabの警告が出ない。 - 対象パスへアクセスすると、systemdのautomountとbindマウントがどちらも
activeになる。 - マウント先が、意図したLinux側の元フォルダと同じフォルダを指している。
起動後にコマンドが通るので、その時点では設定に問題がないように見えました。起動ログを読むと、見るべきだったのはフォルダの有無と処理の順番でした。
コメント