I have a python project that I am trying to serve with uWSGI and Nginx. I'm trying to connect the two with a Unix IPC socket (debian stretch), but the socket refuses connections whenever Nginx tries to connect to it. It's not an issue of proper permissions or Nginx being pointed to the wrong location; I've already checked for that. What I believe may be the problem is that Nginx/the system does not see it as the proper socket file type to connect to. I considered this as a possibility when I did ls -l on the directory containing it, and it showed "-rw-rw-r--". With all the sockets I've seen, they have some variation of that with a "s" where the first hyphen is. How can I fix this issue?
Asked
Active
Viewed 572 times
1
-
1Typically, the directory containing the socket needs to have the execute permission for the user needing to access it, as well as any parent directories. For example, if the socket file is `/run/uwsgi/django.sock`, owned by "uwsgi:uwsgi", and the user accessing the socket was "nginx", then you'd want to ensure `/run/uwsgi/` has others execute permissions, via `chmod -c o+x /run/uwsgi/`. Would you be able share the permissions of the directory itself? – Alan Ivey May 23 '19 at 16:38
-
Are you saying the containing directory doesn't have `x` permissions? Or that the path that is supposed to be the socket doesn't have an `s`? Or is it both? Your description is not clear, and you didn't actually include any `ls -l` output, which would be helpful. – Michael Hampton May 23 '19 at 17:24
-
As a response to @Alan Ivey- Yes. The permission for the directory is located is "drwxr-xr-x" with root as the owner. – uwsgiisues May 23 '19 at 17:25
-
Can you append relevant lines from the Nginx error log to your original question? – Alan Ivey May 24 '19 at 17:12
-
@alan-ivey I came here looking for the solution to my problem - in my case I had a socket in /tmp which was not anyone executable drwxrw-rwt, so my socket had srw-rw-rw permissions and could not be read until I put it in (e.g.) /var/run/appdir/app.sock Also worth checking the user, group, and process user and group of nginx and uwsgi, and also checking if you have any selinux permission issues... – smaudet Dec 09 '20 at 22:28