NGINX + Gunicorn + Flask - 502 Bad Gateway - Permission Denied on Socket File
Asked Answered
B

4

0

We are trying to set up NGINX as a reverse proxy to our Gunicorn Python application. We have been following this Guide from Digital Ocean (https://www.digitalocean.com/community/tutorials/how-to-serve-flask-applications-with-gunicorn-and-nginx-on-ubuntu-16-04#create-a-systemd-unit-file). Both Gunicorn and NGINX are running on the same Ubuntu 16.04 32-bit virtual machine.

All of the posts we've seen online dealing with this type of permissions issue seem to point to the wrong "Group" setting in the service file, or to wrong permissions on the socket file. But as you can see below, we have the group set to "www-data". The socket file appears to have the necessary permissions and www-data is the owner.

What we currently have set (I've replaced our app name with "app"):

run.py

from flask import current_app
import os
from os import path
from application import app
from instance.config import Config

if __name__ == '__main__':
    conf = Config()    
    app.run(host='0.0.0.0', debug=False, threaded=True)

/etc/systemd/system/app.service

[Unit]
Description=Application
After=network.target

[Service]
User=<root>
Group=www-data
WorkingDirectory=/home/<root>/app
Environment="PATH=/home/<root>/venv/bin"
ExecStart=/home/<root>/venv/bin/gunicorn --workers 3 --bind unix:app.sock -m 007 run:app

[Install]
WantedBy=multi-user.target

/etc/nginx/sites-available/app

server {
        listen 80;
        server_name app.com;

        location / {
                include proxy_params;
                proxy_pass http://unix:/home/<root>/app/app.sock;
        }
}

/var/log/nginx/error.log

2020/06/05 16:49:22 [crit] 2176#2176: *1 connect() to unix:/home/<root>/app/app.sock failed (13: Permission denied) while connecting to upstream, client: 10.0.2.2, server: app.com, request: "GET / HTTP/1.1", upstream: "http://unix:/home/<root>/app/app.sock:/", host: "app.com"

Here are the permissions on the socket file:

gsi@ubuntu:~/app$ ls -l app.sock
srwxrwx--- 1 <root> www-data 0 Jun  5 16:10 app.sock

We're new to NGINX so we're not quite sure what the issue is or how to troubleshoot this. Can anyone see where we're going wrong here? Please let us know if there's additional info we can provide.

Bernina answered 5/6, 2020 at 23:40 Comment(5)
Is Nginx in the www-data group?Warmblooded
@Warmblooded When I check who is a member of the www-data group with getent group www-data I get the following output: www-data:x:33:. Is this what you are referring to? Thanks for the comment!Bernina
I mean if the nginx user is in the www-data group. Well, it looks like there is no user in the group.Warmblooded
It doesn't look like nginx is a user on the system at all.Bernina
It might be different based on your Nginx's configuration. If you use ps -ef|grep nginx, you will see there are master process and worker process. The point is to let the worker process be able to access the socket file. On my server, the worker processes belong to nginx user, it may be different on your server, but the point is the same.Warmblooded
B
1

We were able to resolve this by giving the www-data group access to the full application folder: sudo chgrp www-data ~/app. It already had access to the socket file specifically, but not the application folder.

I didn't think this was necessary since we specified the root user as the owner of the service. The root user already had access to the app folder and the instructions we were following didn't have steps for setting up the group access.

I don't have a lot of experience with Linux permissions/ownership though so this might be obvious to most experienced users.

Bernina answered 8/6, 2020 at 23:11 Comment(0)
D
4

I just ran into this problem. I was able to create the gunicorn socket file, but nginx complained about permission denied. The issue was that my socket file was in a sub-folder and the root folder did not have read or execute permissions. So even though the sub-folder had the correct permissions, the root folder prevented nginx from entering the sub-folder.

The solution was to add read and execute permissions to the root folder:

chmod o+rx /example_root_folder
Dunnite answered 20/5, 2021 at 17:57 Comment(2)
Thank you for your answer! This just solved a big problem for me :)Teetotal
I am not sure what should be example_root_folder here. Is it your flask application folder ? I tried that but it didn't help.Cryolite
B
1

We were able to resolve this by giving the www-data group access to the full application folder: sudo chgrp www-data ~/app. It already had access to the socket file specifically, but not the application folder.

I didn't think this was necessary since we specified the root user as the owner of the service. The root user already had access to the app folder and the instructions we were following didn't have steps for setting up the group access.

I don't have a lot of experience with Linux permissions/ownership though so this might be obvious to most experienced users.

Bernina answered 8/6, 2020 at 23:11 Comment(0)
C
1

According to the EDIT of this solution, an easy solution (that worked for me) is to change the default permissions on the user's home directory.

At least apparently many distribution have a permission 755 for user's home directory by default, so switching from 750 to 751 seems fine, security-wise, and makes accessing the app folder more convenient.

Therefore check the permissions on your home folder, then (at least for Ubuntu 22.04 distribution) :

cd /home
sudo chmod 751 ubuntu

With ubuntu being the default user on a fresh install.

Cryolite answered 5/5, 2023 at 9:0 Comment(1)
It worked for me on production serverLeges
I
0

Instead of entering app.com in the server name, try entering the IP address of the host machine and see if that works on the machine itself by running:

$curl <IP address of the host machine>

If still it doesn't work, I have written an article on the same, try to implement it using that and let me know if it works!

Hope it helps! :)

Installment answered 6/6, 2020 at 1:5 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.