Node.js 应用上线后，日志文件往往既承载排错信息，也可能包含请求参数、异常堆栈甚至敏感字段。真正麻烦的地方不在“有没有日志”，而在“谁能读、谁能写”。这篇文章按 Ubuntu 常见部署流程，把日志路径确认、文件权限设置和 Web 服务器配合这几步拆开说明，方便你根据自己的运行用户和安全要求选出合适方案。
先确认应用已经运行
在调整日志权限前，先确保 Node.js 应用本身已经启动。只有应用真正跑起来，日志文件才有机会被创建，你也才能确认后续要处理的是哪些文件。
如果应用还没启动，可以先运行入口文件：
node app.js这里的 app.js 只是示例，你需要替换成自己的实际入口文件名。
先找准日志文件到底写在哪里
很多项目默认会把日志放在项目目录下的 logs 文件夹，但不要只靠猜。最稳妥的做法，是直接查看项目里的日志配置，确认文件路径和日志级别。
如果项目使用的是 winston，配置通常会类似下面这样：
const logger = winston.createLogger({
level: 'info',
format: winston.format.json(),
transports: [
new winston.transports.File({ filename: 'logs/error.log', level: 'error' }),
new winston.transports.File({ filename: 'logs/combined.log' })
]
});从这段配置可以直接看出，日志文件写入的是 logs/error.log 和 logs/combined.log。如果你的项目不是这个路径，后面的权限命令也要按实际路径替换。
需要所有用户可读时，用 chmod 设置 644
如果你的目标只是让系统中的其他用户能够读取日志，但不允许他们修改内容，可以直接使用 chmod 设置文件权限。
sudo chmod 644 logs/error.log
sudo chmod 644 logs/combined.log644 的含义是：
- 文件所有者可读可写
- 所属组可读
- 其他用户可读
这种方式适合以“读取排障日志”为主的场景，但它也意味着系统内其他普通用户都能查看日志内容。如果日志里可能出现敏感信息，这通常不是最稳妥的做法。
需要更严格限制时，配合 chown 与 660
如果你希望只有应用运行用户和指定组成员可以访问日志文件，就需要同时处理“文件归属”和“权限位”两件事。
先把日志文件所有者改成 nodejs 用户和 nodejs 组：
sudo chown nodejs:nodejs logs/error.log
sudo chown nodejs:nodejs logs/combined.log然后再设置权限：
sudo chmod 660 logs/error.log
sudo chmod 660 logs/combined.log这样设置后：
- 文件所有者可读可写
- 所属组成员可读可写
- 其他用户完全无权访问
对于生产环境来说，这通常比 644 更合适，尤其是在日志可能记录错误堆栈、请求内容或内部路径信息时。
部署在 Nginx 或 Apache 后，还要核对进程用户
如果你的 Node.js 应用是配合 Nginx 或 Apache 部署的，单纯改日志文件权限还不够。你还需要确认 Web 服务器、反向代理或守护进程实际使用的是哪个系统用户运行。
这里最容易出现的问题有两个：
- 服务器配置里的日志路径和应用实际写入路径不一致
- 服务进程运行用户与日志文件所有者或所属组不匹配
一旦这两处对不上，就可能出现“应用正常运行但日志写不进去”或者“排障时发现文件无法读取”的情况。尤其是在改过部署方式、迁移过目录，或日志文件被轮转重新创建之后，这类问题更常见。
最后别忘了做持续检查
日志权限不是一次性配置。应用更新、日志轮转、部署脚本变更，甚至手动清理日志后重新生成文件，都可能让原有权限失效。
比较实用的做法是：
- 每次上线后检查一次日志文件归属和权限
- 确认新建日志文件仍然落在预期目录
- 在发现写入失败或读取异常时，优先排查运行用户和权限设置
只要把路径、归属和权限三件事对齐，Ubuntu 上的 Node.js 日志访问控制通常就不会再成为隐患。
