部署机上 crontab 每天报 /opt/app/run.sh: Permission denied，手动 bash run.sh 能跑，ls 看权限是 -rw-r--r--。乍看像缓存或者权限的锅，追下去往往不是。
chmod +x run.sh git update-index --chmod=+x run.sh git commit -m 'make run.sh executable'
追下去是这么回事：文件在仓库里没有记录可执行位，clone 出来就是 644。手动用 bash 调用绕过了执行权限，定时任务走的是直接执行。
「脚本执行权限丢失」相关的验证我通常做两遍，改完一次、隔天再看一次，确认不是临时生效。验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。
能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。报错里带路径的，先去看那个路径在不在、权限对不对。
同一份配置存在多处的，先确认改的是被加载的那一份。新版本先放一台机器上跑一天再全量，问题一般在这段时间暴露。
备份不是备了就行，恢复一次才算数，很多备份文件打开才发现是空的。
具体做法是，用 chmod +x 后 git update-index --chmod=+x 记录到仓库；部署脚本里显式 chmod 一次；cron 里用 bash /path/run.sh 兜底；重新 clone 一份 确认权限是 755。
验收就看一点，新克隆的仓库里 run.sh 权限是 755，cron 执行不再报 Permission denied。