权限被拒绝 - nginx和uwsgi套接字

Question

我正在尝试使用nginx和uwsgi来提供我的django应用程序。我目前正在使用安装了uwsgi的虚拟环境。但是，我在尝试访问页面时遇到502错误的网关错误。

我遇到的错误。

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"

这是我的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
    }
}

这是我的uwsgi.ini文件

[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

从我在谷歌上看到的它与www-data组和/ tmp /目录的权限问题。但是我是新手，并试图改变文件夹的权限级别无济于事。有人能指出我正确的方向吗？这是权限问题。

也可以将sock文件放在tmp目录中吗？

谢谢

Answer 1

我认为您只需要将套接字文件更改为666（使用www-data就可以了664），或者将其删除并再次运行uwsgi服务器。

在我的uwsgi.ini中：

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

Answer 2

哇，这个问题花了我差不多一整天的时间！

我使用uwsgi 2.0.14, nginx 1.10.1, django 1.10

总而言之，最重要的是确保以下两个用户对rwx文件具有socket权限：

1. nginx;
的用户
2. uWSGI;
的用户

所以，你可以逐一检查它们。

首先，您可以通过刷新网址来检查网络服务器nginx是否具有权限，例如http://192.168.201.210:8024/morning/，而不运行uwsgi。如果您看到/var/log/nginx/error.log 没有此类文件或目录，请执行以下操作：

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"

只需创建一个名为helloworld.sock的文件，然后刷新网址并再次检查日志文件，如果您在日志文件中看到权限被拒绝，就像这样：

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"

这意味着Web服务器nginx没有读取，写入和执行的所有权限。因此，您可以授予此文件的权限：

sudo chmod 0777 helloworld.sock

然后，如果您看到拒绝连接，请重新刷新网址并再次检查日志文件 在日志文件中，如下所示：

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"

这是一个好兆头，这意味着您的网络服务器nginx有权从现在开始使用helloworld.sock文件。

接下来运行uwsgi并检查uwsgi的用户是否有权使用helloworld.sock。首先，删除我们之前创建的文件helloworld.sock。

运行uwsgi：uwsgi --socket /usr/share/nginx/html/test/helloworld.sock --wsgi-file wsgi.py

如果您看到 bind（）：权限被拒绝[core / socket.c第230行] ，则表示uwsgi无权绑定helloworld.sock 。这是目录test的问题，helloworld.sock的父目录。

sudo chmod 0777 test/

现在，您可以成功运行uwsgi。

但也许你仍然会看到 502 Bad Gateway ，它太可怕了，我整天都看到了它。如果再次检查error.log文件，您将再次看到此信息：

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"

出了什么问题???

检查helloworld.sock文件的详细信息，您可以看到：

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

uWSGI自动授予此文件755权限。

您可以通过添加--chmod-socket：

来更改它

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

OK！最后，你可以看到：



取消消息：

1. uwsgi_params文件的位置并不重要;
2. 由于我的nginx用户和uwsgi用户不相同，甚至不在同一个群组，因此我需要777 helloworld.sock权限给test/及其父目录{ {1}};
3. 如果您将helloworld.sock文件放在主目录中，您将始终获得权限被拒绝。
4. 您需要设置socket文件路径的两个位置，一个位于nginx conf文件中，对我来说是helloworld_nginx.conf;一，当你运行uwsgi。
5. 检查SELinux

这是我的helloworld_nginx.conf文件：

# 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;
    }
}

Answer 3

在CentOS上，我尝试了所有这些东西，但它仍然没有用。最后，我找到了这篇文章：

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

对于开发机器，我们只需运行：

semanage permissive -a httpd_t

但是对于真正的生产服务器，我还没想到。 您可能需要尝试上述文章中描述的其他内容。

Answer 4

我已经解决了这个问题一段时间了，发现我的uid文件中的gid和uwsgi.ini标记未应用于.sock文件

您可以通过运行uwsgi来测试，然后使用linux命令.sock检查ls -l文件的权限。

我的解决方案是使用sudo运行uwsgi：

sudo uwsgi --ini mysite_uwsgi.ini

使用包含标志的.ini文件：

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

然后.sock文件的权限是正确的，502 Bad Gateway错误最终消失了！

希望这会有所帮助：）

Answer 5

这个问题让我发疯了。我的环境是centos7 + nginx + uwsgi，使用unix socket连接。 接受的答案很棒，只需在那里添加一些点。

ROOT USER，QUICK TEST

首先，关闭selinux，然后将chmod-socket更改为666，最后使用root启动uwsgi。

喜欢这个

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

其他用户

如果您使用您创建的其他用户启动uwsgi，请确保主文件夹下的用户文件夹的权限为755，并且所有者和组是对应的。

例如

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

Answer 6

这需要我花很多时间才能找到权限问题。 当然，问题在于权限。 默认用户是nginx。 我做了什么： 在user www-data; 更改用户：

usermod -a -G www-data yourusername

接下来将您的用户加入www-data goup：

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

接下来设置uwsgi：

sudo systemctl restart nginx

然后重新启动nginx：

select

最后重启uwsgi。

Answer 7

uwsgi.ini

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

为什么呢？因为有时应用程序需要读取或写入文件系统，超出Web服务器可访问的范围。我不想仅仅为了适应每种情况而改变一大堆所有权和权限。我宁愿让我的应用程序像我一样运行并做它需要做的事情。将组设置为www-data并将套接字chmod到664允许该组写入，从而提供Web服务器和应用程序之间唯一必要的通信窗口。

Answer 8

另一篇针对CentOS用户的精彩文章：

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

尽管有关CentOS的答案很有用，但问题出在SELinux之下。

我关注了整篇文章，但是解决了这个问题的原因我相信可以在以下命令中找到

：

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/

请使用您的实际用户替换用户以授予权限。 chmod命令下的目录也是如此。

Answer 9

在开发模式下，如果使用root，只需将wsgi.ini或emperor.ini设置如下：

uid=root
gid=root

Answer 10

您需要取消注释

#server 127.0.0.1:8001;

来自上游块的

同样将uwsgi.ini中的更改作为

socket = 127.0.0.1:8001