Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

UPDATE

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;
    proxy_pass http://127.0.0.1:8080;
}

Is there anything wrong with this?

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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