WORKGROUP環境のWindows Server 2019からNFS領域をマウントする方法

どうも、Tです。

ADドメインに参加していないWORKGROUP環境のWindows Server 2019がNFSクライアントになって、NFSをマウントして使う方法をまとめました。ユーザーマッピングのあたりとか次やるとき忘れそうなので。

やりたいこと

  • NFSサーバー(Linux系)でNFS領域を公開して、WindowsServerからNFS領域をマウントする
  • Windows Serverからファイルの読み書きが行えるようにする

環境

  • NFSクライアント:Windows Server 2019Windows バージョン1809
  • NFSサーバー:DELL EMC UnityVSA 5.0.0.0.5.116

NFSサーバーに勉強がてらUnityVSAを使いましたが、Linuxと変わらないです。

NFSサーバー側のNFSエクスポートとアクセス権の設定は事前に終わっている前提で進めるのでUnityのことに関しては記載しておりません。

操作はすべてAdministratorユーザーから行っています。

画像はWindows Server 2019で掲載していますが、Windows Server 2016でも同じ手順で行えました。

設定方法

NFSクライアント機能のインストール

Windows Server 2019がNFSを利用できるように機能の追加を行います。

サーバーマネージャー->管理->機能と役割の追加をクリックします。

次へをクリックします。

次へをクリックします。

次へをクリックします。

次へをクリックします。

「NFSクライアント」にチェックを入れ、次へをクリックします。

インストールをクリックします。

インストールが開始されます。

インストールが終わったら閉じるをクリックします。

Windowsユーザーマッピング

次にWORKGROUP環境のAdministratorとAdministaratorsグループを Linuxのroot ユーザー(uid:0) と root グループ (gid:0) にマッピングします。

ここから説明する方法は、Windows Server 2012以降から可能になっているものです。Windows Server 2008R2以前では、ADもしくはAD LDSが必要になります。

Linuxの/etc/passwdファイルと/etc/groupファイルを取得します。今回は、CentOS Linux release 7.6.1810のものを利用しています。

passwdファイルを下記のように書き換えます。Administratorを(uid:0)にマッピングしています。

#変更前
root:x:0:0:root:/root:/bin/bash
#root以下の行は割愛

#変更後
Administrator:x:0:0:root:/root:/bin/bash
#先頭1行以外は削除します。
passwd ファイルのエントリはユーザー名、UID、GID のみが参照され、ホーム ディレクトリやログイン シェルなどのエントリは無視されます。

groupファイルを下記のように書き換えます。Administratorsを(gid:0)にマッピングしています。

#変更前
root:x:0:
#root以下の行は割愛

#変更後
BUILTIN\Administrators:x:0:
#先頭1行以外は削除します。
group ファイルのエントリはグループ名、GID、グループ リストが参照されます。

passwdファイルとgroupファイルを以下のパスに配置します。

%SystemRoot%\system32\drivers\etc\

OSを再起動します。

※この後の手順が実施できな場合があるので、必ず再起動してください。

ユーザーマッピングの参考情報

今回はユーザー指定ですが、匿名ユーザーもレジストリを弄ることでUID、GUIの設定が可能なようです。

Windows Server 2008 R2 / 2012 R2 のNFSクライアント設定 — Memo ドキュメント

匿名ユーザのUID/GIDを変更する
デフォルトだと強制的に”4294967294(-2)”で固定されるのでレジストリで値を設定する。

レジストリエディタを起動し、下記を開く
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default
新規キーの追加で下記を追加する
AnonymousUid , 新規作成, DWORD値, 10進数でUID値を入力
AnonymousGid , 新規作成, DWORD値, 10進数でGID値を入力

NFSサーバーへの接続(NFS領域のマウント)

NFS領域をマウントします。

コマンドプロンプトを開いて下記コマンドを実行します。

mount <NFSサーバーのIPアドレスまたはホスト名>:<エクスポートパス> <Windows側で未使用のドライブラベル>

接続が完了するとデバイスとドライブの一覧にNFSの領域がマウントされます。

コマンドプロンプトでmountコマンドを実行すると接続情報が表示されます。UIDとGIDがマッピングを行った0になっていることが確認できます。

NFS領域にWindows_testファイルを作成して書込みしてみたところです。

Linuxから見たファイルはどうなっている?

下記はLinuxのNASクライアントからNFS領域をマウントして表示したところです。win_dirフォルダとwin_test.txtはWindowsクライアントから作成していますが見えて操作が行えます。所有者とグループがrootになっていることがわかります。

ユーザーマッピングがなぜ必要なのか?

ユーザーマッピングをせずにNFS領域をマウントした場合にどうなるのか試しました。

ユーザーマッピングをしていない場合も、mount <NFSサーバーのIPアドレスまたはホスト名>:<エクスポートパス> <Windows側で未使用のドライブラベル>NFS領域をマウントすることが可能です。linux_testファイルは、Linuxクライアントから作成しましたが、開いて閲覧することも可能です。

厳密には、Linuxクライアントで作成したファイルのアクセス権の設定によります。今回は、デフォルトで作成した場合を記載しています。

しかし、ファイルやフォルダの新規作成、変更を行おうとすると「この操作を実行するアクセス許可が必要です」が表示され行うことができません。

この状態でmountコマンドを見てます。ユーザーマッピングをしていない状態でつなげるとWindows Server 2019はUID-2、GID-2という存在しないユーザーとグループで接続していることになります。

なので、書込みやroot権限が必要な読込を行う際は、ユーザーマッピングを行う必要があります。

参考

WindowsからNFSサーバに接続する設定手順 | さくらのクラウド マニュアル
WindowsからNFSサーバに接続する手順の説明です。
Windows Server 2012 以降の NFS 利用時のユーザーマッピングについて

まとめ

ちょこちょこ調べていましたが、エンタープライズストレージでNAS機能を備えている製品などでも、AD環境のあるユーザーマッピングは基本されているようですが、WORKGROUP環境だとマチマチですね。

WindowsからNFS使うのはあまりなかった環境でした。