Nginx should be configured for permission denied and file not found _nginx

13:permission denied
the previous period of time to upgrade the WordPress programmer to 3.5.1, itself if there is no special plug-ins, in the background to update can be completed.

After the update is completed in the background to publish the article, the editor can not click the Visual label, can only display HTML tags, see the next JS console prompts REFERENCEERROR:TINYMCE is not defined 3.5.

Intuition that the upgrade where there is a problem, simple and rough reload, but still not, this time I think it may be nginx where the problem of configuration.

Looked at the log file and found the following error message:

2013/03/13 01:22:17 [Crit] 3331#0: *10 open () "/usr/local/lnmp/nginx/fastcgi_temp/3/00/0000000003" failed (13: Permission denied) while reading upstream, client:124.42.13.230, server:264.cn, request: "get/wp-admin/load-scripts.ph P?C=0&LOAD%5B%5D=JQUERY,UTILS,PLUPLOAD,PLUPLOAD-HTML5,PLUPLOAD-FLASH,PLUPLOAD-SILVERLIGHT,PLUPLOAD-HTML4, json2&ver=3.5.1 http/1.1 ", Upstream:" fastcgi://127.0.0.1:9000 ", Host:" 264.cn ", referrer:" http://www.nginx.cn/ Wp-admin/post-new.php "

It is very clear that the browser only loads part of the page because of permission denied.

The user who first confirms worker processes (worker process):

Check the user directive for profile nginx.conf

User Www-data;

The latter executes the command

#ps aux | grep "Nginx:worker Process" | awk ' {print '} '

Www-data

Can get the Nginx worker process running user

Check the owner of the Nginx proxy_temp directory,

DRWX------2 root  4096 Mar 3 03:28 proxy_temp

You can see that the owner of the proxy_temp is not www-data, and modifying the directory owner is Www-data.

Chown-r Www-data:www-data Proxy_temp

Through the above steps, WordPress can be normal display, will not appear in the background JS error.

Analysis of the reasons for the upstream problem of the failed (13:permission denied) while reading

First look at the Nginx reverse proxy parameter description

• Proxy_connect_timeout 600; #nginx跟后端服务器连接超时时间 (Agent connection timed out)
• Proxy_read_timeout 600; #连接成功后, back-end server response time (proxy receive timeout)
• Proxy_send_timeout 600; #后端服务器数据回传时间 (Agent send timeout)
• Proxy_buffer_size 32k; #设置代理服务器 (Nginx) to save the buffer size for user header information
• Proxy_buffers 4 32k; #proxy_buffers缓冲区, the average page below 32k, so set
• Proxy_busy_buffers_size 64k; #高负荷下缓冲大小 (proxy_buffers*2)
• Proxy_temp_file_write_size 64k; #设定缓存文件夹大小, greater than this value, will be passed from the upstream server

The problem is on the proxy_temp_file_write_size, when your file exceeds the size set by this parameter, Nginx writes the file to the Temp directory (the default is Nginx install the/proxy_temp directory).

If Nginx does not have permission to Prxoy_temp will not write in, the result is to show only part of the page.

I encountered this case with a tool to view, post-new.php this page big thing 94, more than 64k to conform to our analysis above.

File not found error
using PHP-FPM to parse PHP, "No input file specified", "File not found" is a common mistake for nginx novice headaches because the PHP-FPM process cannot find Script_ FileName is configured to execute the. php file, PHP-FPM returns to the Nginx default 404 error prompt.

For example, my site doucument_root without test.php, access to this file by grasping the package can see the content returned.

http/1.1 404 Not Found
Date:fri, Dec 08:15:28 GMT content-type:text/html
proxy-connection:close
   server:nginx/1.2.5
x-powered-by:php/5.4.7
via:1.1 c3300 (netcache netapp/6.0.7)
content-length:16

File not found.

Many people do not want users to see this default 404 error message directly and want to customize the 404 error.

Before giving a solution, let's analyze how to avoid this 404 error, and then do it again, and then see what happens when you do this (such as when a user enters a path where the error does not exist) to display a custom 404 error page.

One, the wrong path is sent to the PHP-FPM process
With this type of error, 10 out of nine are the backend fastcgi process received the error path (Script_filename), and the latter fastcgi received the wrong path mostly because of a configuration error.

The common nginx.conf configuration is as follows:

server {
  Listen  [::]:80;
  server_name example.com www.example.com;
  Access_log/var/www/logs/example.com.access.log; 

  Location/{
    root  /var/www/example.com;
    Index index.html index.htm index.pl;
  }

  location/images {
    autoindex on;
  }

  Location ~. php$ {
    fastcgi_pass  127.0.0.1:9000;
    Fastcgi_index index.php;
    Fastcgi_param Script_filename/var/www/example.com$fastcgi_script_name;
    Include Fastcgi_params;
  }
}

There are a lot of unreasonable places in this configuration, and one obvious problem is that the root command is placed in the location/block. If the root instruction is defined in the location block, then the root instruction can only take effect on the location in which it resides. There are no root directives in other locaiont, like location/images blocks that do not match any requests, and the root instructions need to be repeatedly configured in each request to solve the problem. So we need to put the root command in the server block so that each location inherits the $document_root of the parent server block definition, and if a location needs to define a different $document_root, You can define a root instruction separately in location.

Another problem is that the fastcgi parameter script_filename is written dead. If you modify the value of the root directive or move the file to a different directory, PHP-FPM returns the "no input file specified" error because script_filename is written in the configuration and does not change as $doucument_root changes , we can modify the Script_filename configuration as follows:

Fastcgi_param script_filename $document _root$fastcgi_script_name;

So we can't forget to configure the root command in the server block, otherwise the $document_root value is empty, only passing $fastcgi_script_name to PHP-FPM, which can cause "No input file specified" error.

Second, the requested document really does not exist
When Nginx receives a request for an absent. php file, because Nginx only checks that $uri is the end of. PHP, it does not judge whether the file exists or not,. The request nginx at the end of PHP is sent directly to PHP-FPM processing. PHP-FPM cannot find a file when it is processed and returns "no input file specified" with the "404 Not Found" header.

Solutions
We intercepted a nonexistent file in Nginx, requesting and returning a custom 404 error

Use Try_files to catch URLs that do not exist and return an error.

Location ~. php$ {
 try_files $uri =404;
 Fastcgi_pass 127.0.0.1:9000;
 Fastcgi_index index.php;
 Fastcgi_param script_filename ....
 . ...................................
 ...................................
}

The above configuration checks to see if the. php file exists, and if not, returns 404 pages.