Permission denied - nginx and uwsgi socket
Asked Answered
D

11

62

Well I am currently trying to get my django application served using nginx and uwsgi. I am currently using a virtual environment to which uwsgi is installed. However I am currently getting a 502 bad gateway error when attempting to access the page.

The Error I am experiencing.

2014/02/27 14:20:48 [crit] 29947#0: *20 connect() to unix:///tmp/uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: 144.136.65.176, server: domainname.com.au, request: "GET /favicon.ico HTTP/1.1", upstream: "uwsgi://unix:///tmp/uwsgi.sock:", host: "www.domainname.com.au"

This is my nginx.conf

    # mysite_nginx.conf

# the upstream component nginx needs to connect to
upstream django {
    server unix:///tmp/uwsgi.sock; # for a file socket
    #server 127.0.0.1:8001; # for a web port socket (we'll use this first)
}

# configuration of the server
server {
    # the port your site will be served on
    listen      80;
    # the domain name it will serve for
    server_name .domainname.com.au; # substitute your machine's IP address or FQDN
    charset     utf-8;

    # max upload size
    client_max_body_size 75M;   # adjust to taste

    # Django media
    location /media  {
        alias /home/deepc/media;  # your Django project's media files - amend as required
    }

    location /static {
        alias /home/deepc/static; # your Django project's static files - amend as required
    }

    # Finally, send all non-media requests to the Django server.
    location / {
        uwsgi_pass  django;
        include     /home/deepc/.virtualenvs/dcwebproj/dcweb/uwsgi_params; # the uwsgi_params file you installed
    }
}

Here is my uwsgi.ini file

[uwsgi]
socket=/tmp/uwsgi.sock
chmod-socket=644
uid = www-data
gid = www-data

chdir=/home/deepc/.virtualenvs/dcwebproj/dcweb
module=dcweb.wsgi:application
pidfile=/home/deepc/.virtualenvs/dcwebproj/dcweb.pid
vacuum=true

From what i have read on google its a permissions problem with the www-data group and /tmp/ directory. However I am new to this and have tried to changer the permission level of the folder to no avail. Could someone point me in the right direction? Is this a permissions problem.

Also is it ok practice to put the sock file in tmp directory?

Thanks

Digital answered 27/2, 2014 at 14:38 Comment(2)
Try to change chmod-socket=644 to 666? I'm not sureJuetta
the reason is nginx can not access the sock file. Make sure the user group started uwsgi is same as nginx group(default www-data) so that nginx can access the sock file, then everything will be ok. usermod -g www-data username. hope helpsBotticelli
G
66

I think you just need to change your socket file to 666(664 is ok with www-data), or remove it and run uwsgi server again.

In my uwsgi.ini:

