在深入探讨如何在不同的Linux机器上同步UID / GID的深度之前，我想知道实际上的好处是什么？
我知道这使得文件同步相对容易（因为所有权是“自然”保留的）。 然而这也可以根据传输服务来实现。
还有其他什么可以从一致的UID / GID中受益吗？
由于以下原因，早期解决这个问题要避免技术债务的积累要简单得多 。 即使你发现自己已经在这种情况下，在不久的将来处理它可能会比继续build设更好。
这个问题似乎集中在使用本地文件系统的机器之间传输文件的狭窄范围，这允许机器特定的所有权状态。
networking文件系统的考虑很容易成为试图保持你的UID / GID映射同步的最大案例，因为通常可以抛出你在窗口input图片时提到的“实现”。 当然，你现在可能没有在这些主机之间共享networking文件系统…但是未来呢？ 你能诚实地说，在你当前的主机或将来创build的主机之间不会引入networking文件系统吗？ 否则就不是很有前瞻性的想法。
假设/home是以下示例中host1和host2共享的networking文件系统。
/home/user1由每个系统上的不同用户拥有。 这样可以防止用户在系统间始终访问或修改主目录。 host2上的这个问题会破坏host1上的权限。 在有人退后一步，意识到拔河正在发挥作用之前，有时候可能需要将这些门票中的一些工作。 唯一的解决办法是修复不一致的ID映射。 这导致… user1具有user2的ID，但user2具有user17的ID，这就是群集中的第一个系统）解决问题的等待时间越长，这些链可能越复杂，通常需要停机时间应用程序在多个服务器上，以便正确地同步。 host2上的user2与host1 user1具有相同的UID，允许它们在不知道user1情况下写入host2上的/home/user1 user1 。 然后使用user1的权限在host1上评估这些更改。 什么可能会出错？ （如果user1是一个应用程序用户，dev中的某个人会发现它是可写的，并且会进行更改，这是一个久经考验的事实。） 还有其他一些情况，这些只是最常见的例子。
使用数字ID编写的任何脚本或configuration文件在您的环境中都变得固有不可移植。 一般来说不是一个问题，因为大多数人不会硬编码这些，除非他们绝对需要…但是有时你正在使用的工具并不能给你一个select。 在这些情况下，您不得不维护n个不同版本的脚本或configuration文件。
例如： pam_succeed_if允许您使用user ， uid和gid字段…显然不存在“group”选项。 如果你被置于一个要求多个系统实现某种forms的基于组的访问限制的位置，那么你将有n个不同的PAMconfiguration变体。 （或至less一个GID，你必须避免碰撞）
natxo的答案已经覆盖得很好。
一旦你达到一定的规模（而且总是比你想象的要快），你会发现在所有的主机上改变你的密码或者禁用某个人的帐户是一个PITA。 这就是为什么人们使用LDAP数据库（或NIS，但不这样做，现在不安全）的系统，如openldap或现在的优秀的freeipa。
您将所有帐户/组信息保留在中央数据库中，所有主机都共享该信息。 您可以从这里做更多的事情：当然，使用用户信息获得文件权限，但也为所有具有ldap绑定的应用程序创build虚拟用户，而不必在那里创build用户（许多Web应用程序可以使用ldap为他们的用户数据库），维护一个中央sudo规则数据库，分发您的autofs环境，保持您的dns区域，…