Fixing 403 Forbidden Nginx Errors
Posted on Saturday, August 31, 2013
Terms of Contents
- Cloud Sites Update: New Control Panel & Faster MySQLThursday, April 9, 2015
- Introducing New Server Networking FeaturesTuesday, March 10, 2015
- Getting started with Docker in minutes using Docker MachineFriday, February 20, 2015
- MEAN & Socket.IO Integration TutorialThursday, September 11, 2014
- Getting Started with MEAN StackWednesday, August 6, 2014
- How To Install Ruby on Rails on UbuntuSunday, December 29, 2013
- How to Add Swap on UbuntuMonday, December 30, 2013
- How To Deploy Django on Nginx, Gunicorn with PostgresTuesday, April 8, 2014
- Few CSS tricks you may not knowFriday, October 27, 2006
- CentOS 6 to CentOS 7 Upgrade ProcedureWednesday, July 16, 2014
HTTP errors are pesky and typically hard to resolve without the right tools. However, with proper investigation and tools, you can easily identify the source of a problem and fix it just as fast. In order to debug or fix 403 Forbidden Nginx errors, all you have to do is check the correct error logs and take the proper action to resolve it. We’ll go over how to check the error logs and the possible scenarios that typically cause these errors.
Finding Error Logs
If you know exactly where the error logs of your Nginx server are, you can skip onto the next section. If you’re not sure where to find the error logs of your Nginx server, then be sure to continue this section.
The path for error logs can change a lot depending on how Nginx was installed on the server and the Linux distribution. If you do not know where your error logs are and you have a hard time going through Nginx configuration, we can use a very small and useful Linux tool with the name of
lsof which gives us all the open files associated to a specific process. This will help us find the error log for your web server.
The first step of this is to check for the process ID of the main Nginx process, you can run the following command and except output somewhat similar to the one indicated below:
$ ps x | grep nginx 29229 ? S 0:00 nginx: master process /usr/sbin/nginx
The first column of each row is the process ID, as we can see, the main/master process ID is
29229 in this case, however this will change in every system. Once you have the process ID, you will be able to use the
lsof too to get all open files associated to this process by running the following. We’ve trimmed the output to the part you should be looking for, as there might be a lot more data when you run that command:
$ lsof -p 29229 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME nginx 29229 root cwd DIR 202,1 4096 2 / nginx 29229 root rtd DIR 202,1 4096 2 / nginx 29229 root txt REG 202,1 843656 1182 /usr/sbin/nginx ... nginx 29229 root 2w REG 202,1 0 262748 /var/log/nginx/error.log ...
As you can see from the above output, we can see that one of the files that are open by this Nginx installation is
/var/log/nginx/error.log which (by the file name) does look like an error log. We’ve now identified the path of our Nginx error log and we can move onto finding the reason behind our pesky HTTP error.
Fixing Nginx HTTP errors
Once you have the correct error log file, it’s time to watch for errors. In our experience, the best way to do this is by running a continuous stream of the error log in your shell screen using the
$ tail -f /var/log/nginx/error.log
Once you’ve ran this command,
tail will continuously output any newly appended content to the error.log as it comes in until you hit Control + C. We recommend that you clear the entire shell screen to make it easy to identify newly appended content. You can do this in Windows (PuTTY) by right clicking the PuTTY menu bar and clicking on “Clear Scrollback” or on Mac OS X by clicking Command + K.
Now, you will need to replicate the issue that you are getting. The error should be printed out right away after you replicate the issue. For example, if you have a 403 Forbidden error, then you should refresh the page that is causing the problem so that a new error log entry can be appended. Once that is done, you’ll see a new line in the error log which should hopefully lead you to the right path to fixing the issue. We’re going to cover a few of the most common issues below.
Incorrect Directory Settings
The error below can be caused by two different reasons: incorrect directory index or disallowed directory listing.
2013/08/31 15:03:43 [error] 29231#0: *2098806 directory index of "/usr/share/nginx/static/" is forbidden, client: 220.127.116.11, server: domain.com, request: "GET / HTTP/1.1", host: "domain.com"
If you are trying to list all the files in a folder, you will get that error if the directory does not have directory listing enabled. You can enable directory listing by adding the following line to your Nginx configuration, you can read more about this option here: http://nginx.org/en/docs/http/ngx_http_autoindex_module.html
The other possibility for that error to come up is if your
index setting is incorrect, so for example, you have a index.php file in that folder, however, your
index setting is setup to
index.html. This means that only these files are checked if no specific file is provided. If you alter it to something like the following, your
index.php file should work:
index index.htm index.html index.php;
The error below is generally caused by incorrect Unix permissions, you will need to make sure you have the correct permissions for the entire path.
2013/09/01 00:31:57 [error] 29231#0: *2115270 open() "/usr/share/nginx/static/forbidden" failed (13: Permission denied), client: 18.104.22.168, server: domain.com, request: "GET /forbidden HTTP/1.1", host: "domain.com"
As you see, the file that we are trying to access is
/usr/share/nginx/static/forbidden. In order for Nginx to access it with no problems at all, Nginx must have read permissions for that specific file as well as execute for all the folders above it. This means that
/usr/share/nginx/static must be executable by Nginx and the file
/usr/share/nginx/static/forbidden must be readable by Nginx in this case.
We’ve gone through quite a few tools such as
lsof. These are just one of the tools which are offered by Linux which allow system administrators to resolve and debug issues much faster and easier. The most important factor in resolving system issues is being able to identify the issue properly, resolution is usually the easiest part once the problem is identified. The larger the toolset of the system administrator, the faster they can identify and fix those problems.