SMB対NFS：家庭で使うべきファイル共有方法はどちら？

家庭内ネットワークにWindows PC、Mac、スマホ、タブレット、メディアプレーヤーが含まれる場合、SMBが通常はより良いデフォルトです。デスクトップのファイルブラウザと自然に統合され、ユーザーベースのログインをサポートし、消費者向けアプリケーションで広く利用可能です。

クライアントが主にLinuxサーバー、Proxmoxホスト、または管理されたインフラワークフローの一部としてストレージをマウントするUnix系システムの場合、NFSはより魅力的になります。UID/GIDの値、エクスポートルール、マウント動作、ファイル所有権が正しく計画されている場合に効率的で予測可能です。

ベンチマークではなくクライアントに合わせてプロトコルを選ぶ

SMBとNFSはどちらもNASやホームサーバーに保存されたファイルを開くことができますが、異なるエコシステムを前提に設計されています。SMBはWindowsにネイティブで、macOS、Linux、モバイルファイルマネージャー、スマートテレビ、メディアアプリケーションで広くサポートされています。NFSはLinuxやUnixのマウントワークフローにより自然に適合します。

この区別は、どちらかのプロトコルが速いという一般的な主張よりも重要です。WindowsノートパソコンはSMBクライアントスタックに最適化されているため、SMB経由でよりスムーズで高速な体験が得られるかもしれません。数千のファイルを処理するLinuxサーバーは、リモートディレクトリが通常のUnixマウントのように振る舞うため、NFSの方が管理しやすい場合があります。

共有にアクセスするデバイスとその用途をリストアップすることから始めましょう。人間によるファイル閲覧、機械間ストレージ、メディアストリーミング、バックアップ、仮想化、コンテナデータは必ずしも同じプロトコルを必要としません。

SMBは混在する家庭環境で通常より簡単なデフォルトです

SMBは通常、Windowsのファイルエクスプローラー、macOSのFinder、スマートフォン、またはメディアプレーヤーアプリケーションから手動でフォルダーを開く際に最も簡単な選択肢です。ユーザーはNASのユーザー名とパスワードで接続でき、すべてのクライアントで数値のLinux識別子を管理する必要がありません。

最新のSMBバージョンは、基本的なファイル転送を超えた機能も提供しており、ユーザーおよびグループのACL、署名、暗号化、ファイルロック、キャッシュ、マルチチャネル機能などが含まれます。これらの機能は複雑さを増しますが、複数の家族メンバーが異なるアクセス権を必要とする場合に役立ちます。

Windows、macOS、Linuxが混在するネットワークでは、最新のSMB 3.xは多くのパフォーマンス差を縮めつつ、より広範なクライアント互換性を維持します。これにより、SMBはドキュメント、家族写真、共有ダウンロード、一般的なNAS閲覧の実用的な出発点となります。

NFSは管理されたLinuxワークフローにより自然に適合します

クライアントがフォルダを閲覧する人ではなくLinuxサーバーの場合、NFSの統合はしばしば簡単です。共有は起動時に固定ディレクトリにマウントされ、バックアップソフトウェア、メディアサービス、仮想化ホスト、またはその他のシステムプロセスで使用されます。

これは1人の管理者がNASとクライアントの両方を管理する場合にうまく機能します。許可されたサブネットを定義し、ユーザーとグループを整合させ、マウントオプションを選択し、ネットワーク共有が利用可能になってからサービスが起動するようにできます。

Windowsラップトップ、モバイルアプリケーション、または複数の家庭ユーザーが直接アクセスする必要がある場合、NFSは使い勝手が悪くなります。クロスプラットフォームのNFSクライアントは存在しますが、セットアップとIDマッピングは通常、これらのデバイスでSMBを使用するよりも簡単ではありません。

SMBとNFSは異なるアクセスモデルを使用します

SMBは通常、アクセスをサーバーアカウントとして提示します。ユーザーは資格情報で接続し、NASはそのIDに関連付けられた共有権限、グループ、およびファイルシステムACLを評価します。

