SMB vs NFS vs iSCSI：どのファイル共有方法を使うべき？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

SMB vs NFS vs iSCSI: Which File Sharing Method Should You Use? - Zima Store Online

簡単な答え

Windows、macOS、混在OSの家庭、オフィスのファイル共有、メディアライブラリにシンプルな共有フォルダが欲しい場合はSMBを使いましょう。環境が主にLinux、Unix、サーバー間、または自動化重視ならNFSを使います。仮想マシンやディスクのようなワークロードでローカルディスクのように振る舞うブロックレベルストレージが必要な場合はiSCSIを使います。

基本ルールはシンプルです：

SMB および NFS ファイルとフォルダを共有します。
iSCSI クライアントにブロックストレージを提示します。
SMB および NFS 通常、共有フォルダに適しています。
iSCSI 通常、1台のホストがディスクのようなアクセスを必要とする場合に適しています。

どのプロトコルが最速かだけで選ばないでください。より良い質問は、どのOSがアクセスする必要があるか、ファイルを共有するのかディスクを提示するのか、複数ユーザーが同時アクセスするのか、権限やリモートアクセスをどう管理するかです。

SMB vs NFS vs iSCSI：核心的な違い

SMB、NFS、iSCSIはいずれもクライアントがネットワーク経由でストレージを使用できますが、ストレージの公開方法は異なります。SMBとNFSはファイルレベルの共有を公開し、iSCSIはブロックレベルのストレージを公開します。

この違いは権限、多人数アクセス、アプリ互換性、バックアップ動作、データ破損のリスクに影響します。

SMBとNFSはファイル共有プロトコルです

SMBとNFSはファイルレベルのアクセス方法です。サーバーがファイルシステムを所有・管理し、クライアントデバイスはサーバーにファイルの開閉、読み書き、移動、削除を要求します。

これにより、複数のユーザー、コンピューター、またはアプリが同じフォルダ構造にアクセスする必要がある場合に、SMBとNFSが適しています。サーバーはファイルの整理、ロック動作、共有権限、エクスポートルールの管理を担当します。

MicrosoftはSMBを、ユーザーやアプリケーションがリモートサーバー上のファイルを読み取り、作成、更新できるネットワークファイル共有プロトコルとして説明しています。また、ユーザーがネットワークドライブをマップしたり、\\server\shareのようなUNCパスにアクセスすると、SMBクライアントがMicrosoft SMBファイル共有の概要を通じてその接続を開始・管理すると説明しています。

iSCSIはブロックレベルストレージです

iSCSIは異なります。共有フォルダを公開する代わりに、iSCSIターゲットはストレージをブロックデバイスとしてイニシエーターに提示します。クライアントはそのネットワークストレージをローカルディスクのように扱うことがあります。

そのため、iSCSIは仮想マシン、データベース、ラボ、またはストレージインフラの議論でよく登場します。クライアントは通常、提示されたストレージを独自のファイルシステムでフォーマットし、リスクモデルが変わります。

複数の人がノートパソコンやデスクトップから開けるフォルダだけが必要な場合、iSCSIは通常適切な選択肢ではありません。

選択前に違いが重要な理由

ファイルレベルとブロックレベルの違いは、その後のほぼすべての決定に影響します。

質問	SMB	NFS	iSCSI
ストレージタイプ	ファイルレベル共有	ファイルレベル共有	ブロックレベルストレージ
典型的なクライアント適合	Windowsおよび混在OS	Linux、Unix、サーバー	VMホストまたはディスクのようなワークロード
複数ユーザーの共有フォルダ使用	一般的	一般的	通常の使用ケースではない
権限モデル	ユーザーアカウント、資格情報、ACL	ホストアクセス、UID / GID、エクスポート、Kerberosオプション	イニシエーターアクセス、ACL、CHAP、LUNマッピング
初心者に最適な使用法	ネットワークドライブまたは共有フォルダ	Linuxサーバーマウント	ディスクのようなターゲットが必要な場合のみ
主なリスク	資格情報と権限の混乱	UID / GIDやエクスポートのミス	ブロックデバイスを通常の共有フォルダのように扱うこと

良い選択はプロトコル名ではなく、ワークロードから始まります。

いつSMBを使うべきか？

Windows、macOS、混在クライアント環境で幅広い互換性と簡単なファイルアクセスを望む場合はSMBを使用してください。家庭用NASフォルダ、オフィス共有、家族のファイル、メディアライブラリ、一般的なドラッグ＆ドロップストレージのデフォルト選択肢であることが多いです。

