17370845950

PHP脚本权限变更会直接导致cron任务失败，因cron用户需对脚本及所有依赖路径（配置、日志、缓存等）具备读写执行权限；必须使用PHP绝对路径、显式设置环境变量与工作目录，并统一属组+setgid解决web与cron用户权限冲突。

PHP脚本权限变更会直接影响cron执行结果

修改PHP脚本文件或其所在目录的权限（如用 chmod 或 chown），可能直接导致cron任务失败——不是“可能”，而是只要权限不满足执行用户的需求，就会出错。Linux cron以指定用户身份运行，该用户必须对脚本有读取+执行权限（.php 文件本身需可读；若通过 php /path/to/script.php 方式调用，脚本无需可执行位，但PHP二进制和路径必须可达）。

• 常见错误现象：Permission denied、Command not found、脚本静默退出（无输出且返回码非0）
• 关键排查点：cron运行用户（如 www-data、root 或自定义用户）能否读取脚本？能否访问脚本中涉及的所有文件（配置、日志、缓存目录）？
• 不要只改脚本权限，还要检查其依赖路径：/var/www/myapp/config.php、/tmp/myapp/ 等——cron用户可能没有写入 /tmp 子目录的权限，即使脚本本身可读

cron中PHP执行路径与当前用户环境不一致

你在终端里能跑通 php script.php，不代表cron能跑通。cron默认不加载用户shell环境（~/.bashrc、~/.profile），PATH极简（通常是 /usr/bin:/bin），所以直接写 php 很可能找不到命令。

• 务必在crontab中使用PHP绝对路径：/usr/bin/php 或 /opt/plesk/php/8.1/bin/php（用 which php 查准）
• 避免依赖当前工作目录：cron执行时PWD通常是用户家目录，不是脚本所在目录。脚本内用 __DIR__ 或 dirname(__FILE__) 定位资源，别用相对路径如 ./config.php
• 测试方法：手动切换到cron用户执行一次完整命令：sudo -u www-data /usr/bin/php /var/www/myapp/cron.php，比看日志更快定位权限/路径问题

web用户与cron用户文件权限冲突最常发生在日志和缓存目录

很多PHP定时任务会写日志、生成缓存、上传临时文件。如果脚本由web服务器（如nginx + php-fpm）和cron共用，而两者运行用户不同（比如web用 www-data，cron用 root），就极易因目录所有权或umask差异导致后续失败。

• 典型表现：第一次cron成功，第二次报 failed to open stream: Permission denied —— 因为web用户创建了缓存文件，cron用户没权限覆盖或追加
• 解决方案不是一律 chmod 777，而是统一属组并设置setgid：chgrp www-data /var/www/myapp/runtime + chmod g+rwxs /var/www/myapp/runtime
• 确认cron用户的umask（默认可能是0022，导致新建文件只有644）。可在crontab开头加：SHELL=/bin/bash + UMASK=0002，或在脚本开头用 umask(0002)

systemd timer替代传统cron时权限模型更严格

如果你用的是systemd timer（比如 mytask.timer + mytask.service），权限控制粒度更高：它强制指定 User= 和 Group=，且默认不继承任何环境变量

，连 $HOME 都可能为空。

• 必须显式声明 Environment=PATH=/usr/local/bin:/usr/bin:/bin，否则连 php 都找不到
• WorkingDirectory= 必须设，否则脚本内 require 'config.php' 会因路径错乱失败
• systemd日志用 journalctl -u mytask.service 查，比 /var/log/syslog 更精准；错误常是 Failed at step USER spawning（用户不存在）或 Permission denied（目标目录不属于该用户）

实际调试时，最容易被忽略的是：cron用户对PHP脚本里 exec()、shell_exec() 调用的外部命令（如 curl、mysqldump）是否也有执行权限，以及这些命令所操作的文件路径是否同样开放给了该用户。