chattr +i 是内核级不可修改锁，连 root 也无法删除、重命名、写入或截断文件；需 root 或 CAP_LINUX_IMMUTABLE 权限设置，解锁前须用 lsof 确认无进程占用，且不适用于 NFS、overlayfs 等不支持的文件系统。
chattr +i 是让文件真正不可修改的唯一可靠方式
普通 chmod 改权限、chown 换属主，对 root 用户完全无效；只有 chattr +i 能让文件连 root 都无法删除、重命名、写入或截断——这是内核级的属性锁，不是权限系统能绕过的。
- 必须用 root 或具备
CAP_LINUX_IMMUTABLE能力的用户执行，普通用户直接报错Operation not permitted -
+i后，连echo "x" > file、rm file、mv file file.bak全部失败，错误信息统一是Permission denied - 别和
chmod 000混用：后者只影响 POSIX 权限检查，chattr +i才是真拦截；两者叠加不增强效果，反而可能掩盖问题
chattr -i 解锁前必须确认当前没有进程在写这个文件
强行 chattr -i 不会报错，但若此时有程序正打开该文件写入（比如日志服务），解锁后可能立刻被覆盖，导致你刚恢复的配置瞬间丢失。
- 先用
lsof /path/to/file或fuser -v /path/to/file查是否有进程持有句柄 - 常见陷阱：systemd 服务用
StandardOutput=append:/var/log/myapp.log，即使服务停了，journalctl --rotate也可能触发日志轮转并重开文件 - 稳妥做法是：停服务 →
lsof确认无残留 →chattr -i→ 修改 → 再chattr +i
ext4/xfs 文件系统支持差异直接影响 chattr 行为
chattr 不是“所有 Linux 都一样”，底层文件系统决定哪些属性可用。比如 +a（仅追加）在 ext4 上有效，在 xfs 上需挂载时加 inode64 或 big_writes 才稳定支持。
- 查看支持情况：
tune2fs -l /dev/sda1 | grep "Filesystem features"（ext4）或xfs_info /mount/point（xfs） -
+i和+a在主流发行版默认 ext4/xfs 上都支持，但某些容器镜像用 overlayfs 或 tmpfs，chattr直接报错Operation not supported - 别在 NFS 挂载点上试
chattr：服务端不支持时，客户端命令看似成功，实际没生效
误删 chattr +i 的关键文件（如 /etc/passwd）怎么救
不是靠备份还原，而是靠紧急模式下绕过属性锁——因为 +i 锁的是 VFS 层操作，不阻止内核模块或 initramfs 级别的直接块写入。
- 重启进 recovery mode 或使用 live USB，挂载根分区为可写：
mount -o remount,rw /dev/sda2 /mnt - 切到挂载点：
chroot /mnt，再执行chattr -i /etc/passwd - 真正危险的是：如果 /boot 分区也设了
+i，grub 可能无法更新内核，得手动mount /boot后再解锁
最常被忽略的一点：chattr +i 对符号链接本身有效，但不保护它指向的目标文件——想锁配置文件，得锁文件本体，不是锁 /etc/nginx/conf.d/default.conf 这个路径名。
