为什么 filesync 命令不会在远程文件夹上执行 chown？ （Solaris，共享）
Why won't filesync command chown on remote folder? (Solaris, share)
我有两台几乎相同的测试服务器，分别是 solaris 10 和 Sun Directory Server。我正在尝试在两者之间创建一种自动方法来同步指定的文件夹。 （这些将是主文件夹和应用程序文件夹。）
所以目前的目标是将 srv1 服务器 /export/test 文件夹中的文件同步到 srv2 服务器 /export/test 文件夹。
我做了什么：
srv2: #share -o rw,root=remotesync /export/test
srv1: #filesync -a -s /export/test -d /net/192.100.55.2/export/test/ -f '*'
这会将文件从 srv2/export/test 复制到 srv1/export/test，但不会保留权限，并为所有文件提供（无法更改）错误。
有人可以帮助我吗？我认为这与分享有关，但我可以使用一些有经验的评论。谢谢
鉴于文件系统是从 srv2 共享的
srv2: #share -o rw,root=remotesync /export/test
根据 share man page:
，您的进程没有来自 srv1 的 root 权限
root=access_list
Only root users from the hosts specified in access_list have root access. See access_list below. By default, no host has root access, so
root users are mapped to an anonymous user ID (see the anon=uid option
described above). Netgroups can be used if the file system shared is
using UNIX authentication ( AUTH_SYS).
仔细阅读关于access_lists的部分。
所以 chown(2) 的条件是：
The operating system defines several privileges to override
restrictions on the chown() family of functions. When the
{PRIV_FILE_CHOWN} privilege is asserted in the effective set of the
current process, there are no restrictions except in the special
circumstances of changing ownership to or from uid 0. When the
{PRIV_FILE_CHOWN_SELF} privilege is asserted, ownership changes are
restricted to the files of which the ownership matches the effective
user ID of the current process. If neither privilege is asserted in
the effective set of the calling process, ownership changes are
limited to changes of the group of the file to the list of
supplementary group IDs and the effective group ID.
您的进程在 NFS 服务器上没有 root 访问权限，并且几乎可以肯定在文件服务器上具有零额外权限，即使您在 NFS 客户端上 运行 作为 root，因此 chmod 失败 EPERM:
EPERM
The effective user ID does not match the owner of the file and the {PRIV_FILE_CHOWN} privilege is not asserted in the effective set of
the calling process, or the {PRIV_FILE_CHOWN_SELF} privilege is not
asserted in the effective set of the calling process.
关键字是 "almost equivalent"。我在其中一台机器上丢失了 resolv.conf 文件，因此在使用共享命令时域名被弄乱了。
我有两台几乎相同的测试服务器，分别是 solaris 10 和 Sun Directory Server。我正在尝试在两者之间创建一种自动方法来同步指定的文件夹。 （这些将是主文件夹和应用程序文件夹。） 所以目前的目标是将 srv1 服务器 /export/test 文件夹中的文件同步到 srv2 服务器 /export/test 文件夹。
我做了什么：
srv2: #share -o rw,root=remotesync /export/test
srv1: #filesync -a -s /export/test -d /net/192.100.55.2/export/test/ -f '*'
这会将文件从 srv2/export/test 复制到 srv1/export/test，但不会保留权限，并为所有文件提供（无法更改）错误。
有人可以帮助我吗？我认为这与分享有关，但我可以使用一些有经验的评论。谢谢
鉴于文件系统是从 srv2 共享的
srv2: #share -o rw,root=remotesync /export/test
根据 share man page:
srv1 的 root 权限
root=access_list
Only root users from the hosts specified in access_list have root access. See access_list below. By default, no host has root access, so root users are mapped to an anonymous user ID (see the anon=uid option described above). Netgroups can be used if the file system shared is using UNIX authentication ( AUTH_SYS).
仔细阅读关于access_lists的部分。
所以 chown(2) 的条件是：
The operating system defines several privileges to override restrictions on the chown() family of functions. When the {PRIV_FILE_CHOWN} privilege is asserted in the effective set of the current process, there are no restrictions except in the special circumstances of changing ownership to or from uid 0. When the {PRIV_FILE_CHOWN_SELF} privilege is asserted, ownership changes are restricted to the files of which the ownership matches the effective user ID of the current process. If neither privilege is asserted in the effective set of the calling process, ownership changes are limited to changes of the group of the file to the list of supplementary group IDs and the effective group ID.
您的进程在 NFS 服务器上没有 root 访问权限，并且几乎可以肯定在文件服务器上具有零额外权限，即使您在 NFS 客户端上 运行 作为 root，因此 chmod 失败 EPERM:
EPERM
The effective user ID does not match the owner of the file and the {PRIV_FILE_CHOWN} privilege is not asserted in the effective set of the calling process, or the {PRIV_FILE_CHOWN_SELF} privilege is not asserted in the effective set of the calling process.
关键字是 "almost equivalent"。我在其中一台机器上丢失了 resolv.conf 文件，因此在使用共享命令时域名被弄乱了。