SMBはネットワークドライブのマッピングやファイルエクスプローラーの操作が馴染みやすいため、非技術者にも通常は使いやすいです。

Windowsおよび混在OSのファイル共有に最適

Windowsデバイスが関与する場合、SMBは通常最良の第一選択肢です。Windowsには組み込みのSMBクライアントおよびサーバーロールがあり、ユーザーはネットワークドライブをマップし、UNCパスにアクセスし、別のストレージプロトコルを追加せずに共有フォルダを操作できます。

SMBはmacOSや多くのNASシステムがSMB共有に接続できるため、混在環境でもよく機能します。ほとんどの家庭や小規模チームにとって、SMBは最も実用的な汎用共有方法です。

SMBを選ぶべき場合：

Windowsクライアントが一般的な場合；
ユーザーが生のディスクではなく共有フォルダを必要とする場合；
ユーザーがファイルを開き、コピーし、名前を変更し、保存する必要がある場合；
慣れ親しんだネットワークドライブの動作を望む場合；
ユーザー資格情報やACLスタイルの権限が必要な場合。

macOSやメディアライブラリでSMBがよく機能する場合

SMBはmacOSがNASフォルダにアクセスする際の一般的な選択肢でもあります。FinderはSMB共有に接続でき、多くのNASシステムは手動マウント用にSMBのURLを公開しています。

メディアライブラリの場合、メディアサーバーや再生デバイスが共有から確実に読み取れる場合、SMBはよく機能します。映画、音楽、写真、共有ホームフォルダには通常十分シンプルです。

ただし、アプリの動作も重要です。ネットワーク共有をうまく扱うアプリもあれば、ローカルディスクの動作を期待するアプリもあります。アプリがネットワークパスの使用を拒否する場合、問題はSMB自体ではなくアプリのストレージの期待値かもしれません。

一般的なSMBの権限および資格情報の問題

SMBの問題は、プロトコルが「壊れている」よりも資格情報や権限に起因することが多いです。ユーザーが誤った保存済みアカウントで接続したり、読み取り専用アクセスしかなかったり、古いネットワークドライブのマッピングを再利用しようとしたりする場合があります。

一般的なSMBの問題には以下が含まれます：

Windowsが誤った資格情報を記憶しています;
ユーザーはファイルを読み取ることはできますが、書き込みはできません;
ネットワークドライブが再起動後に再接続しない場合；
macOSが登録ユーザーが必要なときにゲストとして接続する場合；
共有は存在するが、ユーザーアカウントに権限がない場合；
NASとクライアントが同じ到達可能なネットワーク上にいない場合。

SMBが失敗した場合、プロトコルを変更する前にアカウント、パスワード、共有権限、ファイル権限、ネットワークパスを確認してください。

いつNFSを使うべきか？

クライアントが主にLinux、Unix、またはサーバー間システムの場合にNFSを使用してください。ホームラボ、Linuxメディアサーバー、仮想化環境、自動マウントで一般的です。

NFSは軽量で便利ですが、権限が不要というわけではありません。UID / GIDのマッピング、エクスポートルール、ホストアクセス、セキュリティオプションが重要です。

Linux、Unix、およびサーバー間マウントに最適

NFSはLinuxやUnix系システムが主なクライアントである環境に適しています。サーバー間で共有ディレクトリをマウントしたり、LinuxアプリケーションにNASパスへのアクセスを提供するために一般的に使われます。

これはサービス、スクリプト、メディアサーバー、ホームラボノードのために予測可能なマウントが欲しいときに役立ちます。NFSはLinuxネイティブのワークフローでSMBより自動化しやすいことがあります。

NFSを選ぶべき場合：

ほとんどのクライアントがLinuxまたはUnix系である場合；
サービス間でサーバー間アクセスが必要な場合；
UID / GIDの所有権を理解している場合；
ホストベースのエクスポートが許容される場合；
Linuxのワークフローに合ったマウントが欲しい場合。

なぜNFSがメディアサーバーやホームラボに役立つのか

メディアサーバーは多くの場合Linuxで動作します。メディアアプリとNASの両方がLinuxに対応している場合、NFSはメディアディレクトリをマウントする自然な方法となります。