一般的な家庭用NFS構成は異なります。エクスポートは選択されたホストまたはサブネットに制限されることが多く、ファイルアクセスはクライアントから送信される数値のUnix UIDとGID値に依存します。NFSv4はより高度なIDとKerberos構成を使用できますが、多くの家庭用セットアップは信頼されたクライアントネットワークと数値所有権に依然として依存しています。

実際の違いは、SMBは一般的にユーザーとグループのACLを使用し、NFSアクセスはホストルールとLinuxのUID/GID所有権に密接に結びついていることです。どちらのモデルも自動的に優れているわけではなく、それぞれ異なるトラブルシューティングの問題を生み出します。

UIDとGIDの計画はNFSの主な学習曲線です

Linuxのユーザー名は単なる読みやすいラベルに過ぎません。ファイルシステムは最終的に数値のユーザーIDとグループIDを記録します。2台のマシンに同じ名前のユーザーがいても、 メディアしかし、UID 1000を使う場合とUID 1001を使う場合は異なるIDです。

これが、NFS共有が正常にマウントされてもファイル作成が失敗する理由です。ネットワーク経路とエクスポートは機能していますが、クライアントが提示するユーザーがNAS上の所有者、グループ、またはACLと一致していません。

複数のLinuxシステムでNFSを使用する前に、クライアントとサーバーでid usernameの結果を比較してください。書き込み可能なNFS共有に必要な数値UIDとGIDの整合は、ユーザーがディレクトリに入れるがファイルを作成できない場合によく見落とされるステップです。

Root Squashはランダムな権限エラーではありません

NFSエクスポートは通常、クライアントマシンのrootユーザーがNAS上で自動的にrootになるのを防ぐためにrootスクワッシュを使用します。リモートのUID 0からのリクエストは、権限の低い匿名IDにマッピングされます。

これは、バックアップスクリプト、コンテナ、または管理者のコピーコマンドをrootで実行しているユーザーを驚かせることがあります。共有はマウントされますが、書き込みが失敗したり、ファイルが匿名ユーザーの下に表示されたりします。

1つのワークフローを妨げるからといってrootスクワッシュを無効にしないでください。まず、どの非rootユーザーまたはグループがデータを所有すべきかを決定し、そのIDに必要なアクセス権を与えてください。使用する際は no_root_squash 重要なセキュリティ境界を犠牲にしており、通常のホームサーバーのショートカットとして扱うべきではありません。

NFSは自動的にSMBより高速ではありません

パフォーマンスはクライアントのオペレーティングシステム、プロトコルのバージョン、ファイルサイズ、メタデータのワークロード、ストレージプール、署名や暗号化、マウントオプション、ネットワークリンク、アプリケーションの動作に依存します。

単一の大きなビデオは主に連続スループットをテストします。両方のプロトコルがディスクやネットワークリンクを飽和させることができれば、その結果は似ているかもしれません。数千のサムネイル、字幕、メタデータファイル、ネストされたフォルダを含むディレクトリは、ファイル検索、属性キャッシュ、小さな操作により大きな負荷をかけます。

そのため、1つのベンチマークだけで全ての家庭の選択を決定することはできません。少なくとも4つのワークロードをテストしてください：大きな読み取り1つ、大きな書き込み1つ、多数の小さなファイルがあるディレクトリ1つ、そして実際に共有を使用するクライアントからの通常のフォルダ閲覧です。

大きなメディアファイルは通常、最速のプロトコルを必要としません

典型的な映画のストリームは、健全なギガビットイーサネット接続が提供できる帯域幅よりもはるかに少ない帯域幅を消費します。メディアサーバーがローカルネットワーク上で1つのビデオを安定して再生できない場合、ボトルネックはSMB対NFSではなく、Wi-Fi、トランスコーディング、ディスク性能、またはクライアントの互換性である可能性があります。

