答案：排查日志写入失败是否由文件权限不足引起，需依次验证三件事：当前用户对日志文件是否有写权限、对日志目录是否有写+执行权限、Java（或其他应用）进程实际运行用户是否匹配权限设置；再检查磁盘空间、SELinux/AppArmor及日志框架路径配置等干扰因素。
排查日志写入失败是否由文件权限不足引起，关键不是“猜”，而是按顺序验证三件事：当前用户有没有对日志文件的写权限、有没有对日志所在目录的写+执行权限、Java（或其他应用）进程实际以哪个用户身份在运行。
确认日志路径的权限和归属
先查清楚目标日志文件和它所在的目录到底被设成了什么权限：
- 运行
ls -l /path/to/app.log，看文件权限字段（如-rw-r--r--），重点确认“所有者”列是否是运行应用的用户；如果显示root:root而应用是普通用户启动的，那基本就是权限问题。 - 再运行
ls -ld /path/to/log/，检查目录权限——必须同时有w（写）和x（执行）才允许创建或覆盖日志文件；如果只有r-x或rw-，写入一定失败。 - 用
id查当前用户属于哪些组，再对比日志文件所属组，看是否匹配；不匹配时，即使目录给了组写权限也无效。
核实 Java 进程的实际运行用户
很多故障根源在于“你以为是 userA 启动的，其实是 root 或其他用户”。不能只看你是用谁登录的，要看进程本身：
- 执行
ps -ef | grep java，找到你的应用进程，看第二列（UID）是谁。比如显示root 12345 ... java -jar app.jar，说明它以 root 身份运行，那日志路径就必须对 root 可写。 - 如果是 systemd 管理的服务，查它的 service 文件：
systemctl cat your-app.service，重点关注User=和Group=设置项。 - 若用 nohup 或后台脚本启动，检查启动脚本里是否用了
sudo或切换了用户（如su -c）。
验证并修复权限配置
确认问题后，别直接 chmod 777 ——最小权限原则优先：
- 如果日志文件归 root 所有，但应用应以
appuser运行：用sudo chown appuser:appuser /var/log/myapp/改目录归属，再sudo chmod 755 /var/log/myapp/（目录需 x）。 - 如果日志文件已存在且属主不对：
sudo chown appuser:appuser /var/log/myapp/app.log；如果应用会自动重建日志，删掉旧文件让其重生成更稳妥。 - 避免只改文件权限却不改目录：
chmod 644 app.log没用，除非目录本身允许appuser写入和进入。
排除干扰因素
权限只是常见原因，但不是唯一原因。快速过一遍其他可能性，避免白忙活：
-
磁盘空间或 inode 耗尽：运行
df -h和df -i，尤其关注日志所在分区；No space left on device错误也可能由 inode 满导致。 -
SELinux 或 AppArmor 强制限制：临时禁用测试（
sudo setenforce 0），如果日志立刻恢复，说明是策略拦截，需调整上下文而非单纯改 chmod。 -
日志框架配置路径错误：检查 logback.xml 或 log4j2.xml 中的
logs/app.log），而实际工作目录并非预期位置。
