NFSとSMBを混在するときの注意点

こんにちは。辻村です。以前書かせたいただいた記事のアンコールです。以前の記事に少し手を加えてお送りします。NFSとSMB を混在するときの注意点です。

はじめに

NASをはじめとして、同じストレージをネットワーク越しに共有する際に NFSやSMBといったプロトコルを使う。最近は、NFSとSMB両方に対応している製品が出ていて、同じ共有(share)を複数のプロトコルで使うことも出来る。この場合、どう気をつけたらトラブルが防げるのだろうか？以下は私なりのメモである。

注意点1：必要もないのに NFS と SMB の両方を使わない

私も含めて日本人は、あるだけの機能をできるだけ使おうとする人が多い。狭い範囲での体感だが、海外の人はいろんなことに使えるけれども場面に応じて使う機能を限定して使っているように思える。NFSとSMBが使えるからといって「使わなければいけない」わけではない。当然だが、全クライアントが NFS を使えるのに、わざわざ SMB を混在したり、逆に SMB で大丈夫なのに、NFS を使うクライアントを混在する必要はない。混在をすると、ロックの問題から始まって、IDマッピングまで設定する羽目になる。

トラブルが起きないように使ってあげるコツは、2つあると思う。1つ目は多機能な製品であっても本当に必要なものだけを選んで利用すること、そしてもう1つは、その機能が用意された目的にあわせた形で使ってあげることである。

SMB と NFS を混在する際には、以下をお勧めする。

・SMB の共有と NFS の共有は分ける。
・SMB/NFS を混在するときは、他の注意点に気をつける。

注意点２: SMB を使う共有では、強制ロックを優先する

Solaris には、ZFS に non-blocking mandatory locking [1] と言プロパティがある。SMBのクライアントととして使うのには強制ロックが生きていないといけないので、この値を有効 (on) にする。一方で NFS 側は予期しないロックなどが発生するが、これは、ロックを見つけたときに解放されるまで待ち続けるようなロジックをもつ処理をしなければないと言うことになる。

ロックについては以前に少しばかり書かせて頂いた。ご興味のある方は、以下の記事もご参考頂ければ幸いである。

過去の記事： SMB と NFS のロックについて

[1] 「非ブロッキング強制ロック」と訳されているようです。（参考文献1)

注意点３: NFS は Version 4 をつかう

NFSv3 は伝統的にな POSIX の権限に基づいており、SMB は拡張された ACL を見ているため、基本的には互換性はない。NFSv4 は権限については互換性があるので、可能な限り NFSv4 を使うようにする。NFSv3 も使えないことはないが、拡張 ACL をうまく設定しないと、NFSv3 側では権限があるようにみえるのに、SMB 側で設定した権限が元でアクセスを拒否されると言うことが起こってしまう。

権限については以前に少しばかり書かせて頂いた。ご興味のある方は、以下の記事もご参考頂ければ幸いである。
過去の記事：SMB と NFS の権限について

注意点4: システム間でユーザーやグループの特定する設定

あるユーザーやグループにアクセスを許可するためには、まず、そのユーザーやグループがその所有者によって利用されていることを確定しないといけない。ID やパスワード、指紋認証といった仕組みはこのためにある。同じユーザーが複数システムで作業をしているのであれば、同じユーザーであることを保証してあげる必要がある。システム間で共通の情報を持たせるためのディレクトリサービスや、異なる認証機構をつなぐIDマッピングサービスはこのためにある。

4.1 Unix系のディレクトリーサービス

例えば、Solaris/Linux/macOSなどの Unix 系のシステムは、ユーザー名には UID、グループ名には GID という番号をつけて管理している。複数のシステムで同じように管理するには、管理するためのディレクトリーサービスと言われるサービスを設定してやり、それぞれのシステムがディレクトリーサービスを使ってユーザーやグループを認識するようにする必要がある。Unix系のシステムでは、NISやLDAPが使われている。もし、WindowsのActiveDirectoryとも統合する予定があるなら、LDAPを使うことをお勧めする。

4.2 Windows系のアカウントとディレクトリサービス

Windows系では、少し話が複雑だ。
私の理解では、Windowsのアカウントは次の4種類がある。
(1) マイクロソフトアカウント（個人アカウント）
(2) マイクロソフトアカウント（Azureアカウント、AADをつかったもの）
(3) ローカルアカウント（ワークグループモードでつかうもの）
(4) ADアカウント（オンプレミスの ActiveDirectoryのアカウント）

(1), (3)は他のシステムとの連携はあまり考えていないので、ここでは省く。
(4)については、内部では、ユーザーやグループに SIDと言うものを割り振り、アクセスを管理している。従って、SID が正しく、資格情報があればファイルなどにアクセスが出来る。ActiveDirectory (AD)のドメインコントローラは、セキュリティの情報を持つディレクトリサービスであると言える。

一方の(2) AADは本来 Azure Cloud 上にあるリソースを認証する仕組みであって、AD とは異なるものである。一方で、ADで認証されたユーザーが透過的に Azure上のリソースが使えるようにするために、Azure AD Connect と言う機能が用意され、ADのドメインコントローラで作成されたユーザーやグループなどの情報が同期される。

4.3 混在時の設定

Unix と Windowsの認証が混在するときには、IDマッピングなどのサービスを使って、SID と UID/GID の対応を作る必要がある。この対応を作ることでファイルなどのアクセス権があるかどうかを NAS などが認識することが出来る。SolarisにもLinuxにも同様の設定はあり、例えば、ActiveDirectoryドメインのメンバーサーバーでありつつ、NFS v4のサーバーでもあるという設定を構成できる。

注意点５ macOSの機能拡張

macOS のSMB クライアントはアップルさんが性能向上を目指して、独自の機能拡張を行っている。公になっている範囲の情報を以下にまとめさせて頂いた。

・アップルさんのSMBついての覚え書き

参考文献

本記事を書かせていただくにあたって、以下の記事を参考にさせていただいた。

参考文献1: Oracle Solaris の管理: ZFS ファイルシステム 表 6-1 ZFS のネイティブプロパティーの説明

参考文献2: Azure AD Connect とは
https://docs.microsoft.com/ja-jp/azure/active-directory/hybrid/whatis-azure-ad-connect

参考文献3: 個人アカウントと組織アカウント
https://cloud.ebisuda.com/個人アカウントと組織アカウント/

関連する記事

・SMB と NFS のロックについて
・SMB と NFS の権限について
・アップルさんのSMBついての覚え書き

改版の履歴

2022-05-06　「注意点５ macOSの機能拡張」、「関連する記事」の項目を追加