日志无法写入通常是权限问题，需依次检查目录及文件属主权限、运行用户是否在adm组、SELinux/AppArmor限制、父目录执行权限。
日志无法写入，八成是权限没配对。不是用户没权限，就是目录或文件的属主、组、权限位卡住了，再或者被 SELinux 拦了。下面几块直接对应常见堵点，照着查基本能定位。
检查日志路径的属主与权限
日志写入失败，第一眼看 /var/log/ 下目标目录和文件本身的权限是否合理：
- 用
ls -ld /var/log/your_app/查目录权限，确保 rsyslog 或应用运行用户（如 www-data、nginx）有写权限；常见安全配置是drwxr-s--- root:adm，此时需保证用户在 adm 组里 - 用
ls -l /var/log/your_app/app.log查日志文件权限，640 或 644 较稳妥；若为 444 或 600 且非 root 运行，则普通服务进程必然写不进 - 确认应用进程实际运行用户：比如
ps aux | grep nginx看 worker 是用哪个用户启的，再比对文件属主和组
验证用户是否在必要系统组中
很多日志目录（如 /var/log/）默认只允许 root 和 adm 组成员读写。如果应用以普通用户启动，但不在 adm 组，就会被拒：
- 运行
groups your_user看是否含adm；不含就加：sudo usermod -aG adm your_user - 加完别忘了重启服务，让新组权限生效；也可以临时切用户测试：
sudo -u your_user touch /var/log/test.log - 某些发行版还依赖
syslog组，可一并检查
排查 SELinux 或 AppArmor 干预
CentOS/RHEL 系统默认启用 SELinux，它可能静默阻止日志写入，即使权限和属主都对：
- 执行
sestatus看当前模式；若为Enforcing，先临时切宽容模式验证：sudo setenforce Permissive - 再试写日志，若恢复，说明是 SELinux 策略问题；可查拒绝记录：
sudo ausearch -m avc -ts recent | audit2why - 永久修复建议用
audit2allow生成策略模块，而不是长期关闭 SELinux
留意父目录的执行（x）权限
Linux 中进入目录需要执行权限（x），而不仅是写（w）。如果日志路径某一级目录缺少 x 权限，进程连“走进去”都做不到：
- 例如路径
/var/log/myapp/，需确保/var、/var/log、/var/log/myapp每一层对运行用户都有x权限 - 典型错误：把
/var/log/myapp设为700，但运行用户不是 owner，就卡在“Permission denied”——其实不是没写权限，是根本进不去 - 修复：给目录加执行位，如
sudo chmod 755 /var/log/myapp，或更精准地设为750+ 正确属组
