可能重复：
恢复 chmod 777 / -R
我在服务器上chown someuser * -R时意外执行了。 我以为也许通过发布可以以某种方式修复它。但似乎存在一些问题。 例如，现在当我尝试登录时，DirectAdmin 表现得很奇怪。它说：/chown root * -R
无法确定用户类型
user.conf 需要修复
有什么办法可以解决此情况吗？
更新：我想也许可以通过编写一个 shell 脚本来解决这个问题，该脚本检查每个文件的组并相应地设置用户，因为据我所知，通常所有文件的用户和组值都相同。
答案1
真不幸！
您发出的后一个命令的作用是将所有文件的所有权更改为 root。因此，任何设置为 suid（设置 UID，以便它们以其所有者的权限运行）的文件都将以 root 权限运行，并且用户将不拥有其主目录。对此要非常小心。考虑使用 ls 搜索此类文件，因为如果您的用户有任何 suid shell 脚本或诸如此类的东西，这可能是一个严重的安全问题。
你面临一个困难的情况；你现在必须确定谁应该拥有哪些文件，并手动分配。在某些情况下，重建会比执行此操作更容易，特别是如果你有配置备份（我假设你备份了数据）。如果没有，请立即备份所有内容，以便在重建时有参考。但是，如果你不介意一点不准确，这里有一些简单的规则：
- 用户应该拥有其主目录中的所有文件。对于每个用户，
chown -R username ~username. - 更改其自身文件的服务通常应由运行 Web 应用程序的用户拥有。虽然您可以配置这一点，但如果您使用的是 apache，则该用户通常称为 apache。对于每个此类应用程序的 webroot
chown -R apache /path/to/webroot，。 - 类似地，服务将更改的文件和目录（例如上传目录）应归服务运行的用户所有。对于它们中的每一个，
chmod -R username /path/to/filesystem/object。 - 属于系统服务的 SSL 私钥通常应由 root 拥有（并且只能由所有者读取）。它们的存储位置各不相同，但在所有情况下，您或您的前任都会将它们放在那里。找到它们，并
chown root somefile.key针对每个进行操作。 - 如果应用程序的配置文件的读取权限仅限于所有者，但在放弃 root 权限后读取了这些文件，则该应用程序必须拥有这些文件（这听起来很像您的 DirectAdmin user.conf，可能的话，如果它听起来是这样的话）
chown username /path/to/file。
尽管如此，您还是应该考虑从备份中恢复用户的主目录，因为他们可能设置了各种权限，并在其中保存了各种内容。这样做有助于避免开头提到的安全风险。
您无法根据组推断所有者。例如，用户主目录中的文件通常具有所有权username:users。此外，许多文件都有特定的所有者可以编辑它们，特定的组可以读取和执行它们，而其他用户则没有权限。这也会导致奇怪的行为，或者只是失败（组不需要与用户相对应）。
祝你好运！如果你选择不重建，从现在起直到永远，如果你发现有关文件损坏或权限不正确的奇怪错误，你将不得不检查所有权。