root 删除文件报 Operation not permitted：检查 immutable 属性

文件属于 root，执行 sudo rm 仍提示 Operation not permitted，甚至按 inode 找到同一个文件后再删除也失败。这时值得检查文件的 immutable 属性：如果 lsattr 的属性列含有小写 i，文件会被禁止删除、重命名和写入，普通权限位改成可写也不能解除这项保护。

这条处理路径适用于支持相应文件属性的 Linux 文件系统。不同文件系统支持的属性有差异；如果属性读取失败，不能据此认定目标没有保护，也不能把所有删除失败都归因于 immutable。

先确认失败的是哪个对象

以下路径均为示例。将文件路径换成实际目标，父目录也要对应，先运行只读检查：

ls -ld -- /srv/example-app /srv/example-app/protected.dat
lsattr -d /srv/example-app /srv/example-app/protected.dat

ls -ld 用来确认目标类型、属主和普通权限。lsattr -d 检查文件及目录自身的属性，避免把目录里的所有文件列出来。示例输出可能类似：

--------------e------- /srv/example-app
----i---------e------- /srv/example-app/protected.dat

这里的小写 i 才表示 immutable；e 表示 extent 格式，不是禁止删除的标志。大小写不同的 I 也不是 immutable。

目标文件带 i 时，删除该文件会受到限制。父目录自身带 i 时，创建、删除或重命名其中条目也会受限制；只解除子文件的属性可能仍然无法完成操作。检查发现是目录保护时，先确认为什么整个目录需要保护，不要直接对目录树递归清除属性。

若原来的操作是删除一个目录树，而报错只指向其中一个文件，应缩小到该路径判断。rm -f 只能改变交互和部分错误处理，不能绕过文件系统的删除限制。

获得授权后，只解除明确需要修改的保护

先确认文件的用途、保护设置的责任人，以及这次需要删除还是修改。保留可恢复的内容、属主、权限和属性记录；如果文件来源不明，先留存调查证据，不要仅凭文件名或异常权限认定它是恶意程序。

对于已经确认可以修改的单个文件，示例操作为：

sudo chattr -i /srv/example-app/protected.dat
lsattr -d /srv/example-app/protected.dat

第一条解除该文件的 immutable 属性，第二条核对属性列是否确实不再有 i。这一步本身不会删除文件，也不会修改其普通权限。随后才按已批准的目的编辑、替换或删除目标；删除会丢失内容，应有独立备份，不能把清除属性当成备份。

如果只是修改内容，完成内容、属主和权限核对后，可以恢复原本需要保留的保护：

sudo chattr +i /srv/example-app/protected.dat
lsattr -d /srv/example-app/protected.dat

再次设置 i 可能使应用后续更新该文件失败，因此应按文件的管理规则决定恢复时机。已经删除的文件不能靠 chattr +i 恢复；恢复时需要先从备份还原文件，再核对元数据并恢复属性。

清除属性需要相应权限。容器内 UID 为 0，并不保证进程拥有 CAP_LINUX_IMMUTABLE，也不保证底层存储允许修改该属性。如果 chattr 也报 Operation not permitted，先确认这是宿主机还是受限容器、实际能力和挂载限制；不要为一次文件维护把整个容器改成 privileged。

没有 i，就沿着实际错误继续查

Operation not permitted 并不唯一对应 immutable。append-only 的小写 a 也会限制删除，父目录限制、安全策略及特定存储规则都可能影响操作。应记录属性输出和完整报错，再查对应规则。

如果报错是 Read-only file system，应检查挂载和存储状态，而不是反复清除 i。只读挂载可能是有意配置，也可能来自文件系统异常；直接改成可写前需要确认原因。若是 Permission denied，普通目录权限、路径遍历权限及访问控制也需要单独检查。

解除属性后的成功标准是：lsattr 显示批准解除的保护已消失，预期的单文件操作成功，其他文件和目录的属性保持原状。编辑后还要核对内容；删除后核对的是目标条目已移除，不能把命令没有打印信息当成恢复和业务验证都已完成。