違いはPlex、Jellyfin、Sonarr、または他のアプリケーションが大規模なライブラリをスキャンするときにより顕著になります。サーバーは実際の再生が一つの大きなメディアファイルを連続して読み込む一方で、数千のポスター、字幕、NFOファイル、データベース参照を開くことがあります。

このため、大容量ファイルのストリーミングはどちらのプロトコルでもうまく機能しますが、小規模ファイルのライブラリスキャンでは大きな違いが現れます。LinuxベースのメディアサーバーはNFSの恩恵を受けるかもしれませんが、WindowsやmacOSクライアントは依然としてSMBのほうがサポートしやすい傾向があります。

SMBは通常、メディアプレーヤーの直接アクセスに適している

Apple TV、Android TVデバイス、スマホ、タブレット、ノートパソコンがNASに直接接続する場合、通常はSMBのほうが簡単です。多くのメディアアプリはサーバーアドレス、ユーザー名、パスワードでSMB共有を参照できます。

NFSのサポートはアプリケーションやデバイスによって異なります。利用可能であっても、そのエクスポートや権限設定は家庭のユーザーにとっては通常のSMB認証情報を入力するよりも分かりにくい場合があります。

これはメディアサーバー自体がストレージをマウントする方法とは別です。LinuxのJellyfinサーバーはNFS経由でライブラリを読み込むかもしれませんが、家族のデバイスはJellyfinのウェブやストリーミングインターフェースにのみ接続します。エンドユーザーデバイスは基盤となるファイルプロトコルに直接アクセスする必要はありません。

NFSはProxmoxストレージにとって自然な選択であることが多い

ProxmoxはLinuxを基盤として動作しているため、NFSはバックアップ、ISO、テンプレート、共有ストレージのワークフローに自然に適合します。NASのエクスポートはホストによってマウントされ、デスクトップのファイル共有ではなくインフラストラクチャストレージとして管理されます。

これはすべての仮想マシンディスクが自動的に家庭用NFSサーバーに置かれるべきだという意味ではありません。VMストレージはレイテンシ、同期書き込みの挙動、ネットワークの可用性、バックアップ設計、NASが再起動または切断されたときのシステムの動作に依存します。

コンテナの場合、すべてのコンテナに個別のネットワークマウント設定を与えたり、共有をマウントするためだけに特権を与えるよりも、ProxmoxホストでNFSをマウントし、特権のないコンテナにストレージパスを渡すほうがクリーンかもしれません。

Dockerのストレージはデータタイプによって選ぶべきです

Docker内でNASパスを使用することは、すべてのコンテナにとってNFSが最適な選択であることを自動的に意味しません。ワークロードがコンテナプラットフォームよりも重要です。

メディアライブラリ、ダウンロード、インポート、エクスポート、バックアップ、その他の大きな共有ファイルはSMBやNFSでうまく動作します。LinuxのDockerホストでは、ファイル所有権が馴染みのあるUID/GID値で表現されるためNFSの方が扱いやすいかもしれません。

データベース、SQLiteファイル、検索インデックス、アプリケーション状態、頻繁なロックや同期書き込みを伴うワークロードはより注意が必要です。アプリケーションが選択したネットワークファイルシステムを明示的にサポートし、再起動、ロック、障害時の挙動をテストしていない限り、これらのファイルはローカルストレージに置いてください。

コンテナに渡す前にホストで共有をマウントしてください

多くのホームサーバー展開では、最もクリーンなモデルはDockerホストでNAS共有を一度マウントし、それを必要なコンテナにバインドマウントすることです。

これにより、認証情報、NFSエクスポート設定、再接続動作、起動順序が一箇所にまとまります。コンテナは通常のディレクトリだけを見て、ホストがネットワークファイルシステムを管理します。

このモデルはNFSでもSMBでも機能します。重要なのは、ホストのマウントがコンテナ起動前に利用可能であること、コンテナのUID/GIDがマウントされたファイルにアクセスできること、NASがオフライン時にサービスが空のローカルディレクトリに黙って書き込まないことです。

計画なしに両方のプロトコルで同じデータを書き込ませないでください