NFSはまた、Unixスタイルのパスと権限を期待するホームラボのノード、コンテナ、自動化タスクに役立ちます。多くの場合、Linuxサービス内でSMBの資格情報を使うよりも設定がすっきり感じられます。

トレードオフとして、NFSのID管理はSMBとは異なります。クライアントのサービスユーザーがサーバーで期待される所有権と一致しない場合、マウントは見えるものの、ファイルの書き込みや編集が失敗することがあります。

一般的なNFSのUID、GID、および権限の問題

Red HatはNFSを多くの既知ホストとファイルシステムを透過的に共有するのに適していると説明しつつ、NFSのセキュリティはエクスポート制御とクライアントの権限に大きく依存すると警告しています。従来のAUTH_SYSモードでは、Red HatはクライアントがユーザーのUIDとGIDを申告するため、悪意のあるまたは誤設定のクライアントがRed Hat NFSセキュリティモデルを通じて誤ったIDを表現できると指摘しています。

だからこそUIDとGIDが重要です。クライアントとサーバーがユーザーとグループのIDを一致させない場合、ユーザーは「許可拒否」エラーや予期しないファイル所有権を目にすることがあります。

一般的なNFSの問題には以下が含まれます：

クライアントホストはエクスポートルールで許可されていません;
クライアントのユーザーIDがサーバー側の所有者と一致しない。
rootスクワッシュがrootアクセスの挙動を変更する。
書き込みアクセスが期待されているのに共有が読み取り専用でエクスポートされている。
必要な場合にKerberosやより強力なセキュリティオプションが設定されていない。

NFSは強力ですが、クライアントの識別とホストアクセスが意図的に設計されている場合に最適に機能します。

いつiSCSIを使うべきか？

クライアントがネットワーク越しにブロックレベルのストレージを必要とする場合にiSCSIを使用してください。これは通常の共有フォルダプロトコルではありません。

iSCSIは、システムがファイル共有ではなくディスクのようなデバイスを期待する場合に最も関連性があります。これにはVMストレージ、ラボ環境、特定のデータベースのようなワークロード、またはSMBやNFSパスでうまく動作しないアプリケーションが含まれます。

仮想マシンとブロックストレージワークロードに最適

iSCSIは、ホストが直接接続されたディスクのように振る舞うストレージを必要とする場合に有用です。例えば、VMホストはiSCSIターゲットに接続し、プラットフォームやファイルシステムの設計に応じて提示されたストレージを仮想ディスクとして使用することがあります。

重要なポイントは、iSCSIは共有フォルダツリーではなくストレージブロックを提示することです。これにより、SMBやNFSとは異なる役割を持ちます。

iSCSIを選ぶべき場合：

クライアントがローカルディスクのようなデバイスを期待していること。
ワークロードがブロックストレージ用に設計されていること。
適切なホストまたはクラスタシステムのみがターゲットにアクセスすること。
イニシエーター、ターゲット、LUN、アクセス制御を理解していること。
ターゲットをフォーマットまたは使用する前にバックアップとリカバリ計画があること。

なぜiSCSIは共有フォルダとは異なるのか

Red Hatは、iSCSIターゲットがクライアント側のイニシエーターにサーバー上のストレージデバイスへのアクセスを提供し、ターゲットはファイル、ボリューム、ローカルSCSIデバイス、RAMディスクでバックアップされたローカルストレージリソースをエクスポートできると説明しています。Red Hat iSCSIターゲット設定ガイドでは、バックストア、ポータル、LUN、ACL、CHAP認証についても説明しています。

これはSMBやNFSとは異なるモデルです。SMBやNFSではサーバーがファイルシステムを管理し、クライアントはファイルにアクセスします。iSCSIではクライアントがブロックデバイスを見て、自身のファイルシステムでフォーマットすることがあります。

だからこそ、iSCSIはディスクのようなアクセスには適したツールですが、気軽な共有フォルダには不向きなツールなのです。

複数のクライアントから1つのiSCSIターゲットをマウントするリスク

iSCSIの主な誤りは、1つのLUNを共有フォルダのように扱うことです。iSCSI LUN上の通常のファイルシステムは、ストレージスタックがクラスタアクセス用に設計されていない限り、通常は1つの所有者を想定します。

複数の通常クライアントがクラスタ化ファイルシステムや適切な調整なしに同じブロックデバイスに書き込むと、データの破損が発生する可能性があります。クライアントはそれぞれがディスクのレイアウトを制御していると誤認することがあります。

