Linuxホームサーバー間でNFSv4のIDマッピングを設定する方法

単一のID権限管理機関または一致する数値IDを使用し、すべてのLinuxクライアントとサーバーでNFSv4マッピングドメインを統一します。

これは、ローカルのユーザー名と数値IDが異なる複数のLinuxホームサーバーで同じエクスポートをマウントする場合に重要です。数値所有権やIDマッピングポリシーの解決方法が異なると、名前が一致しているだけでは不十分で、nobody所有になったり、意図しないアクセスが発生したりする運用上のリスクがあります。保存したベースラインから開始し、一度に1つだけ可逆的な変更を行い、観測された分岐が意図した設定経路と一致しなくなった時点で中止します。

Nfsv4 IDマッピングのベースラインを確立する

設定を変更する前に、UID、GID、マッピングドメイン、エクスポートのセキュリティフレーバー、所有者文字列、キャッシュ状態、ファイル作成結果を記録します。元の設定と本番に近い実行結果を1つ保存し、後の改善を記憶や合成的なアイドル状態ではなく、同じワークロードと比較できるようにします。

サポートされている制御とその意味を確認するため、現在のNFSv4 IDマッピング設定を使用します。デフォルトは既知の開始点として扱い、このサーバー、クライアント構成、または復旧目標に設定が適合している証拠とはみなしません。

編集前に受け入れ条件と停止条件を定義します。受け入れの兆候は、ログ、プロトコル状態、アプリケーション出力、または復元データで確認できる必要があります。停止条件は、アクセス範囲の拡大、データ損失、リソース枯渇、または次の復旧時間枠を消費する障害を防ぐものでなければなりません。

Nfsv4 IDマッピングの変更を管理された段階で適用する

ステップ1: 数値IDを調査し、ローカルファイル、LDAP、または別のディレクトリのどれを権限管理の基準にするか決定します。変更後、期待される状態が現れるか直ちに確認します。現れない場合は、次のステップを適用する前にこのステップを元に戻します。

ステップ2: 明示的なマッピングを使用する場合は同じNFSv4ドメインを設定し、ネームサービスの検索結果を一致させ、クライアントごとの場当たり的な所有権修正を避けます。変更後、期待される状態が現れるか直ちに確認します。現れない場合は、次のステップを適用する前にこのステップを元に戻します。

ステップ3: 設定の整合性が取れた後でのみIDマッピングキャッシュを消去し、再マウントして各クライアントから使い捨てファイルを作成します。変更後、期待される状態が現れるか直ちに確認します。現れない場合は、次のステップを適用する前にこのステップを元に戻します。

[General]
Domain = home.arpa

[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

成功、失敗、例外の分岐を解釈する

成功とは、すべてのクライアントで同じ所有者とグループが解決され、新しく作成したファイルが意図した共同アクセス権を維持することです。結果を生んだ正確なワークロード、バージョン、タイミングを記録します。軽いテストは、元の問題が解決した証拠にはなりません。

失敗とは、所有者がnobodyと表示される、数値IDが異なる、またはあるクライアントが作成したファイルを別のクライアントが変更できない状態です。隣接するすべての制御を弱めて補おうとしてはいけません。最後に問題のなかったベースラインへ戻し、不一致がID、ネットワーク、ストレージ、アプリケーションの準備状態、または容量のどこに属するのかを切り分けます。

例外または曖昧な結果の場合は、以前のIDマッピング設定を復元し、ID権限管理の基準が修正されるまで読み取り専用でマウントします。低リスクの判別手順を再現でき、より深いプラットフォームまたはハードウェアの変更が必要だと証拠で示される場合にのみ、エスカレーションします。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

元のホームサーバー負荷で永続性を検証する

ベースラインで使用したものと同じクライアント経路、ファイルサイズ、同時実行数、スリープまたは再起動イベント、競合するワークロードを繰り返します。少なくとも2サイクル実行し、キャッシュが温まった状態での成功、偶然うまくいった1回の再接続、または1回だけ正常な起動した結果を永続性と取り違えないようにします。

成功と封じ込めの両方を確認します。すべてのクライアントで同じ所有者とグループが解決され、新しく作成したファイルが意図した共同アクセス権を維持する一方で、無関係なユーザー、サービス、共有、管理経路は元の動作を保っていなければなりません。変更が隣接するストレージ、ネットワーク、または復旧の境界に及ぶ場合は、関連するZimaSpaceワークフローを確認します。

受け入れの兆候が持続し、ロールバックが引き続き使用可能な場合にのみ、変更を完了します。所有者がnobodyと表示される、数値IDが異なる、またはあるクライアントが作成したファイルを別のクライアントが変更できない場合は、自動化を停止し、ログと保存済み設定を保持して、さらに変更を積み重ねるのではなく、最後に検証済みの状態へ戻します。

クエリファンアウトFAQ、完了判断、最終テスト

これらのクエリファンアウト形式の質問は、メイン設定が機能した後にユーザーがよく検索する次の判断を扱います。未テストの修復経路を導入せずに、対象範囲を広げるものです。

各回答は、測定した環境の条件が一致する場合にのみ適用します。バージョン、プロトコル、ファイルシステム、クライアント、信頼境界の違いによって、正しい分岐が変わる場合があります。

回答をランブックとともに保管し、アップグレードやトポロジー変更後に更新します。書き込みアクセス、ネットワーク到達性、または削除権限を拡大する例外には、新たなロールバックおよび復旧テストが必要です。

すべてのLinuxホストでユーザー名を一致させる必要がありますか？

名前を統一することは役立ちますが、実効IDの経路と数値所有権も一貫して解決されなければなりません。

なぜファイルがnobodyとして表示されるのですか？

クライアントとサーバーの間で、NFSv4ドメイン、ネームサービス、セキュリティフレーバー、またはマッピングキャッシュの内容が一致していない可能性があります。

chmod 777で解決すべきですか？

いいえ。IDのエラーを隠し、アクセス範囲を拡大するだけです。代わりにマッピングとグループポリシーを修正します。

結論: すべてのクライアントで同じ所有者とグループが解決され、新しく作成したファイルが意図した共同アクセス権を維持し、失敗の分岐が理解され、文書化されたロールバックが変更対象のコンポーネントに依存しなくなった時点で、設定は完了です。

最終テスト手順: 保存したベースラインを復元し、承認済みの変更を1回適用して、元の本番に近い負荷を繰り返します。成功の兆候と封じ込めの境界を確認し、その後、使い捨てデータでロールバックを実行します。5つすべての観測結果が一致した場合にのみ、変更を維持します。