ほとんどのNASプラットフォームは同じデータセットをSMBとNFSの両方で公開できます。技術的には、これによりWindowsユーザーとLinuxアプリケーションが同じファイルを扱うことが可能です。

問題は、二つの経路が異なるIDやACLモデルでファイルを作成する可能性があることです。SMBアップロードは詳細なACLを持つNASアカウントに属し、NFSアプリはUID 1000でPOSIXモードビットと異なるumaskで書き込むかもしれません。

両方のプロトコルがアクセスする必要がある場合は、主な書き込み者を定義してください。もう一方は読み取り専用にするか、両方が慎重に調整された共有グループと継承モデルを使うことができます。その計画がないと、権限のずれはすぐには現れず徐々に発生しがちです。

役割が分かれている場合は両方のプロトコルを使うのが合理的です

混在するホームラボでは、すべてに一つのプロトコルを選ぶ必要はありません。両方を使う方が、すべてのデバイスを同じアクセスモデルに無理に合わせるよりもすっきりします。

実用的な分け方の一例は：

• WindowsおよびMacのファミリーフォルダ用のSMB
• スマホ、タブレット、テレビの直接アクセス用のSMB
• ProxmoxのバックアップおよびLinuxホスト用のNFS
• Linuxメディアサーバーの読み取り専用ライブラリマウント用のNFS
• アプリケーションのデータベースや機密性の高いランタイム状態のためのローカルストレージ

プロトコルは責任ごとに分けるべきで、デフォルトでどこでも有効にするべきではありません。データセットを分けるか、明確な読み書きの境界を設けることで、権限の衝突を減らしトラブルシューティングを容易にします。

どちらのプロトコルもインターネットに直接公開すべきではありません

SMBとNFSは信頼されたローカルネットワークまたはプライベートネットワーク経路向けです。ホームルーターからパブリックインターネットへTCP 445（SMB）やNFSサービスのポートフォワードをしないでください。

リモートファイルアクセスには、まずVPNや他の認証されたプライベートアクセス層を通じてホームネットワークに接続してください。その信頼された経路内にリモートデバイスが入れば、LANで利用可能な同じSMBまたはNFSサービスを使えます。

SMBからNFSに変えても公開露出が安全になるわけではありません。セキュリティは到達可能なクライアントの制限、ソフトウェアの更新、適切な認証、不要な公開サービスの回避に依存します。

転送速度以上のベンチマークを行いましょう

公平な家庭内テストは、両方のプロトコルで同じNASデータセット、クライアント、ネットワークリンク、ファイルを使うべきです。そうしないと、結果はSMBとNFSではなく異なるストレージパスやクライアントデバイスを測定している可能性があります。

毎秒メガバイト以上を記録しましょう。スリープや再起動後にマウントが再接続するか、ファイル名やメタデータが正しく動作するか、アプリケーションがファイルを作成・削除できるか、権限が一貫しているかをテストしてください。

5％速いが再起動後に頻繁に失敗するプロトコルは、むしろ悪い選択かもしれません。信頼性、クライアント互換性、権限管理にかかる時間は実際のパフォーマンスの一部です。

この決定順序を使いましょう

プロトコルの好みよりもクライアントから始めましょう。データが必要なすべてのコンピューター、モバイルデバイス、メディアプレーヤー、サーバー、ハイパーバイザー、アプリケーションをリストアップしてください。

次に、人間の閲覧と機械間アクセスを分けます。家庭のユーザーは一般的にSMBアカウントと馴染みのあるファイルブラウザから恩恵を受けます。管理されたLinuxサービスはNFSマウントと数値ID制御から恩恵を受けるかもしれません。

最終的な共有を有効にする前に、これらの質問に答えてください：