ほとんどの家庭用NASユーザーにとって、「複数のコンピューターが同じファイルを必要とする」場合、iSCSIは使うべきではありません。その場合は通常、SMBかNFSの方が安全です。

SMB vs NFS vs iSCSIの決定チェックリスト

最速の選択方法は6つの実用的な質問に答えることです。これがストレージアクセス適合マトリックスの役割です。

決定層	重要な質問	何を決めるのに役立つか	最適な方向性
アクセスの種類	ファイルを共有していますか、それともディスクを提示していますか？	ファイルレベルの共有が必要か、ブロックレベルのストレージが必要か。	ファイルにはSMB/NFS、ブロックストレージにはiSCSI。
クライアント環境	どのオペレーティングシステムがアクセスを必要としていますか？	クライアントはWindows、macOS、Linux、サーバー、VM、メディアアプリのどれか。	Windowsや混合OSにはSMB、Linux/UnixにはNFS、ディスクのようなワークロードにはiSCSI。
同時アクセスの境界	複数のユーザーやデバイスが同じデータにアクセスしますか？	共有フォルダが必要か、単一クライアントのブロックデバイスで十分か。	共有アクセスにはSMB/NFS、iSCSIは正しい排他またはクラスタ設計がある場合のみ。
権限モデル	ユーザー、デバイス、アプリはどのように認証すべきか？	認証情報、ACL、UID/GIDマッピング、ホストアクセス、イニシエーターアクセスのどれが最も重要か。	ユーザーベースのアクセスにはSMB、UnixスタイルのIDにはNFS、ホストレベルのアクセスにはiSCSI。
ネットワーク境界	アクセスはLAN、VPN、またはリモートのプライベートアクセスに限定されていますか？	プロトコルはローカルに留めるべきか、プライベートネットワーク経由でアクセス可能にするべきか。	ストレージプロトコルはパブリックインターネットから切り離してください。
検証チェック	選択が機能しているかどうかはどうやってわかりますか？	ファイルが正しく開き、保存され、再接続され、ワークロードに対して正常に動作するかどうか。	重要なデータに使う前にテストしてください。

どのオペレーティングシステムがアクセスを必要としていますか？

Windowsが中心の場合はSMBから始めてください。LinuxやUnixサーバーが中心の場合はNFSを検討してください。VMホストやアプリケーションがディスクを期待している場合は、iSCSIを慎重に評価してください。

macOSは日常的な共有にSMBをよく使います。LinuxもSMBを使うことが多いですが、サーバー間のマウントや自動化にはNFSの方が適している場合があります。

オペレーティングシステムがすべてを決めるわけではありませんが、最初の選択肢を絞る手助けになります。

ファイルを共有していますか、それともディスクを提示していますか？

これが最も重要な質問です。ユーザーがフォルダを閲覧したり、ドキュメントを開いたり、メディアをストリーミングしたり、デバイス間でファイルを共有したい場合は、SMBやNFSのようなファイル共有プロトコルを使用してください。

クライアントがフォーマットや管理を行うディスクのようなブロックデバイスを必要とする場合、iSCSIが適しているかもしれません。

iSCSIがより高度に聞こえるからといって選ばないでください。これは別の問題を解決します。

複数のユーザーやデバイスが同時にアクセスする必要がありますか？

共有フォルダの場合、複数のユーザーやデバイスが同じデータにアクセスすることが一般的です。SMBとNFSはファイルレベルのアクセスパターンに基づいて設計されています。

iSCSIを使う場合は注意が必要です。1台のホストにマウントされたLUNは、多くのクライアントに共有されたフォルダとは異なります。

複数の通常クライアントが同じファイルを扱う必要がある場合、通常はSMBまたはNFSの方が適しています。

権限、性能、シンプルさはどれくらい重要ですか？

ほとんどの家庭や小規模オフィスユーザーにとっては、理論上の性能よりもシンプルさと正しい権限設定の方が重要です。マウントや再接続、トラブルシューティングが簡単なプロトコルの方が、狭いケースでベンチマークが速いものより優れている場合があります。

これらのルールを使ってください：

アクセスの種類に合ったプロトコルを選んでください。
主要なクライアントOSに合わせてください。
権限モデルが管理可能なものであることを確認してください。
アクセス経路はローカルかプライベートに保ってください。
信頼する前に、開く、保存、再接続、作業負荷の動作をテストしてください。

