Nginx (13: Permission denied) while connecting to upstream

Question

I'm deploying my Djano application on a VPS and I'm following the steps in the below link to configure my app with Gunicorn and Nginx.

How To Set Up Django with Postgres, Nginx, and Gunicorn on Ubuntu 16.04

Everything went well with the tutorial (gunicorn and nginx are running) but the issue is that when Im' visiting the VPS through the static IP its showing a white screen that is always reloading.

After checking nginx log I found the following:

(13: Permission denied) while connecting to upstream, client: <client_ip>, server: <server_ip>, request: "GET / HTTP/1.1, upstream: "http://unix:/root/myproject/myproject.sock:/", host: "<server_ip>", referrer: "http://<server_ip>/"

Roundel

Answer 1

After searching for roughly 7 hours, I was finally able to find a solution to this issue in the Nginx forum:

Nginx connet to .sock failed (13:Permission denied) - 502 bad gateway

What I simply did was changing the name of the user on the first line in /etc/nginx/nginx.conf file.

In my case the default user was www-data and I changed it to my root machine username.

Roundel

You should never run your web server process as root – Gretta

Why shouldn't I do so? @Sævar – Roundel

If your web application is compromised the attacker will have gained privileged root access to your server, instead of just a non-privileged user. – Gretta

Thank you. Will work on fixing that. @Sævar – Roundel

it worked for me!thanks but instead of root i used my own customized user. – Trifoliate

It works for me. But by default the user defined in nginx.conf was "nginx" and I changed it to my own username . Thank you very much. – Facesaving

Answer 2

I faced similar problem. The problem turned out to be trivial, it was necessary to change the rights of the directory to 755

chmod 755 /path/to/Project

Kimi

Answer 3

If you're using Ubuntu 22 (not sure about others) and you deploy your application to any path, that's under /home/{{ username }}, check the permissions of /home/{{ username }}

It's likely that your username dir has the following permissions:

drwxr-x---

while you need to have

drwxr-xr-x

this change will allow Nginx user to read and navigate inside your user folder.

Restorative

Answer 4

In the top of nginx.conf file is a user name (user nginx;). just add this user in same group that your site or project is. www-data or any is yours. sorry for english.

Exotic

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Intubate

Answer 5

i just created new user in my system and give the project ownership to that user and then in my /etc/nginx/nginx.conf i marked user as user that i created

Bustard

Answer 6

Posting a completely different solution in case someone has a different problem with the same symptoms. In my case, I was running on RHEL with Security-enhanced Linux enabled.

SELinux can block Nginx from accessing the socket, even if filesystem permissions look correct. To check if SELinux is the culprit, temporarily put it in permissive mode with: sudo set enforce 0

Does it work? If so, you may want to make an exception to the rule.

Remember to revert! sudo setenforce 1

Red Hat has a tutorial for Creating an SELinux Policy (RHEL docs)

This is a bit of a shortcut—if you've tried to start Nginx and it was denied access to the Gunicorn socket, then the denial would be logged in the audit logs. You can use these logs to generate a custom SELinux policy module:

sudo grep gunicorn /var/log/audit/audit.log | sudo audit2allow -M nginx_gunicorn

Looking at the context of the socket, ls -lZ /run/gunicorn.sock I'm seeing:

system_u:object_r:var_run_t:s0

And for nginx, ps -eZ | grep nginx:

system_u:system_r:httpd_t:s0

Noting var_run_t and httpd_t in the contexts.

cat nginx_gunicorn.te Shows the policy, and it should probably have something about allowing the two contexts to interact.

allow httpd_t var_run_t:sock_file write;

While saying a little prayer to the SELinux guardians, you may try enabling the policy.

sudo semodule -i nginx_gunicorn.pp
sudo systemctl restart nginx

**If this doesn't work, you might try a variation of the Holy Grep Incantation on audit log searching for nginx. First, disable the policy you added, then create and enable again.

sudo semodule -r nginx_gunicorn
sudo grep nginx /var/log/audit/audit.log | sudo audit2allow -M nginx_gunicorn
sudo semodule -i nginx_gunicorn.pp

Godspeed.

Clutch