从 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”则不能。我运行“truss”来查看到底发生了什么故障，它显示了以下内容：
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 提供服务时，这曾经工作得很好，我猜测它与服务器端的配置方式有关。
但我的猜测可能没有根据。我发现从同一服务器安装到同一客户端的另外两个 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 机器时，一切都按预期进行。