1. WindowsやmacOSのユーザーはファイルを閲覧しますか？
2. 携帯電話やテレビのアプリケーションは直接アクセスが必要ですか？
3. ほとんどのクライアントは管理されたLinuxシステムですか？
4. UIDとGIDの値は一貫して維持できますか？
5. ワークロードにはデータベースやロックに敏感なファイルが含まれていますか？
6. SMBとNFSは同じデータセットに書き込みますか？
7. NASが利用できない場合、マウントはどのように動作すべきですか？
8. 選択したプロトコルは完全にパブリックインターネットから切り離せますか？

ほとんどの混在デバイスの家庭では、まずSMBから始めましょう。特定のLinux、Proxmox、バックアップ、またはそれに適したコンテナワークロードで一貫して管理できる場合にのみNFSを追加してください。

最終的なまとめ

SMBは通常、Windows、macOS、携帯電話、タブレット、スマートテレビ、共有ファミリーフォルダーに最適なデフォルトです。幅広い互換性とアカウントベースのアクセスモデルを提供し、家庭内ユーザーに説明しやすいです。

NFSはLinuxサーバー、Proxmoxストレージ、自動バックアップ、その他の機械間ワークフローに適していることが多いです。その利点はUID/GID値、エクスポート、マウントオプション、所有権を正しく管理することに依存します。

家庭内で両方のプロトコルを使用できますが、それぞれの役割を明確にしてください。SMBは人や混在クライアントデバイス向け、NFSは管理されたLinuxインフラ向けに使用し、同じデータセットに対して両方のプロトコルに無制限の書き込みアクセスを与えるのは避けてください。

よくある質問

NFSは常にSMBより速いですか？

いいえ。NFSはLinux間や小さなファイルのワークロードでより良い性能を発揮することがありますが、最新のSMBはWindowsや混在クライアントネットワークで非常に良い性能を発揮します。実際に使用するファイル、クライアント、ストレージ、ネットワークでテストしてください。

PlexやJellyfinにはSMBとNFSのどちらを使うべきですか？

どちらも使えます。Linuxメディアサーバーは大規模なライブラリスキャン時にNFSが有利な場合があり、Windows、macOS、メディアプレーヤーアプリがNASに直接アクセスする場合はSMBの方が簡単かもしれません。大容量のビデオストリーミングはどちらでも通常うまく動作します。

ProxmoxにはNFSの方が良いですか？

NFSはProxmoxのバックアップ、ISOストレージ、テンプレート、共有ストレージに一般的で自然な選択肢です。VMディスクや高書き込み負荷はレイテンシ、同期動作、NASの可用性のテストが必要です。

DockerコンテナはSMB共有を使用できますか？

はい。Dockerホスト上でSMB共有をマウントし、その結果のパスをコンテナにバインドマウントしてください。コンテナのユーザーがマウントされたファイルにアクセスできる権限を持ち、ホストのマウントがコンテナ起動前に利用可能であることを確認してください。

NFSで共有はマウントされるのに「許可拒否」と表示されるのはなぜですか？

エクスポートとネットワークパスは正しいが、クライアントのUID/GIDがNAS上の所有者または許可されたグループと一致しない場合があります。rootスクワッシュやエクスポートマッピングも実効ユーザーを変更することがあります。

同じフォルダーでSMBとNFSを同時に有効にできますか？

可能ですが、同時書き込みアクセスは所有権、ACL、拡張属性の競合を引き起こすことがあります。別々のデータセットを使用するか、一方のプロトコルを読み取り専用にするか、慎重に調整された共有権限モデルを作成することを推奨します。

家庭内でより安全なプロトコルはどちらですか？

どちらも信頼できるLAN内であれば安全に使用できます。SMBはシンプルなユーザー認証と最新の署名や暗号化を提供します。NFSは信頼できるクライアントに制限し、正しいエクスポートルールとrootスクワッシュを設定する必要があります。どちらもインターネットに直接公開すべきではありません。

初心者はどのプロトコルを選ぶべきですか？

Windows、macOS、携帯電話、またはテレビアプリケーションが家庭内にある場合はSMBを選択してください。クライアントが主にLinuxシステムで、マウント、UID/GID値、エクスポート権限の管理に慣れている場合はNFSを選択してください。