0

I'm trying to serve static files directly with a location block like this:

location /static/ {
    alias /opt/graphite/webapp/content/;
}

But when I make a request for anything matching /static/, I get a 404 error, and a message like this in the error log:

2016/09/14 09:28:47 [error] 66068#0: *4 open() "/opt/graphite/webapp/content/js/completer.js" failed (2: No such file or directory), client: my.ip.add.ress, server: server.domain, request: "GET /static/js/completer.js HTTP/1.1", host: "server.ip", referrer: "http://server.ip/composer?"

The thing is that the path given in that error message is completely valid. That file exists. It's not claiming permission denied, so it doesn't seem like a permissions issue. The location that proxies to the app works fine. I'm at a loss, and similar posts all seem to pertain to sockets.

Running nginx 1.10.1 on OpenBSD 6.0.

Mud Bungie
  • 21
  • 2
  • Permissions is most likely Please post permissions for the object, including owner and group, and tell us what user / groups Nginx is running as. – Tim Sep 14 '16 at 21:03
  • Permissions of the object are 644, owned by www:www, which is the user that nginx is running as. Directory is 775, also www:www. – Mud Bungie Sep 14 '16 at 21:05
  • I would try adding a second line to your location block with a `try_files` directive and point it to a distinct error (like '499') on fail instead of 404 to confirm this is tripping. Second, try rewriting your location block with a regex and using `root` instead of `alias`. – Ryder Sep 14 '16 at 21:27
  • Tried that. Successfully returns a `499` after the `try_files` fails (though no error is logged, since `try_files` coming back empty doesn't count as an error). I was using `alias` because the URL structure doesn't correspond directly to the directory structure, but after remediating that, I get the same behavior. Logged error claiming that a file which exists does not exist. – Mud Bungie Sep 14 '16 at 21:55
  • Have you checked the permissions of all of the parent directories? – Richard Smith Sep 14 '16 at 21:55
  • Global read and execute all the way up to the root. – Mud Bungie Sep 14 '16 at 22:06
  • And, for what it's worth, I can read the files that aren't returned with `sudo -i www cat /opt/graphite/webapp/content/js/*`, which would seem to indicate that permissions are not the problem. – Mud Bungie Sep 14 '16 at 22:08
  • Could it be something really simple like a path mismatch? Are you 100% sure your base URL is set correctly? What is the full path of this file on the file system? – Tim Sep 14 '16 at 22:24

1 Answers1

2

Figured this out. The distribution of nginx in OpenBSD defaults to chrooting into /var/www/, which denies access to the entire filesystem outside of that section. This can be circumvented by starting nginx directly with the -u flag, or adding that same flag to the command in /etc/rc.d/nginx.

Alternatively, moving everything into the chroot is pretty trivial, once you know that's what's happening.

Mud Bungie
  • 21
  • 2
  • Always good to check the OpenBSD manpage for nginx. Not a well advertised feature, and if you administer different boxes you may be caught out whether the binaries on the machine are built from ports (includes -u un-chroot) or src (not include -u) – samt Sep 15 '16 at 22:37