0

I've got nginx 1.8.1 on a server running FreeBSD 10.2. I'm trying to serve files from a subdirectory of /usr/local/www/ (which is default on FreeBSD), but for some reason, requests to the files I'm trying to access always result in a 404.

The file specifically is /usr/local/www/example.com/pubic_html/index.html, with /usr/local/www recursively owned by www:www, the user and group of the nginx worker process, with permissions recusrively set to 755.

My server block, in /usr/local/etc/nginx/sites-available/example.com:

server {
    listen 80 default;
    server_name example.com www.example.com;

    root /usr/local/www/example.com/public_html;

    location /app {
        proxy_pass http://localhost:8080;
    }

    location / {
        try_files $uri =404;
    }
}

I'm honestly puzzled by this. I haven't had this issue on Linux with Nginx or Apache, and I haven't had this issue working with Apache on FreeBSD before, either. How can I get nginx to serve this static file?

EDIT: while requests for static files don't result in anything being logged to my nginx-error.log, it does result in normal 404 hit records in the nginx-access.log.

Jules
  • 201
  • 4
  • 11
  • nginx error.log usually contains the answer. – citrin Nov 17 '16 at 00:30
  • There's nothing at all about these 404s in `nginx-error.log`. The entries in `nginx-access.log` aren't informative. – Jules Nov 17 '16 at 00:51
  • Did you try adding an `index index.html`? Also, unless you have a very good reason, `www-data` -being your webserver runtime user- should not have write permissions over the content it serves. – SYN Nov 17 '16 at 01:03
  • @SYN this is just a test; I'm trying to get familiar with setting up nginx on FreeBSD. Normally I would put it to 644 with ownership by `someuser:www-data`. (And just to nitpick; `www-data` is `www` on FreeBSD). – Jules Nov 17 '16 at 01:28
  • What is the URL you are trying to access? – Michael Hampton Nov 17 '16 at 02:12
  • @MichaelHampton `mysite.com/index.html` – Jules Nov 17 '16 at 02:25
  • Hmm. You used someone else's domain name. Are you sure you're connecting to _your_ server and not _their_ server? – Michael Hampton Nov 17 '16 at 02:26
  • @MichaelHampton ... I'm sorry? I'm just putting `mysite.com` as a placeholder. I'm most certainly in control of this domain, I have the base URL forwarded to an app running on my server. – Jules Nov 17 '16 at 02:29
  • It's a really bad idea to use other people's domain names as examples, as it will confuse people. As for "the base URL forwarded to an app running on my server" .. what do you mean by that? There's nothing about that in your question. – Michael Hampton Nov 17 '16 at 03:34
  • @MichaelHampton I was under the impression that `mysite.com` is a fairly common placeholder and that it would be self-descriptive (and therefore obvious). I can update it to `example.com`, which is (IIRC) operated by IANA for this exact purpose. I didn't include details about the app because it's irrelevant to this question. I have a Golang web application running on port 8080 on the same machine, where requests on port 80 of a different `location` block inside the same `server` block are being forwarded to it. – Jules Nov 17 '16 at 05:58
  • Are you 100% sure it's irrelevant? How so? Does your 404 page say "nginx" at the bottom, or does it simply say `404 page not found` in monospace text? It might be better if you posted the complete `server` block, just in case. BTW, `mysite.com` is a dodgy webhosting provider who really don't need any more free advertising. – Michael Hampton Nov 17 '16 at 06:00
  • The 404 page does include `nginx/1.8.1` at the bottom, yes. I'm quite sure that the remaining part of the `server` block is irrelevant, yes, but I'll post it all the same in a few minutes. – Jules Nov 17 '16 at 06:03
  • OK, I agree that's irrelevant. But it never hurts to make sure of everything. On that note: Are you absolutely 100% certain that you are typing `example.com/index.html` into your browser? Not `example.com` or something else? – Michael Hampton Nov 17 '16 at 07:54

2 Answers2

0

OK here's the thing: the default configurations for web servers in FreeBSD DO NOT use files inside the sites-available directory. Either you have to put the contents of the files inside /usr/local/etc/nginx/nginx.conf or add this line to /usr/local/etc/nginx/nginx.conf so that it will read files inside the sites-available directory:

# virtual hosting
include /usr/local/etc/nginx/sites-available/*.conf;

The same behavior also applies to Apache on FreeBSD. (Probably on other web servers as well, but I have experience only with these two.)

Manuth Chek
  • 402
  • 2
  • 6
  • 16
  • This line was in the default `nginx.conf` that was placed inside the initial `pkg install`. I've even intentionally missed semicolons in site config files to make sure it was really reading them; `nginx -s reload` errored (as expected) when this happened. – Jules Nov 17 '16 at 15:13
  • This was not like my case. Anyway you can put the content right inside nginx.conf instead to make sure that the configurations really work. – Manuth Chek Nov 18 '16 at 05:36
  • I _have_ made sure the configuration really works -- there's literally no need at this point to verify that. – Jules Nov 18 '16 at 05:51
0

Do you have other configuration files for Nginx?
I guess you have listen <ip> directive somewhere else so you should also use listen <ip> default_server or listen <ip>:80 default_server in your example.com configuration.

Fedor Dikarev
  • 736
  • 4
  • 10
  • I have no other configuration files for nginx, and I'm confident this is the one being read; otherwise I wouldn't be able to do port forwarding on that web application at `/app`. I tried changing `default` to `default_server`, as well as explicitly writing the public IP of my server instead of just `80`, but no dice. – Jules Nov 18 '16 at 01:19
  • One more guess: have you tried `try_files $uri $uri/ =404` or remove `try_files` ? I've tried your config, and it works with `curl --resolve example.com:80:127.0.0.1 http://example.com/index.html` but failed with `curl --resolve example.com:80:127.0.0.1 http://example.com/` and `try_files $uri $uri/ =404` or removing `try_files` fixed this too. – Fedor Dikarev Nov 18 '16 at 08:55