chmod 误改 000 怎么恢复？Linux 下的 6 种救命方案

前两天有个哥们在群里发了个救命信号，说手滑把 chmod 命令的权限改成了 000，整个人都麻了。
这事儿听起来像段子，但真遇上了，那可是要命的操作——chmod 没了执行权限，你就没法再用 chmod 去改权限，这不就成死循环了吗？

为什么会出现这种致命操作

说白了，就是手快脑子没跟上。很多人在服务器上批量改权限的时候，习惯性地敲 chmod -R 000 /some/path，结果路径没写对，或者直接手抖把 /usr/bin/chmod 给改了。
还有一种情况是写脚本的时候，变量没赋值好，导致 chmod 把自己给废了。
这种事儿在凌晨三点加班改配置的时候特别容易发生，困得眼睛都睁不开，手指头在键盘上乱飞，等反应过来的时候，chmod 已经躺平了。
更要命的是，很多公司的生产环境还没有快照备份，这一下就真的是叫天天不应了。

几种实战恢复方案

方案一：用 Perl 救场

Linux 系统里一般都自带 Perl，而 Perl 可以直接调用系统调用来修改文件权限。
这招算是最快的：

perl -e 'chmod 0755, "/usr/bin/chmod"'

一行命令搞定，chmod 立马复活。
这个方法的原理是绕过 chmod 命令本身，直接通过 Perl 的 chmod 函数去操作文件系统。

方案二：Python 也能顶上

如果服务器上有 Python（现在哪台服务器没 Python 啊），那就更简单了：

python -c "import os; os.chmod('/usr/bin/chmod', 0o755)"

或者 Python 3：

python3 -c "import os; os.chmod('/usr/bin/chmod', 0o755)"

这个方法和 Perl 一个道理，都是通过编程语言的系统调用接口来改权限。

方案三：从其他机器拷贝

如果你有另一台相同系统的机器，可以直接把正常的 chmod 拷过来：

scp user@other-server:/usr/bin/chmod /tmp/chmod
/tmp/chmod 755 /usr/bin/chmod

注意要先拷到 /tmp 目录，因为 /tmp 一般都有执行权限。
这招适合有多台服务器的场景，但要确保系统版本一致，不然可能会有兼容性问题。

方案四：用 busybox 救命

有些精简系统会装 busybox，它自带了一套独立的工具集：

busybox chmod 755 /usr/bin/chmod

busybox 就像是 Linux 工具箱的备胎，关键时刻能救命。

方案五：LD_PRELOAD 黑科技

这个方法比较硬核，适合实在没办法的情况。
可以写个共享库来劫持系统调用：

// fix_chmod.c
#include <sys/stat.h>
int chmod(const char *path, mode_t mode) {
    return syscall(90, "/usr/bin/chmod", 0755);
}

编译后用 LD_PRELOAD 加载，但这个方法太复杂，一般不推荐。

方案六：LiveCD 大法

实在不行就用 LiveCD 或 U盘启动盘进系统，挂载硬盘后直接改：

mount /dev/sda1 /mnt
chmod 755 /mnt/usr/bin/chmod

这招最稳，但需要物理接触服务器，云服务器就比较麻烦了。

如何避免再次踩坑

这种低级错误其实完全可以避免。  

首先，操作生产环境之前一定要先在测试环境验证，别直接在线上瞎搞。  

其次，写脚本的时候多加几层检查，尤其是涉及到权限修改的操作，最好加个二次确认。  

还有就是养成备份的习惯，不管是快照还是定期备份，关键时刻能救命。很多人觉得备份麻烦，但真出事了才知道，那点时间成本根本不算什么。  

另外，操作敏感命令的时候，可以给自己设置个别名，比如把 chmod -R 改成需要确认的版本，或者干脆用 chmod -c 让它输出修改信息，这样至少能及时发现问题。  

最重要的是，别在状态不好的时候操作服务器。困了就睡觉，别硬撑着改配置，手滑一次可能就是一个通宵的代价。  

更多运维实战案例，可以来 云栈社区 一起探讨。