I'm working on a local development VM and trying to test serving my site with gunicorn and nginx as a reverse proxy for static resources only. The site loads minus static resources with user nginx; in nginx.conf. Attempting to load a static resource individually reveals a 403 Forbidden error.

For background. The static resources are in a shared folder under /media/sf_work. All files are owned by root:vboxsf (VirtualBox default). My user account on the system has been added to the vboxsf group, and I have full access to the shared folder.

For comparison, I tried changing the nginx.conf user to my user account. In that scenario, the static files did load, but then the homepage itself gives a 403 Forbidden error. So, I then tried adding the nginx user to the vboxsf group, but then everything gives a 403 Forbidden error. After further investigation it seems that if the nginx.conf user is in any group, it results in a 403 Forbidden.

Any idea what could possibly be going on here?


So, the issue with the homepage returning 403 Forbidden when using my user account as the nginx user (the only way that static files work) is related to no index.html file being in the directory (directory listing denied). However, I obviously don't want it to list the directory; it should be passing this request off to the gunicorn proxy. I'm using the following:

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;

Is there anything wrong with this?


So, I finally solved it. First, the nginx.conf user must have access to the shared folder, obviously, which means I had to use my user account. I'm not happy about that, but this is just a development box, so security is really not a concern.

Then, there was a problem with my try_files directive. In retrospect, it makes perfect sense. I'm requesting /, and that directory actually does exist, but I don't want that match. So what I actually needed was:

try_files $uri @proxy

Then, everything worked fine.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.