我在 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 或 nobody 或您的 Web 服务器运行的任何用户）所有。
要让它工作，您可以设置 cron 作业以作为 Web 服务器用户运行。像这样的东西：
su -l www-data -c 'crontab -e'
或者，您可以将权限更改为 775（所有者和组的读写执行，其他人的读取执行）并将文件夹的组所有权设置为运行 cron 作业的用户。
但是，您必须确保如果您要删除某些内容或下降到由 apache 创建的文件夹中，您仍然可能会遇到问题（apache 会创建一个它自己拥有的文件，并且您的用户无法删除它，不管的目录权限。
您还可以查看 suphp 之类的东西或任何最新的东西 - Web 服务器进程在您的用户名下运行，具体取决于您的系统架构。
权限授予用户组所有人。这就是3个字符的含义。
您的 php 脚本作为与 cron 作业不同的用户和组运行，因此它们观察到不同的权限。
检查chown和chgrp，或尝试使用同一用户运行 cron 作业。
这取决于您定义了 cronjob 的用户。
如果您是 root（不推荐），它应该可以工作。如果您是网络用户（例如 ubuntu 上的 www-data），它也应该可以工作。
sudo su - www-data
crontab -e
如果您使用 cpanel 运行 php，您可以尝试这样的操作：“php /home/algo/public_html/testcron.php” ...只需编写：php（脚本的规则）/yourscritpt.php”