Linux 文件权限正确却删除失败怎么查：lsattr、chattr 不可变位与挂载属性

删一个 root 用户也能写入的日志文件，却收到“Operation not permitted”，这类问题通常不是普通的读写权限。先检查文件属性，再判断目录权限和挂载状态，能把“权限看着没问题”的误判拆开。

删除失败时先执行 lsattr -- /var/tmp/app.log；如果结果含有 i，先用 chattr -i 解除不可变位，再重新检查目录权限和挂载属性。

先把“权限正常”拆成三个检查面

Linux 删除文件看的是父目录的写入和执行权限，而不是文件本身的写权限。除此之外，文件的扩展属性和文件系统是否以只读方式挂载，也会在更早的层面拒绝操作。排查时不要一上来就递归改权限，先保留现场。

target=/var/tmp/app.log
ls -l -- "$target"
namei -l -- "$target"
lsattr -- "$target"
findmnt -T "$target" -o TARGET,SOURCE,FSTYPE,OPTIONS

这里的四条命令分别回答：文件当前模式是什么、路径上的目录权限如何、扩展属性是否含有 i、目标路径落在哪个挂载点以及是否带有 ro。先看结果再决定修复动作。

lsattr 里的 i 为什么会拦住删除

lsattr 输出中的 i 是 immutable 属性。被标记的文件不能被修改、删除或重命名，即使文件模式是 -rw-r--r--，也可能返回 Operation not permitted。如果属性来自目录，还要继续检查目录本身，不能只盯着文件。

$ lsattr -- /var/tmp/app.log
----i--------- /var/tmp/app.log

$ rm -- /var/tmp/app.log
rm: cannot remove '/var/tmp/app.log': Operation not permitted

这时先记录属性，再判断变更是否经过审批。对业务日志、系统配置和证据文件，解除保护前应确认没有备份、审计或保留策略要求。

用 chattr -i 做最小修复

确认目标就是误加的不可变位后，使用精确路径解除属性，不要对整个目录递归执行。下面的顺序把“解除属性”和“删除文件”分成两个动作，中间可以插入复核。

target=/var/tmp/app.log
sudo chattr -i -- "$target"
lsattr -- "$target"
sudo rm -- "$target"

第二次 lsattr 不应再出现 i。删除命令成功后用 test ! -e 检查路径已经消失；如果仍然失败，回到父目录权限与挂载属性，不要重复执行 chattr。

解除 i 仍失败时看目录和挂载点

目录没有写权限时，删除动作依然会失败。namei -l 能把 /var、/var/tmp 和目标文件的权限逐段列出来；目录至少需要对执行删除的用户开放写和执行权限。若 findmnt 的选项中出现 ro，则是文件系统只读，应该处理挂载或底层存储故障。

namei -l -- /var/tmp/app.log
findmnt -T /var/tmp/app.log -o TARGET,OPTIONS
test -w /var/tmp && test -x /var/tmp && echo "parent directory writable"
test ! -e /var/tmp/app.log && echo "delete verified"

如果是只读挂载，不要直接执行 mount -o remount,rw 作为默认答案。先确认为什么变成只读、是否存在 I/O 错误，再按机器的变更流程恢复；对生产盘来说，保护数据比立即删除一个文件更重要。

常见问题

文件权限是 644，为什么还是不能删除？

删除主要受父目录权限、不可变位和挂载模式影响。644 只描述文件模式，不能证明这三个检查面都允许删除。

chattr -i 会改变文件内容吗？

不会。它只移除 immutable 属性，但这个动作本身需要足够权限，并且应先确认保护位确实可以解除。

lsattr 没有 i 还要查什么？

继续看父目录的写和执行权限，再用 findmnt -T 检查是否只读；必要时查看内核日志中的存储错误。

把修复结果留成可复查证据

一次合格的验收至少包括：lsattr 不再显示 i，目标挂载点不是只读，父目录允许当前操作者写入和访问，最后用 test ! -e 得到删除后的明确状态。这样下次遇到相同错误，能区分属性保护、目录权限和存储故障，而不是继续盲目改 chmod。