VMware vSphereで「NFS Error: cannot open volume」が出る原因と解決策まとめ（Windows Server 2003 NFS共有）

VMware vSphere（ESX/ESXi）でNFSデータストアを追加しようとした際に、NFS Error: cannot open volume や「Error during the configuration of the host」といったエラーに遭遇すると、設定が合っていそうでも先に進めず時間を溶かしがちです。特にNFSサーバーがWindows Server（とくに2003系）だと、権限やマッピング周りの癖があり、ネットワーク設定だけ整えても失敗するケースが目立ちます。
この記事では、よくある原因の切り分けと、最短で解決に近づく具体的な設定ポイントを、実務で使える形に整理します。

VMware vSphereで「NFS Error: cannot open volume」が出る原因と解決策まとめ（Windows Server 2003 NFS共有）

発生する症状：vSphere側で「cannot open volume」

典型的なエラーメッセージは次のような内容です。

「Error during the configuration of the host」
「Cannot open volume: /vmfs/volumes/xxxx-xxxx…」
NFSデータストア追加時に失敗して、マウントされない

重要なのは、このエラーが「ネットワーク疎通が完全にダメ」というより、NFSとしては到達できているが、サーバー側のエクスポート権限やユーザー権限の解釈で弾かれているときにも出る点です。

まず確認すべき前提：ネットワークとVMkernel

NFSマウントの失敗原因は大きく「通信」と「権限」に分かれます。通信側の基本を先に潰します。

ESX/ESXi側にNFS通信用のVMkernelポートがあるか
NFSサーバー（Windows側）へ疎通できるか（同一セグメント/ルーティング/MTU）
ESX/ESXiのファイアウォール、または外部FWでNFS関連がブロックされていないか

ただし、この段階をすべて満たしていても、今回のようにエラーが残ることがあります。次が本丸です。

原因の本命：Windows NFS共有の権限（RootアクセスとRW）

Windows Server 2003のNFS共有では、「誰としてアクセスしているか」の扱いがクセになります。vSphere（ESX 4.0世代を含む）はNFSアクセス時に、実質的にroot権限相当として扱われる挙動が絡みやすく、Windows側でそれを許可していないと、共有を見つけられてもマウントに失敗します。

このときの決定打になりやすいのが、NFS共有フォルダの設定で次を満たすことです。

共有フォルダのNFS権限が Read-Write（読み書き）
Rootアクセスを許可（rootを匿名に潰さない／root相当を拒否しない）

vSphere側の設定をいくら触っても直らない場合、Windows側のNFS共有タブ（またはServices for NFSの管理画面）で、アクセス許可が「読み取りのみ」になっていないか、rootアクセスが拒否されていないかを最優先で見直してください。

実務的なチェック手順（Windows側）

NFSとして公開しているフォルダを選ぶ
NFS共有（NFS Sharing）関連の設定画面を開く
アクセス権限を確認する
Read-Writeになっているか
Rootアクセス許可が有効か（設定項目名は環境により差があります）

この2点が揃うだけで、cannot open volume が消えるケースが多いです。

追加のヒント：イベントビューアの警告（User Name Mapping）

Windowsイベントビューアで、次のような警告が出ることがあります。

「User Name Mapping からマッピング情報を取得できない。30分後に再試行する」
Event ID: 1003

これは、Windows NFSがUNIXユーザー（UID/GID）とWindowsアカウントの対応付け（User Name Mapping）を期待しているのに、取得できない状態で起きがちです。
この警告が出ている環境では、NFSアクセスが「誰の権限で来たのか」をうまく解釈できず、結果としてマウントエラーに繋がることがあります。

ここでのポイントは、環境の思想をどちらかに寄せることです。

マッピングを正しく構成して厳密に運用する（本番向けに堅め）
rootアクセス許可や匿名アクセスの扱いを調整して、vSphereから確実にマウントさせる（検証や小規模で現実的）

Windows Server 2003のNFSは構成が古く、現代の感覚で「権限は揃ってるはず」と思ってもズレが出やすいので、警告が出ているなら権限周りが根っこにある可能性が高いです。

「設定したのに直らない」時の切り分けポイント

権限を直しても改善しない場合、次の順で潰すと迷いにくいです。

エクスポート（共有）対象のパスが正しいか（別フォルダを共有していないか）
ESX/ESXiが参照するNFSサーバーIPが正しいか（DNS名解決の揺れ含む）
NFS共有の許可クライアントにESX/ESXiのIPが含まれているか
WindowsのNFSサービスが安定稼働しているか（再起動で改善するケースもある）
可能なら、別の簡易NFSサーバー（Linux等）で同条件を試し、vSphere側の問題か切り分ける

特にWindows NFSは「共有設定画面では許可したつもりでも、実際には匿名扱いで拒否」という状態が起きやすいので、root許可とRWを最優先に疑うのが近道です。

まとめ：このエラーは「通信」より「権限」で詰まることが多い

NFS Error: cannot open volume は、VMkernelやポート開放など“いかにもネットワーク”な対策をやっても解決しないことがあります。Windows Server 2003のNFS共有では、vSphereからのアクセスがroot相当として扱われやすく、NFS共有の権限でRead-Writeを許可し、Rootアクセスを許可することが決定打になります。
イベントビューアにUser Name Mapping関連の警告が出ている場合も、権限解釈が噛み合っていないサインとして捉え、共有設定の見直しを優先してください。

この手順で直らない場合でも、ここで挙げた切り分け順に沿って確認すれば、原因を「vSphere側」「ネットワーク側」「NFSサーバー側（権限/マッピング）」のどこに閉じ込めるべきかが明確になります。