我在webroot上方有一个文件夹，用于临时存储php Web应用程序生成的用户文件。例如，这些文件可能是将附加到电子邮件中的PDF。
文件夹权限设置为 rwxr-xr-x （0755）。从 Web 应用程序执行过程时，文件将写入此文件夹，没有任何问题。
我现在还设置了一个 cron 作业，该作业调用 php 脚本来执行与上述完全相同的过程。但是，由于权限失败，PDF 无法保存到上述文件夹中 - cron 作业报告permission denied错误。
我尝试将文件夹权限设置为 0775，但仍然被拒绝权限。但是，当权限为 0777 时，cron 作业就可以正常工作。
这对我来说似乎很奇怪 - 为什么 cron 在 0755 处被拒绝权限，但它通过 Web 应用程序工作正常？
可能的答案是 cron 作业在您的用户下执行 - 并且目录由 apache（或 www-data 或您的 Web 服务器运行的任何人或任何用户）拥有。
要使其正常工作，您可以将 cron 作业设置为以 Web 服务器用户身份运行。像这样：
su -l www-data -c 'crontab -e'
或者，您可以将权限更改为 775（所有者和组的读-写-执行，其他人的读取-执行），并将文件夹的组所有权设置为运行 cron 作业的用户。
但是，您必须确保如果您要删除某些内容或下降到由 apache 创建的文件夹中，您仍然可能会遇到问题（apache 会创建一个它自己拥有的文件，并且您的用户无法删除它，无论目录权限如何。
您还可以查看一些诸如suphp或任何最新内容之类的内容 - Web服务器进程以您的用户名运行，具体取决于您的系统架构。
这取决于您定义了 cronjob 的用户。
如果你是根（不推荐），它应该可以工作。如果你是网络用户（例如 ubuntu 上的 www-data），它也应该可以工作。
sudo su - www-data
crontab -e
权限授予用户组所有人。这就是 3 个字符的含义。
您的 php 脚本以与 cron 作业不同的用户和组运行，因此它们遵守不同的权限。
选中chown和chgrp，或尝试使用同一用户运行 cron 作业。
如果你使用cpanel来运行PHP，你可以尝试这样的事情："php/home/algo/public_html/testcron.php" ...只需写：php（脚本的Rute）/yourscritpt.php"