您也可以尝试以下解决方案：

chmod +x post.php
chmod +x bash.sh
echo "* * * * * /home/samitha/bash.sh >> /home/samitha/log/cron.log 2>&1" >> cronjob

chmod +x cronjob

/etc/init.d/crond start  #redhat based servers like centos
/etc/init.d/cron  start  #debian based servers like ubuntu

crontab cronjob

问题可能是您的用户没有执行该文件的权限。
首先，设置脚本的执行标志

chmod +x /home/samitha/bash.sh

然后您应该使用检查php文件的权限

ls -lah /var/www/Controller

如果你的用户组和用户名都没有出现，你必须用超级用户权限运行脚本或者修改它的权限。
第一种方法是把你的词条

sudo crontab -e

或者第二个是（我不推荐，因为每个人都可以通过调用你的站点来执行脚本）

chmod a+x /var/www/Controller/post.php

执行该cron的用户（执行cron -e的用户）没有执行该脚本的适当权限，即：要么脚本缺少执行标志，要么因为它的某些祖先目录缺少执行标志而无法访问它。

TL;DR：在crontab中的脚本前面以及脚本调用的任何脚本中插入“bash”。
我有一个解决这个问题的方法。之前的答案对我都不起作用。我有两台华硕笔记本电脑运行Kubuntu（更新到内核v5.8），配置几乎完全相同。我不知道为什么一台有问题，另一台没有。但是，经过2天的实验，我找到了一个解决方法。希望比我更有知识的人能找到原因。
Cron正在使用sh而不是bash。我尝试添加SHELL=/bin/bash并在crontab中的命令上方定义PATH，但没有效果。我的所有脚本在开头都有#！/bin/bash shebang，也没有效果。我的脚本（及其目录）权限是777。无论我在文件上尝试了user：group的什么组合，脚本都不会为cron或用户运行。使用完整路径名是cron，在脚本内部没有效果，这与使用环境变量不同。
我的修复方法是在crontab中的脚本文件名前插入“bash”。
00 01 * * * 攻击$BASH脚本/备份操作系统.sh
(Yes，cron在使用我在/etc/environment中定义的环境变量时没有问题。）此外，在cron中，当一个脚本运行另一个脚本时，第二个脚本将获得“permission denied”，除非修改该脚本，使其在第二个脚本的文件名前具有“bash”，或者使用“source”（如果这对您的脚本有效）。

• 文件必须是可执行文件（@see chmod）
• 所有父目录必须具有执行标志（@see chmod）
• 如果crontab由其他用户运行，即不是所有者，则可能此用户没有执行权限。（@see chown）

我遇到了与OP完全相同的错误，但在RHEL上。当然，这不是Cron问题，而是权限问题。我应该通过尝试手动运行脚本来检查这一点，但我没有，因为它在其他服务器上运行良好，文件权限也没问题。最终，在挠头了几个小时后，我认为原因是在此特定服务器上，使用noexec选项装载了具有主目录的文件系统（例如使用mount | grep home来检查/home的挂载选项）。另一个需要记住的细节。
编辑：我又读了一些，结果发现，出于“安全”原因，现在建议在FS上使用noexec和主目录（尽管这样做的意义是有争议的）。我还意识到，可能yendao42也有同样的问题，因为在bash脚本前面添加bash确实是解决这个问题的一个非常简单的方法。