Linux システムからエクスポートされ、Solaris システムにインストールされたファイルシステムです。 Solarisシステムでは、このファイルシステムの一部の操作が失敗します。特に：
$ touch z1; install --mode 0444 z1 z2
install: setting permissions for `z2': Operation not supported on transport endpoint
ここの「インストールプログラム」プログラムは、GNU coreutilsバージョン6.12からインポートされます。
これは、サーバー側がNetwork Applianceだったときに機能しました。
「chmod」は権限を設定できますが、「install」は設定できません。正確に何が失敗したかを確認するために「トラス」を実行しましたが、次のようなものが表示されました。
facl(4, SETACL, 4, 0x0004A938) Err#122 EOPNOTSUPP
chmodでtrussを実行すると、別のシステムコールを使用していることがわかります。
chmod("z2", 0444) = 0
サーバーはx86_64でRHEL 6.4を実行しています。次のオプションを使用してファイルシステムをエクスポートします。
rw,async
クライアントはsparc（sun4u）でSolaris 10（SunOS 5.1）を実行しています。次のオプションを使用してファイルシステムをマウントします。
remote/read/write/setuid/devices/rstchown/vers=3/xattr/dev=5d414f4
この問題を解決するために「vers = 3」を追加しましたが、そうではありません。
Network Applianceがファイルシステムを提供するときにこれがうまく機能したことを考慮すると、サーバー側の構成方法に関連していると推測されます。
しかし、私の推測は根拠がないかもしれません。同じサーバーから同じクライアントにマウントされた2つの異なるext4ファイルシステムでは、これらの動作は表示されません。ただし、この場合のインストールオプションは次のとおりです。
remote/read/write/nosetuid/nodevices/rstchown/intr/hard/noquota/xattr/dev=5d41520
そして
remote/read/write/setuid/devices/rstchown/intr/hard/noquota/xattr/dev=5d41521
共通項目は「intr/hard/noquota」です。これがなぜ変化をもたらすのか知っていますか？
回答：@roaimaが正しい方向に向かっていることがわかりました。私は基本的なファイルシステムがすべてext4だと思いましたが、何らかの理由でそのいくつか（作業ファイルシステム）はxfsでした。問題のファイルシステムをxfsに移動し、NFSを介してSolarisシステムに共有したとき、すべてが期待どおりに機能しました。