Nginx – 403 Forbidden serving static files from VirtualBox shared folder with nginx (Ubuntu 10.04LTS guest, Windows 7 host)

http-status-code-403network-sharenginxUbuntuvirtualbox

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?

Best Answer

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.