Я работаю над локальной виртуальной машиной разработки и пытаюсь протестировать обслуживание моего сайта с помощью gunicorn и nginx в качестве обратного прокси-сервера только для статических ресурсов. Сайт загружает минус статические ресурсы с помощью user nginx;nginx.conf. При попытке загрузить статический ресурс по отдельности выявляется ошибка 403 Forbidden.

Для фона. Статические ресурсы находятся в общей папке под /media/sf_work. Все файлы принадлежат root:vboxsf(по умолчанию VirtualBox). Моя учетная запись пользователя в системе была добавлена ​​в vboxsfгруппу, и у меня есть полный доступ к общей папке.

Для сравнения я попытался изменить пользователя nginx.conf на свою учетную запись. В этом сценарии статические файлы загружались, но затем сама домашняя страница выдает ошибку 403 Forbidden. Итак, я затем попытался добавить nginxпользователя в vboxsfгруппу, но затем все выдает ошибку 403 Forbidden. После дальнейшего расследования выяснилось, что если пользователь nginx.conf находится в какой-либо группе, это приводит к 403 Forbidden.

Есть идеи, что здесь может происходить?

ОБНОВИТЬ

Итак, проблема с домашней страницей, возвращающей 403 Forbidden при использовании моей учетной записи в качестве пользователя nginx (единственный способ работы статических файлов), связана с отсутствием файла index.html в каталоге (список каталогов запрещен). Однако я, очевидно, не хочу, чтобы он отображал каталог; он должен передать этот запрос прокси-серверу. Я использую следующее:

location / {
    try_files $uri $uri/ @proxy
}
location @proxy {
    proxy_pass_header Server;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Scheme $scheme;
    proxy_connect_timeout 10;
    proxy_read_timeout 10;
    proxy_pass http://127.0.0.1:8080;
}

Что в этом плохого?

answer

Итак, я наконец решил это. Во-первых, очевидно, что пользователь nginx.conf должен иметь доступ к общей папке, а это значит, что мне пришлось использовать свою учетную запись. Я не доволен этим, но это всего лишь ящик для разработки, поэтому безопасность на самом деле не является проблемой.

Затем возникла проблема с моей try_filesдирективой. Оглядываясь назад, это имеет смысл. Я запрашиваю /, и этот каталог действительно существует, но я не хочу этого совпадения. Так что мне действительно нужно было:

try_files $uri @proxy

Потом все заработало.