[Fixed]-Nginx (13: Permission denied) while connecting to upstream

29👍

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.

1👍

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

0👍

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.

0👍

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

0👍

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.

Leave a comment