phpWebアプリケーションによって生成されたユーザーファイルを一時的に保存するために使用されるwebrootの上にフォルダーがあります。たとえば、ファイルは電子メールに添付されるPDFの場合があります。
フォルダのアクセス許可はrwxr-xr-x（0755）に設定されています。Webアプリケーションからプロシージャを実行すると、ファイルは問題なくこのフォルダに書き込まれます。
上記とまったく同じ手順を実行するためにphpスクリプトを呼び出すcronジョブも設定しました。ただし、アクセス許可が失敗したため、PDFを上記のフォルダーに保存できません。cronジョブはpermission deniedエラーを報告します。
フォルダのアクセス許可を0775に設定しようとしましたが、アクセス許可が拒否されました。ただし、アクセス許可が0777の場合、cronジョブは正常に機能します。
これは私には非常に奇妙に思えます-なぜcronは0755で許可が拒否されるのに、Webアプリでは正常に機能するのですか？
考えられる答えは、cronジョブがユーザーの下で実行され、ディレクトリがapache（または、www-dataまたはnobody、またはWebサーバーが実行されているユーザー）によって所有されていることです。
これを機能させるには、Webサーバーユーザーとして実行するようにcronジョブを設定できます。このようなもの：
su -l www-data -c 'crontab -e'
または、アクセス許可を775（所有者とグループの場合はread-write-execute、その他の場合はread-write-execute）に変更し、フォルダーのグループ所有権をcronジョブを実行しているユーザーに設定することもできます。
ただし、何かを削除したり、apacheによって作成されたフォルダーに移動したりする場合でも、問題が発生する可能性があることを確認する必要があります（apacheはそれ自体が所有するファイルを作成し、ユーザーはそれを削除できません。ディレクトリ権限の。
また、システムアーキテクチャに応じて、suphpなどの最新のものを確認することもできます。Webサーバープロセスはユーザー名で実行されます。
user-group-everybodyに権限が与えられます。それが3文字の意味です。
phpスクリプトはcronジョブとは異なるユーザーとグループとして実行されるため、異なる権限を監視します。
チェックchownしてchgrp、または同じユーザーでcronジョブを実行してみてください。
cronjobを定義したユーザーによって異なります。
ルート（非推奨）の場合は機能するはずです。あなたがウェブユーザー（例えば、ubuntuのwww-data）なら、それもうまくいくはずです。
sudo su - www-data
crontab -e
cpanelを使用してphpを実行している場合は、次のように試すことができます： "php /home/algo/public_html/testcron.php" ...次のように記述します：php（スクリプトのルート）/yourscritpt.php "