nginx逆プロキシjava再帰作成ファイルおよびフォルダによる作成ファイルがnginxユーザーにアクセスできないという問題

javaアップロードファイルアクセス権Fileクラス部分コード

を設定できます.

File uploadPath = new File(imgPath+path);
if(!uploadPath.exists()) {    
        uploadPath.mkdirs();
}
//Process process = Runtime.getRuntime().exec("chmod 777 -R " + uploadPath);
log.info( process.toString());
String uploadFileName = path+"/"+ getUUID()+"."+imgend;
File uploadFile = new File(imgPath+uploadFileName);
uploadFile.setExecutable(true,false);//         
uploadFile.setReadable(true,false);//        
uploadFile.setWritable(true,false);//      

ここでjavaはshellスクリプト方式を実行します

Process process = Runtime.getRuntime().exec("chmod 777 -R " + uploadPath);

なぜ有効になっていないのか分かりませんが、現在のファイルには機能しますが、再帰的に作成されたフォルダには機能しません.

uploadFile.setExecutable(true,false);//         
uploadFile.setReadable(true,false);//        
uploadFile.setWritable(true,false);//      

後でtomcatがrootユーザーで起動していることを発見し、nginxもrootユーザーが起動したビューフォルダでrootユーザーにもすべての権限があることを発見した後、nginxの構成問題であることを発見したnginxのworker processユーザーはrootではない
Nginxユーザー権限
nginx.confファイルの最初の行は一般的にユーザーを設定する場所(nginxをコンパイルインストールする際のパラメータ--user=もユーザーを指定する場所)であり、user www www wwwなどである.
デフォルトがnobodyであることを指定しないと、ここでユーザーの設定は何の意味がありますか?主にnginxを実行するworker processを指定するユーザーで、linuxの中のすべてのプログラムはすべてファイルで、すべて権限の問題を持っていて、この指定したユーザーは特定のファイルに対してアクセスして実行する権限があるかどうか、このユーザーの意味です.
まず、Nginxのユーザー管理について説明します:(1)NginxはLinuxサービススクリプトで起動するとstart-stop-domainで起動し、root権限でdaemonプロセスを実行します.(2)その後daemonプロセスは/etc/nginx/nginx.confファイルのuser構成オプションを読み込み、デフォルトではここのuser=nginx、すなわちnginxユーザーでworker processを起動する.403エラーは、nginxユーザーが現在開発中のユーザーディレクトリ、/home/dean/work/resourcesにアクセスする権限がないためです.解決策はuser=nginxをrootに置き換え、nginxを再起動することです.他の方法でも、nginxユーザーをrootグループに追加するなど、/home/dean/work/resourcesディレクトリに777権限を設定してみました.だから開発するときはuser=rootで構成しましょう.製品環境では、resoucesディレクトリはnginxユーザーディレクトリの下に完全に配置できるので、問題はありません.
例2:アクセス速度が遅いnobodyユーザによるnobodyはシステムユーザであり、ログインできないアカウント、特殊な用途のユーザID、apache、aquidなどのサービスプロセスは、nobody、news、gamesなどの特殊なアカウントを使用して実行される.一般的にuid<500はシステムIDです.Linuxシステムは安全のため、多くの操作とサービスの運行はrootユーザーの下で運行するのではなく、専用のIDで、このIDは一般的にnobodyで、このように各サービスの運行状況を隔離することができます.サーバプログラムの問題でサーバプログラムがハッカーの直接操作源にならないことを保証します(ハッカーはサーバプログラムを取って、rootユーザーではなくnobodyユーザーだけです).他のユーザーのデータにも影響しません.サーバ・プログラムの権利は、悪意のある使用を防ぐための専用の方法があります.nobodyのほかに、よくあるのはftp、sshなどです.サービスを走るのではなく、ピットを取るために使われるものもあり、主にユーザーグループの権限管理で権限設定を行い、このときピット用の同名IDがユーザーグループに加わる.この状況は主に互換性のためらしい.問題の説明:
午前中、業務関係者は、システムの応答が遅く、インタフェースがリフレッシュされてから出られたと明らかにした.バックグラウンドを調べても間違いはありません.私たちのシステムはnginxで負荷均衡をしています.慣性的に負荷等化を行わずに単一ノード応用に直接アクセスし,応答が速く,正常であることが分かった.初歩的な位置決めの問題はnginxに出て、それからnginxログを調べて、多くの間違いがあることを発見して、間違いの中に“13:Permission denied”という情報があって、明らかに権限の問題で、とてもおかしくて、前に運行してすべて正常です.後で聞いてみると、メンテナンススタッフが操作していたことがわかりました.
システム上でnginxをインストールする際に使用するのはrootユーザであり、rootユーザによって起動されるので、構成を変更するにはrootユーザを使用する必要があり、管理上不便であるため、メンテナンス担当者は心血を注いでnginxの権限を変更した(後にこのコマンドを使用して変更した権限chown-R user:group$nginxdirであることが分かった).nginxのユーザーとグループを交換しましたが、なぜ「応答が遅い」のでしょうか.
問題の原因と解決:
前述したlinuxでは、セキュリティを保証するためにnobodyというユーザーをデフォルトで使用して起動するアプリケーションもあります.nginxには2つのプロセスがあり、メインプロセス以外のワークプロセスはnobodyというユーザーによって開始されます(nginxワークプロセスの数はworker_processesというパラメータを使用して設定されます).ワークプロセスはnginxの下の2つのディレクトリclient_にアクセスします.body_tempとproxy_temp(この2つのディレクトリは私の理解では、画像やcssファイルなどの静的ファイルをキャッシュしてnginxアクセス速度を向上させることです)、権限が変更された後、ワークプロセスがこの2つのディレクトリの下の内容にアクセスできなくなり、応答が遅いようにいくつかの画像と接続が開かないことがあります.権限を変更すればOKです.