chmod-socket = 664
uid = www-data
gid = www-data
Gradatim answered 12/8, 2014 at 8:24 Comment(7)
I have set this, and also tried to use the flags on the binary (--uid www-data --gid www-data) but it seems to ignore them. Any idea why?Lavernelaverock
@Chockomonkey, did you run your uwsgi (with --uid www-data --gid www-data) in command line? It will start process with your current user only. In my project, I just followed uwsgi-docs.readthedocs.org/en/latest/Upstart.html, the init script will run my uwsgi as a server, the user on the process/socket/pid will be www-data. Please let me know if something not clear, thx.Gradatim
Thanks for the clarification. You are right, when I run it via the command line is when it ignores the --uid and --gid flags. So at least that part makes sense now, yay! However I'm still having problems getting the Emperor to run correctly with Upstart. See #29243945Lavernelaverock
you sir, are a gentleman, and a scholar. I had to add the uid/gid flags inti my uwsgi.ini file.Moral
What a legend, thank you! What's the best way to debug such issues? It's not like nginx has complained in its logs about the lack of permissions..Bassoon
@Tony, hmm, just make the linux permission (user, group) clear enough, no better way :(Gradatim
command line --uid and --gid works for me when running the command with sudo. I guess the normal user simply doesn't have permissions to give another process the www-data uid.Overexpose
C
40

Wow, this problem takes me almost a whole day!

I use uwsgi 2.0.14, nginx 1.10.1, django 1.10

To sum up, the most important thing is to make sure both of below two users have rwx permission to socket file:

  1. the user of nginx;
  2. the user of uWSGI;

So, you can check them one by one.


First you can check if the web server nginx has permission by refreshing the url, say http://192.168.201.210:8024/morning/, without running uwsgi. If you see /var/log/nginx/error.log No such file or directory, like this:

2016/10/14 16:53:49 [crit] 17099#0: *19 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"

Just create a file named helloworld.sock, and refresh the url and check log file again, if you see Permission denied in log file, like this:

2016/10/14 17:00:45 [crit] 17099#0: *22 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"

It means web server nginx does not have all permission to read, write and execute. So you can grant permission to this file:

sudo chmod 0777 helloworld.sock

Then, refresh the url and check log file again, if you see Connection refused in log file, like this:

2016/10/14 17:09:28 [error] 17099#0: *25 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (111: Connection refused) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"

This is a good sign, it means your web server nginx has the permission to use helloworld.sock file from now on.


Next to run uwsgi and check if the user of uwsgi has permission to use helloworld.sock. Firstly, remove the file helloworld.sock we have created before.

Run uwsgi: uwsgi --socket /usr/share/nginx/html/test/helloworld.sock --wsgi-file wsgi.py

If you see bind(): Permission denied [core/socket.c line 230], it means uwsgi don't have permission to bind helloworld.sock. This is the problem of the directory test, the parent directory of helloworld.sock.

sudo chmod 0777 test/

Now, you can run uwsgi successful.

But maybe you still see 502 Bad Gateway, it's terrible, I have seen it all day. If you check error.log file again, you will see this again:

2016/10/14 17:33:00 [crit] 17099#0: *28 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"

What's wrong???

Check the detail of helloworld.sock file, you can see:

srwxr-xr-x. 1 belter mslab       0 Oct 14 17:32 helloworld.sock

uWSGI gives this file 755 permission automatically.

You can change it by adding --chmod-socket:

uwsgi --socket /usr/share/nginx/html/test/helloworld.sock --wsgi-file wsgi.py --chmod-socket=777

OK! Finally, you can see:

successfully see the web info


Take away message:

  1. uwsgi_params file's location is not important;
  2. Since my nginx user and uwsgi user not same and even not at the same group, so I need to give 777 permission to helloworld.sock and its parent dir test/;
  3. If you put helloworld.sock file in your home directory, you'll always get Permission denied.
  4. There are two places you need to set the socket file path, one in nginx conf file, for me it is helloworld_nginx.conf; one when you run uwsgi.
  5. Check SELinux

This is my helloworld_nginx.conf file:

# helloworld_nginx.conf
upstream django {
    server unix:///usr/share/nginx/html/test/helloworld.sock; # for a file socket
    # server 127.0.0.1:5902; # for a web port socket (we'll use this first)
}

# configuration of the server
server {
    # the port your site will be served on
    listen      8024;
    # the domain name it will serve for
    server_name .belter-tuesday.com; # substitute your machine's IP address or FQDN
    charset     utf-8;

    # max upload size
    client_max_body_size 75M;   # adjust to taste

    # Finally, send all non-media requests to the Django server.
    location /morning {
        include     uwsgi_params;
        uwsgi_pass  django;
    }
}
Corrective answered 14/10, 2016 at 10:42 Comment(4)
While I think 0777 is too permissive, and you should find a better way to give the correct users permission instead of opening it to all users, your explanation was very good and helped me track down the issue.Valdez
When i run uwsgi --socket /tmp/mysite.sock --wsgi-file wsgi.py it displays !!! no internal routing support, rebuild with pcre support !!! *** WARNING: you are running uWSGI without its master process manager *** lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with --thunder-lock) error removing unix socket, unlink(): Operation not permitted [core/socket.c line 198] bind(): Address already in use [core/socket.c line 230]Decussate
You can change a dir instead of /tmp for your socket file, try again.Corrective
My sock file has content helloworld.sock: No such device or address and my web page is unresponsiveSpacial
W
12

On CentOS, I tried all those things but still it did not work. Finally, I found this article:

https://www.nginx.com/blog/nginx-se-linux-changes-upgrading-rhel-6-6/

For a development machine, we simply run:

semanage permissive -a httpd_t

