wave
Uncategorized

Fixing 403 Forbidden Nginx Errors.

Mohammed Naser

Mohammed Naser

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 utility.

$ 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: 1.1.1.1, 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

autoindex on;

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.htm and 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;

Incorrect Permissions

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: 1.1.1.1, 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, /usr/share, /usr/share/nginx and /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.

Conclusion

We’ve gone through quite a few tools such as tail and 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.

Would you like to know about Zuul, a CI/CD project gating tool? Download our white paper and get reading!

How to up your DevOps game with Project Gating

Share on Social Media:

OpenStack

Cluster API driver for OpenStack Magnum

Mohammed Naser

Public Cloud

9000 MTUs (jumbo frames) in all Public Cloud Regions

Mohammed Naser

Uncategorized

OpenInfra Summit Berlin 2022 VEXXHOST Recap

Mohammed Naser

Go to Top