chattr +a 仅防截断写入，不防删除；防删需用 chattr +i 或对父目录设 +a。+a 对文件无效于 rm/mv，对目录则禁止删改条目；xfs/btrfs 可能不支持该属性。
chattr +a 只能防覆盖，不能防删除；真要防删，得用 chattr +i 或控制父目录权限。
chattr +a 的真实能力边界
它只限制对文件本身的 open(O_WRONLY|O_TRUNC) 和 open(O_RDWR|O_TRUNC) 系统调用，也就是禁止 echo "x" > file 或 vim file 这类截断写入。但 rm file、mv file old、touch file 全部照常成功——因为这些操作不作用于文件 inode，而是修改父目录的目录项。
常见误判现象：
-
lsattr file显示有a，但rm file仍成功 - 日志轮转（logrotate）失败，报
Permission denied，其实是rename()被拒，不是rm - 在 XFS/Btrfs 上执行
chattr +a不报错，但strace -e trace=openat,unlink echo test > file显示截断写仍被允许——文件系统根本不支持该属性
想真正阻止删除，只有两个靠谱选择
一是用 chattr +i：文件级彻底锁定，rm、mv、echo > 、truncate 全部拒绝，连 root 都不行。但代价是无法追加——echo x >> file 同样失败。
二是锁父目录：chattr +a /var/log/myapp。此时目录本身变成“只允许新建/追加，禁止删除或重命名任何条目”。已有文件如 /var/log/myapp/app.log 仍可 echo x >> app.log，但 rm app.log 会报 Operation not permitted。
注意：chattr +a 加在目录上后，touch、cp 新文件仍被允许；而 chattr +i 加在目录上，则整个目录冻结，连 touch 都失败。
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
logrotate 和 systemd-journald 场景下的实操陷阱
默认 logrotate 使用 rename() 替换旧日志，一旦父目录被 +a，rotate 就卡住。必须显式配置：
- 加
copytruncate：先复制内容再清空原文件，绕过 rename - 或改用
create 640 user group+postrotate中手动chattr +a /path/to/logfile
systemd-journald 默认不兼容 +a 目录——它依赖在 /var/log/journal/xxx 下自由创建和轮转文件。若强行加 +a 到该目录，journalctl 会报 Failed to rotate logs 并停写。
验证是否生效，别只信 lsattr 输出。必须实测：
-
echo test > logfile→ 应报Permission denied -
echo test >> logfile→ 应成功 -
rm logfile→ 若成功，说明你锁的是文件而非目录，或文件系统不支持
替代方案：ACL + sticky bit 更适合多用户协作场景
如果既要多人可追加、又要防误删历史文件，chattr 反而太重。推荐组合：
- 设目录
chmod 2770 /data/logs（setgid + sticky bit） - 用
setfacl -d -m u::rw-,g::r--,o::- /data/logs控制新文件默认权限 - 给用户
setfacl -m u:appuser:rwx /data/logs
这样 appuser 能 echo x >> /data/logs/app.log，也能 touch new.log，但删不了别人创建的文件（sticky bit 生效），也改不了已有文件内容（默认无写权限）。比硬上 +i 或 +a 更灵活，且兼容 logrotate。
最易被忽略的一点：所有 chattr 操作都依赖文件系统支持。执行前务必确认：stat -f /mount/point | grep Type，ext4 安全，XFS 和 Btrfs 则大概率静默失效。