パフォーマンスチューニングは、プロトコルが作業負荷に合ってから行うべきです。

共有方法を選ぶ際のよくある間違い

ほとんどのプロトコルの誤選択は、速度の主張や孤立した例に基づいてユーザーが選ぶために起こります。安全な方法は、プロトコルの動作を作業負荷に合わせることです。

共有フォルダが本当に必要な場合にiSCSIを使うこと

iSCSIはより良いSMBではなく、異なるストレージモデルです。

本当に必要なのが「ノートパソコン、デスクトップ、メディアサーバーが同じファイルを見られること」なら、SMBやNFSを使ってください。iSCSIを誤用すると、一つのクライアントが制御するディスクを作ってしまい、安全な共有フォルダにはなりません。

これは特にiSCSI LUNをフォーマットしたり重要なファイルを置く前に重要です。

ローカルディスクを期待するアプリにSMBやNFSを使うこと

一部のアプリはネットワーク共有上でうまく動作しません。ローカルディスクのセマンティクス、直接ブロックアクセス、SMBやNFSと合わないファイルロック動作を期待することがあります。

その場合、アクセスパターンが適切ならiSCSIを検討してもよいでしょう。ローカルディスクを期待する作業負荷を単一ホストで実行するなら、共有フォルダよりiSCSIの方が理にかなっています。

それでも、データを移動する前にアプリの対応を確認すべきです。

LAN、VPN、権限の境界を無視すること

SMB、NFS、iSCSIは一般的にプライベートネットワークストレージプロトコルとして扱うべきです。利便性のために直接パブリックインターネットに公開しないでください。

リモートアクセスの場合は、VPNなどのプライベートネットワーク経路や他の安全なアクセス方法を使い、そのプライベート接続を通じて共有をマウントしてください。ストレージプロトコルを公開向けのセキュリティ境界にしてはいけません。

誰がアクセスできるかも確認してください。技術的にマウントが成功していても、誤ったユーザーがファイルを読み書きできる場合は問題です。

すべてのユースケースを一つのプロトコルで処理しなければならないと仮定すること

多くのNASやプライベートクラウドのセットアップでは複数のプロトコルが使われます。SMBはデスクトップユーザー向け、NFSはLinuxサービス向け、iSCSIは特定のVMやラボの作業負荷に使われることがあります。

すべての作業負荷を一つの方法に無理に押し込む必要はありません。より良い方法は、各ユースケースをそのアクセスパターンに合ったプロトコルに割り当てることです。

唯一の注意点は複雑さです。プロトコルが増えると、管理すべき権限、マウント、ログ、障害ポイントも増えます。

ファイル共有の設定が正しく機能しているか確認する方法

ファイル共有のセットアップはマウントが表示された時点で完了ではありません。実際に使用するワークロードと権限モデルでテストする必要があります。

クライアントデバイスからファイルが正しく開き保存できること

実際のファイルを開き、編集し、保存し、閉じて再度開いてください。その後、新しいファイルを作成し、テストファイルを削除してください。

これは基本的な接続確認以上のものです。クライアントがワークロードに必要な方法で読み書きできることを検証します。

iSCSIは共有フォルダのようにテストしないでください。意図したホストがターゲットを正しく認識し、設計通りにストレージが使用されていることを検証してください。

権限が意図したユーザーやデバイスに合っていること

SMBの場合、正しいユーザーが意図した権限レベルで共有にアクセスできることを確認してください。クライアントがキャッシュされた認証情報を使っている場合は、古いマッピングを削除し正しいアカウントで再接続してください。

NFSの場合、UID / GIDの動作、エクスポートルール、読み書きアクセスを確認してください。マウントは成功しても書き込みアクセスが失敗することがあります。

iSCSIの場合、正しいイニシエーターが意図したLUNにアクセスでき、意図しないイニシエーターはアクセスできないことを確認してください。

再起動やネットワーク変更後も再接続が機能すること

良いセットアップは通常の再起動に耐えられるべきです。クライアントを再起動し、共有やターゲットが期待通りに再接続されることを確認してください。

再起動後にマウントが切れる場合は、保存された認証情報、マウントオプション、ネットワークのタイミング、サービスの起動順序、NASのIPアドレスが変わっていないかを確認してください。

モバイルやリモートのワークフローでは、ネットワークを切り替えた後もテストしてください。一つのLANでしか動作しない設定はVPNやプライベートリモートアクセスの計画が必要かもしれません。

