NFSボリュームファイルのアクセス許可
/ myvolumeにNFSボリュームがマウントされたRedhat6.0システム（SELinuxが有効）があります。
コマンド ls -la /myvolumeは、所有者が「nobody」でグループが「nobody」であると言います。
このシステムでは、Apacheを「Apache」ユーザーおよび「Apache」グループとして実行しています。
Apacheはmod_wsgiを介してpythonスクリプトを実行します。このスクリプトは（tempfile.mkdtempを使用して）一時ディレクトリを作成し、その中にいくつかのファイルを作成してから、ディレクトリ全体を/ myvolume内に移動します。
スクリプトが処理を完了した後、スクリプトが作成したファイルには、所有者「nodody」とグループ「nobody」があり、すべてのファイルのアクセス許可マスクは「rwx ------」です。
「Sudo」を使用しない限り、自分のユーザーはこれらのファイルにアクセスできないことを確認しましたが、Apacheユーザーはそれらのファイルにアクセスできます。
なぜこれが起こるのですか？ SELinux、Unixパーミッション、NFSボリューム、またはnodobyユーザーに関連するものはありますか？/myvolume内のファイルを「chown」しようとすると、「無効な引数」エラーが発生するのはなぜですか？
これはnfsに関連しています。
http://tldp.org/HOWTO/NFS-HOWTO/server.html は次のように述べています：
"no_root_squash：デフォルトでは、クライアントマシンのユーザーrootによって行われたファイル要求は、サーバー上のユーザーnobodyによって行われたかのように扱われます（正確にどのUIDに要求がマップされるかは、ユーザー" nobody "のUIDによって異なります。クライアントではなくサーバー。）no_root_squashが選択されている場合、クライアントマシンのrootは、サーバーのrootと同じレベルでシステム上のファイルにアクセスできます。これは、必要な場合もありますが、セキュリティに重大な影響を与える可能性があります。エクスポートされたディレクトリを含むクライアントマシンで管理作業を実行する場合。正当な理由がない限り、このオプションを指定しないでください。」
Nfsサーバーでno_root_squashをアクティブ化することはお勧めしません。このオプションは、文書化の目的でのみ引用しました。
1つの解決策は、同じuidとgidを使用してnfsクライアントとnfsサーバーの両方にユーザーとグループを作成することです。次に、このユーザーでスクリプトを実行するようにApacheを構成します。