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
- Django South Error: "there is no enabled application matching 'myapp'"
- Naming variable, best convention
- Why was an old .pyc file breaking Django?
- Recommended way of accessing BASE_DIR in Django
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.
- Django selenium LiveServerTestCase
- Reverse Queryset Order in Django
- Django: how to trigger creation of ContentTypes for new models?
- How to limit queryset/the records to view in Django admin site?
- Why isn't django serving my SPA static files correctly?
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
- Colorizing the output of Django tests
- Divide Django base.html template into header, content and footer.html
- Traversing multiple lists in django template in same for loop
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.