この設定で最も重要な課題は、クライアント (c) のRHELサーバーで実行される**Dockerコンテナ内のPostgreSQLプロセス（postgres ユーザー）**が、ネットワーク越しにNFSサーバー (n) のUbuntu上にあるファイルに対して、正しい書き込み権限を持つようにすることです。
多くの場合、公式のPostgreSQLコンテナは、コンテナ内で postgres というユーザー（UID 999, GID 999 など、イメージによって異なる場合があります）として実行されます。NFSv4のデフォルト設定（sec=sys）では、このUID/GIDがそのままNFSサーバー (n) に渡されます。
しかし、NFSv4特有の idmapd（IDマッピングデーモン）の設定がサーバー (n) とクライアント (c) で一致していないと、すべてのファイルが nobody:nobody （権限なし）として扱われ、データベースが起動に失敗します。
この問題を回避し、確実に動作させるために、ここではNFSサーバー (n) 側で「クライアント (c) からのアクセスを、すべて特定のUID/GID（例: 999:999）として強制的に扱う」という all_squash 戦略を採用します。
useradd：DBデータ所有者ユーザーの作成 (n)目的:
NFSサーバー (n) 上に、PostgreSQLのデータ（コンテナが使用するUID/GID）を所有するための専用ユーザーを作成します。ここでは、多くのDockerコンテナで標準的に使われる UID 999 / GID 999 を使用すると仮定します。
例えるなら:
NFSサーバー (n) という銀行に、「PostgreSQLデータ専用金庫（UID 999）」を設置する作業です。この金庫の鍵（UID 999）は、後でNFSクライアント (c) に渡す「一時的なマスターキー」の行き先となります。
どんな時に使う？:
NFSサーバー (n) とクライアント (c) 上のDockerコンテナ間で、UID/GIDを確実に一致させたい場合に使用します。
（※重要：999 がサーバー (n) で未使用か id 999 コマンドで確認してください。もし使用済みなら別のIDに変え、以降の anonuid/anongid もそのIDに合わせます）
GID 999 の postgres_data グループを作成し、UID 999 の postgres_data ユーザーを作成します。
sudo groupadd -g 999 postgres_data
sudo useradd -u 999 -g 999 -M -N -r -s /usr/sbin/nologin postgres_data
groupadd -g 999 postgres_data:
g 999: グループIDを 999 に固定します。useradd -u 999 -g 999 ...:
u 999: ユーザーIDを 999 に固定します。g 999: 所属グループIDを 999 にします。M: ホームディレクトリを作成しません（データ管理用ユーザーのため）。N: ユーザー名と同じグループを作成しません。r: システムユーザーとして作成します。s /usr/sbin/nologin: このユーザーでログインできないように設定します（セキュリティ向上）。999 の postgres_data ユーザーが作成されます。