ワークロードに対してパフォーマンスが許容範囲内であること

パフォーマンスは速度テストだけでなく、ワークロードに基づいて判断すべきです。メディアサーバーは安定したストリーミングが必要です。写真ライブラリは応答性の良いブラウジングが求められます。VMのワークロードは安定したレイテンシと書き込み動作が必要です。

パフォーマンスが悪い場合は、ネットワークリンク速度、Wi-Fiと有線接続の違い、ディスク性能、クライアントのCPU負荷、プロトコル設定、選択したプロトコルがワークロードに適しているかを確認してください。

ボトルネックを確認する前にプロトコルを変更しないでください。

プライベートクラウドやNASのワークフローでの動作方法

実際のNASやプライベートクラウドのワークフローでは、プロトコルの選択がセットアップの道筋となります。まずアクセス方法を選び、次に共有フォルダやストレージターゲットを作成し、正しいクライアントシステムからマウントし、最後に権限と再接続の動作を検証します。

SMBに特化した場合、デバイス固有のガイドが実際の操作例を示すことがあります。ZimaOS SMB共有接続ワークフローでは、共有フォルダの作成、マウント用URLの取得、Windowsからの接続、ネットワークドライブの割り当て、macOS Finderからのマウント方法を説明しています。また、プロトコルの選択後にクライアント、認証情報、LANの到達性、マウント方法がなぜ重要かも示しています。

ストレージ重視のプライベートクラウドや家庭用NASのワークフローには、ZimaCube 2パーソナルクラウドNASが適しています。SMB、NFS、リモートファイルアクセス、メディアストレージ、プライベートクラウドファイルのワークフローを一緒に計画する必要があるマルチドライブデバイスのカテゴリに該当します。これらのプロトコルを使う唯一の方法ではありませんが、プロトコル選択が実際のユーザーワークフローになるNAS側の環境の一例です。

同じ原則はどのNASにも当てはまります。まずワークロードに基づいてプロトコルを選び、その後システム固有の共有設定、権限、クライアントのマウント、検証のガイドに従ってください。

よくある質問

SMBはNFSより優れていますか？

主にWindows、macOS、混合デスクトップクライアント、または単純な共有フォルダを使う場合はSMBが優れています。NFSはLinux、Unix、サーバー間マウント、そして自動化が多いワークフローに適しています。どちらが優れているかは一概には言えず、クライアント、権限、ワークロードによって最適な選択が変わります。

NFSはSMBより速いですか？

NFSは特にLinuxやサーバー側のワークロードで、IDや権限がきちんと設定されている場合に高速に感じられることがあります。SMBはWindowsや混合OSユーザーにとってより便利で互換性があります。パフォーマンスはワークロードに依存するため、どちらか一方が常に優れているとは限りません。

家庭用NASにiSCSIを使うべきですか？

特定のホストやワークロードでブロックレベルのストレージが必要な場合のみiSCSIを使ってください。通常の共有フォルダや家族のファイル、複数のデスクトップクライアントが同じファイルを閲覧する用途には最適ではありません。ほとんどの家庭用NASユーザーはまずSMBかNFSを検討すべきです。

WindowsはNFSやiSCSIを使えますか？

Windowsはエディションや機能、設定によってSMB以外も使え、対応環境ではiSCSIイニシエーターとしても動作します。しかし、通常はSMBが最も簡単なWindowsのファイル共有オプションです。ワークロードが明確に必要とする場合のみNFSやiSCSIを使ってください。

同じNASでSMB、NFS、iSCSIを使えますか？

はい、多くのNASシステムは複数のアクセス方法を提供できます。しかし、すべてのフォルダやワークロードがすべてのプロトコルを使うべきというわけではありません。デスクトップのファイル共有にはSMBを、LinuxやサーバーのマウントにはNFSを、そしてiSCSIはそれ専用のブロックストレージ用途にのみ使用してください。

PlexやJellyfinのメディアストレージにはどのプロトコルを使うべきですか？

Windowsまたは混合OSのメディアライブラリの場合、SMBがしばしばより簡単な選択肢です。LinuxベースのメディアサーバーでNASからメディアをマウントする場合、UID / GIDの権限が正しく設定されていればNFSはクリーンな選択肢となります。iSCSIは、サーバーが特にディスクのようなブロックストレージを必要としない限り、通常のPlexやJellyfinのメディアフォルダには不要です。