CODEWITHSUNDEEP
pythonnginxflaskreverse-proxygunicorn
user2437443
user2437443

Reputation: 2257

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

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.

Upvotes: 0

Views: 3843

Answers (4)

laconis
laconis

Reputation: 117

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.

Upvotes: 1

Bryce
Bryce

Reputation: 123

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

Upvotes: 4

user2437443
user2437443

Reputation: 2257

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.

Upvotes: 1

Prithvi Shetty
Prithvi Shetty

Reputation: 61

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! :)

Upvotes: 0

Related Questions