CentOS的灾难恢复-chmod对整个根目录赋予000权限

每日一个跑路小命令，没准哪天能用上呢【滑稽】，切勿在生产环境使用，切勿在生产环境使用，切勿在生产环境使用

在Linux系统管理中，错误地对根目录（/）递归执行 chmod 000 命令，会引发严重的系统故障。本文将详细介绍在CentOS系统上，如何从这种极端的文件权限故障中恢复系统。

进入救援模式修复系统

由于操作系统本身已无法启动，我们必须借助外部的、独立的运行环境来进行修复。方法是使用CentOS安装镜像（ISO）提供的救援模式（Rescue Mode）。

首先，将系统安装镜像挂载到服务器，并设置从该镜像启动。

1. 在系统引导菜单中，选择 Troubleshooting（故障排查）选项。
2. 接着，在下一级菜单中选择 Rescue a CentOS system（救援一个CentOS系统）。

救援程序启动后，会扫描硬盘并尝试定位已安装的系统。随后，程序会提供一个交互式菜单，包含几个挂载选项，此处的选择非常关键。

1) Continue
2) Read-only mount
3) Skip to shell
4) Quit (reboot)

• 选项 1 (Continue)：该选项会尝试以读写模式挂载系统分区并自动执行 chroot。此操作将会失败，因为目标系统内的 /bin/bash 等所有基础命令均无执行权限，chroot 无法成功建立环境。
• 选项 2 (Read-only mount)：该选项以 只读模式 将系统分区挂载到 /mnt/sysroot 目录，且不执行 chroot。这是正确的选择，它使我们能够安全地访问到损坏的系统文件，为后续修复做准备。

请选择选项 2 并按回车，系统将进入救援模式的命令行Shell。

恢复文件系统权限

进入救援环境后，我们的核心任务是逐步恢复系统文件的正确权限。整个过程分为三个主要步骤。

第一步：重新挂载为读写模式

救援模式默认以只读方式挂载分区以防止误操作。要进行修复，我们首先需要获取写入权限。执行以下命令，将分区重新挂载为读写（rw）模式：

mount -o remount,rw /mnt/sysroot

可以通过 mount | grep sysroot 命令检查挂载状态，确认其已从 ro（只读）变为 rw（读写）。

第二步：临时授予所有权限

当前，我们仍无法 chroot 到 /mnt/sysroot，因为目标环境内的命令依然没有执行权限。为了解决这个问题，需要一个临时的、直接的措施来恢复文件的可执行性。

chmod -R 777 /mnt/sysroot

此命令将原系统根分区下的所有文件和目录权限设置为 777，确保了所有内容都可读、可写、可执行。虽然这会造成暂时的权限混乱，但它是执行后续修复步骤的必要前提。

第三步：切换环境并使用RPM数据库恢复

在所有文件都具备执行权限后，我们便可以成功地 chroot 到原系统环境中，进行更精确的权限修复。

chroot /mnt/sysroot

执行此命令后，命令行提示符会改变，表示当前操作环境已切换到原系统的根目录。

此时，问题已经从“如何从 000 权限恢复”转变为“如何从 777 的混乱权限恢复到系统默认状态”。幸运的是，RPM包管理器在其数据库中保存了所有已安装软件包的元数据，包括每个文件的初始权限。我们可以利用这一点来恢复绝大多数文件的权限。

执行以下命令，让RPM遍历所有软件包并重置其文件权限：

rpm -qa | xargs rpm --setperms

• rpm -qa 用于查询所有已安装的软件包名称。
• xargs 将查询结果传递给 rpm --setperms 命令，该命令会根据RPM数据库中的记录，为每个软件包中的文件恢复其默认权限。

这个过程可能需要一些时间。完成后，系统中绝大部分文件的权限都已恢复正常。

手动修复特殊文件权限

完成上述步骤后，虽然系统核心组件的权限已恢复，但整个修复工作尚未结束。rpm --setperms 命令只能恢复由RPM软件包自身包含的文件的权限。对于那些在软件安装后由服务自动生成的文件（如SSH主机密钥）、用户自行创建的数据、或从源码编译安装的程序，它们的权限仍然是之前设置的 777。我们需要手动检查并修复这些特殊文件，其中SSH服务是需要优先处理的最典型例子。

系统重启后，请使用控制台登录并检查SSH服务的状态：

systemctl status sshd

通常会发现服务启动失败。要定位具体原因，可以查看服务日志：

journalctl -u sshd

日志中会出现类似 Permissions ... for '/etc/ssh/ssh_host_..._key' are too open 的关键错误信息。这是因为SSHD守护进程出于安全考虑，会检查其密钥文件的权限。如果发现私钥文件（例如主机密钥）的权限过于开放，它会拒绝加载这些密钥，从而导致服务启动失败。

修复方法是手动为SSH的配置文件和密钥设置严格的权限。一个安全有效的做法是：

chmod -R 600 /etc/ssh/

该命令将 /etc/ssh/ 目录及其下所有文件的权限设置为 600，即仅文件所有者（root）拥有读写权限，符合SSH的安全要求。

完成权限修改后，重新启动并检查SSH服务：

systemctl restart sshd
systemctl status sshd

此时，服务状态应显示为 active (running)。

修复SSH后，建议举一反三，检查系统中其他关键服务的状态，例如Web服务器（httpd, nginx）、数据库（MariaDB）等。如果发现有服务启动失败，遵循同样的方法，通过 journalctl -u <服务名> 查看日志，定位因权限问题导致的错误，并进行手动修复。此外，也应检查 /home、/srv、/opt 等目录下用户数据的权限是否需要调整。