But for a real production server, I have not figured out. You may need to try other things described in the above article.

Whiffler answered 5/10, 2015 at 1:51 Comment(2)
this command solved my problem that I`ve spent my whole week for, thanks!Knowall
Thanks for this, solved my problem on CentOS 7. I had to install semanage with yum install policycoreutils-python.Contention
P
8

This is take me a lot of time to find the problem with permissions. And the problem is with permissions of course. Default user is nginx. What i did: in /etc/nginx/nginx.conf change user:

user  www-data;

Next join your user to www-data goup:

usermod -a -G www-data yourusername

Next set uwsgi:

[uwsgi]
uid = yourusername
gid = www-data
chmod-socket = 660

And then restart nginx:

sudo systemctl restart nginx

And finaly restart uwsgi.

Primulaceous answered 19/3, 2018 at 23:47 Comment(0)
G
3

I grappled with this problem for a while, and found that the uid and gid flags from my uwsgi.ini file were not being applied to the .sock file

You can test this by running uwsgi, then checking the permissions on your .sock file using the linux command ls -l.

The solution for me was to run uwsgi with sudo:

sudo uwsgi --ini mysite_uwsgi.ini

with the .ini file containing the flags:

chmod-socket = 664
uid = www-data
gid = www-data

Then the permissions on the .sock file were correct, and the 502 Bad Gateway error finally vanished!

Hope this helps :)

Gnarly answered 25/7, 2017 at 13:13 Comment(0)
M
2

This issue made me crazy. My environment is centos7+nginx+uwsgi, using unix socket connection. The accepted answer is awesome, just add some points in there.

ROOT USER, QUICK TEST

First, turn off selinux, then change chmod-socket to 666, and finally start uwsgi using root.

Like this

setenforce 0 #turn off selinux
chmod-socket = 666
uwsgi --ini uwsgi.ini

OTHER USER

If you use the other user you created to start uwsgi, make sure that the permissions of the user folder under the home folder are 755, and that the owner and the group are corresponding.

For example

chmod-socket = 666
usermod -a -G nginx webuser #add webuser to nginx's group
cd /home/
chmod -R 755 webuser
chown -R webuser:webuser webuser
uwsgi --ini uwsgi.ini --gid webuser --uid webuser
Mackoff answered 28/7, 2017 at 17:54 Comment(0)
A
1

Another great article for CentOS users:

https://axilleas.me/en/blog/2013/selinux-policy-for-nginx-and-gitlab-unix-socket-in-fedora-19/

Although answers are useful regarding CentOS the problem lies beneath SELinux.

I followed the entire article but what solved the issue I believed where the following commands:

yum install -y policycoreutils-{python,devel}
grep nginx /var/log/audit/audit.log | audit2allow -M nginx
semodule -i nginx.pp
usermod -a -G user nginx
chmod g+rx /home/user/

Please substitute user with your actual user for granting permissions. Same applies for the directory under chmod command.

Astra answered 9/8, 2018 at 4:36 Comment(0)
A
0

uwsgi.ini

[uwsgi]
uid = yourusername
gid = www-data
chmod-socket = 664

Why? Because sometimes the app needs to read or write to the file system beyond what's accessible to the web server. I don't want to change a whole bunch of ownership and permissions just to accommodate each such situation. I'd rather have my application run as me and do what it needs to do. Setting the group as www-data and chmoding the socket to 664 allows for that group to write to it, thus providing the only necessary window of communication between the web server and the app.

Armory answered 5/6, 2017 at 11:25 Comment(0)
R
0

In dev mode, if using root, simply set wsgi.ini or emperor.ini as below:

uid=root
gid=root
Removal answered 5/1, 2021 at 3:34 Comment(0)
S
0

Just add User name to the nginx config file and it will work Add /etc/nginx/nginx.conf

user user_name www-data;

Stairwell answered 20/4, 2023 at 2:4 Comment(0)
G
-4

you need to uncomment

#server 127.0.0.1:8001;

from upstream block and similarly do the changes in uwsgi.ini as

socket = 127.0.0.1:8001
Goltz answered 17/3, 2015 at 12:34 Comment(1)
This will use internet socket type. OP is trying to set it up with unix socket.Sorbose

© 2022 - 2024 — McMap. All rights reserved.