导出的报表在网页上点开是 403，登录服务器看文件是 -rw-------，属主 www-data。同目录下手工建的文件是 644。日志里能对上时间点，这种反而好排。
进程的 umask 是 0077，open 传的 0666 被掩成 0600，只有属主能读。systemd 启动的服务继承的 umask 和交互式 shell 不一样，在终端里试不出来。这一点先确认清楚，后面就不用反复试。
grep Umask /proc/$(pgrep -f gunicorn | head -1)/status umask 0022 install -m 0644 report.csv /data/export/report.csv
「umask 文件权限」确认了原因之后，改动尽量只碰那一处，顺手改的东西后面最容易出问题。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
别只看报错的最后一行，往上看几行，真正的起因通常在上面。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。
处理上按这个顺序：先看进程的 umask 值 /proc/<pid>/status 里的 Umask 行；在 unit 或启动脚本里显式设置 UMask=0022；创建文件时传明确的 mode 别依赖默认值；目录要 755 文件要 644 分别确认。
结果对不对很好判断，新生成的报表权限是 644 Web 端直接能下载 不再返回 403。