In my /etc/nginx/nginx.conf file I have a server block like this:
server {
location /testme/ {
root /home/username/sites;
index index.html index.htm;
}
}
When I visit http:localhost/testme/ in my browser, shouldn't files be served from /home/username/sites/testme/ directory, where I have my simple index.html? Instead I get 404 Not Found Error. What I am doing wrong here.
NOTE: I did sudo nginx -s reload after changing configuration.
Related
I have the current syntax in my nginx server block in /sites-available/:
location / {
try_files $uri $uri/ /index.php?$args;
}
Actually i have a WordPress installation in my root folder. And I have some folders mixed in the root folder too. So looks like these:
https://mywebsite.com/mycustomfolder/foo/bar/ <- WordPress URL
https://mywebsite.com/mycustomfolder/ <- Folder with simple HTML files
I need to access both of the cases. But the nginx is forcing somehow to just access /mycustomfolder/ who have no files and I get a 403 Forbidden or I access the files normally if have them.
So, what I desire is, if there is no files or folder, just keep WordPress show a 404 page or a custom created. And if there is files or folder, show them as HTML/PHP normally.
I have a webapp running in kubernetes. I want to serve static files, css in my case, from nginx pod. From the application I define css file location like this:
<link rel="stylesheet" href="assets/css/stylesheet.css" type="text/css">
When building docker image I copy over css file to www/media/ and in nginx config I point to that:
FROM nginx
RUN rm /etc/nginx/conf.d/default.conf
COPY config/default.conf /etc/nginx/conf.d/default.template
COPY assets/ /www/media
EXPOSE 80
Here's nginx config:
server {
listen 0.0.0.0:80;
server_name localhost;
location / {
proxy_pass http://${FLASK_APP}:8080/;
}
location ~ /assets {
root /www/media;
}
}
I have confirmed that the file can be found on nginx pod under /www/media/css/stylesheet.css, however I cannot reach it neither from the browser nor the application itself.
The error I get is this:
GET http://192.168.99.106:30604/assets/css/stylesheet.css net::ERR_ABORTED 404 (Not Found)
/assets should point to www/media where the directory with stylesheet are kept, correct?
What am I misunderstanding?
Not sure if this is the solution, but hopefully some things to try.
Change your docker file to
COPY assets /www/media
In your comments you've said that you can see the files in /www/media. But you're trying to access them in /assets. Have you configured this in nginx correctly? Perhaps try this
location /assets/ {
alias /www/media/;
}
Final thing I would mention is permissions. What are the permissions of the files in the container? ls -la will tell you this. They should be 755 I believe for Nignx.
Hope this helps you.
Ok, I figured it out.
Here's my Nginx config to serve the files:
server {
listen 0.0.0.0:80;
server_name localhost;
location / {
proxy_pass http://${FLASK_APP}:8080/;
}
location ~ \.css {
root /www/media;
}
}
I also changed my docker a bit:
FROM nginx
RUN rm /etc/nginx/conf.d/default.conf
COPY config/default.conf /etc/nginx/conf.d/default.template
COPY assets /www/media/assets
RUN chown -R nginx:nginx /www/
EXPOSE 80
With the above config in place css is being served without any issues.
Is it possible for me to have an nginx server's domain to contain slashes? For example, for the server's root url location to be https://example.com/apps/app1?
I have a server whose files need to be served from /opt/production/app1/public. My current nginx.conf configuration, which doesn't work, contains:
location /apps/app1 {
root /opt/production/app1/public;
}
But obviously, this doesn't work because my files aren't at /opt/production/app1/public/apps/app1. I would like for nginx to consider https://example.com/app/apps1 to be my domain, so that my nginx.conf can access content as so:
location / {
root /opt/production/app1/public;
}
Is this at all possible? If not (which I suspect is the case), is there a way to work around this w/o changing the url schema?
If I understand your question correctly, you can try an alias directive for /apps/app1/ location:
location /apps/app1/ {
alias /opt/production/app1/public/;
}
I have a website which is an app containing other apps.
In the main app, I'll load the other apps with iframes.
The main app is served at the domain root: http://example.com
The other apps are served under the /apps path:
http://example.com/apps/app-a
http://example.com/apps/app-b
Also the apps are developed in Polymer so there is client side navigation. I make sure the /apps path is not used on the client side to hit the NGINX server correctly but it also means that for url such as http://example.com/view1 it should redirect to the index.html of the main app. And for url like http://example.com/apps/app-b/view1 it should redirect to the index.html of app-b.
I'm trying to configure NGINX to serve those static apps.
server {
listen 80;
server_name example.com;
root /var/www/example.com/main-app;
index index.html;
try_files $uri $uri/index.html /index.html;
location ~ /apps/([a-z-]+) {
alias /var/www/example.com/apps/$1;
}
}
With the above config I have the main app working with the correct redirection to the index.html for the /view1 path for example.
But I have a 403 forbidden error for the sub apps.
directory index of "/var/www/example.com/apps/app-b" is forbidden,
client: 127.0.0.1, server: example.com, request: "GET /apps/app-b/
I've tried other configurations with no success (infinite redirection leading to /index.html/index.html/index.html...).
I'm sure about the filesystem permissions all directories are 755 and files are 644.
I don't know why it is trying to do a directory index.
Any help is appreciated.
When using alias with a regular expression location, you need to build the entire path to the file. Currently, you are only capturing the second path element.
Having said that, you do not actually need to use an alias here, as the root directive can be use instead.
location /apps/ {
root /var/www/example.com;
}
See this document for details.
I have some slate docs as website and would like to serve them on the internal server, through a subdomain as follows: internal-docs.mysite.com. For the record, accessing mysite.com shows the "nginx is running propertly" page.
I've created a config file with following path and name: /etc/nginx/sites-available/internal-docs.mysite.com:
server {
listen 80;
server_name internal-docs.mysite.com;
root /var/www/docs-internal;
index index.html;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
error_page 404 /404.html;
}
And of course, I've put the files in /var/www/docs-internal. And then I made a symlink to the uppershown config file in the /etc/nginx/sites-enabled dir:
internal-docs.mysite.com -> ../sites-available/internal-docs.mysite.com
Then I reload nginx -s reload but "this site can't be reached" error is what I get when accessing the URL.
The setup and configuration look correct to me (according to the guidelines I've followed), so that's why I'm in a dead end, sort of...
It seems you forgot the Listen directive. Try the following:
server {
listen 80;
server_name internal-docs.mysite.com;
root /var/www/docs-internal;
index index.html;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
error_page 404 /404.html;
}
If that does not work, check:
That Nginx user has read permission to the site content. For example if your Nginx user is www and you have root access, do the following:
# su www
$ cat /var/www/docs-internal/index.html
If that fails, ensure the location has correct ownership and permissions. Note that for a user to be able to browser a directory, that directory must have the execute bit for that user or user group.
That Nginx user has read permission on file ../sites-available/internal-docs.mysite.com. For example if your Nginx user is www and you have root access, do the following:
# su www
$ cat /etc/nginx/sites-available/internal-docs.mysite.com
If that fails, ensure that the config files have correct ownership. Note: normally Nginx master process is run by root, and that process spawns sub-processes run as Nginx user, so permissions on config files are unlikely to be the problem.
That maybe your config file name should end with ".conf" (on my server I have the following line: include conf.d/*.conf; so it will NOT load any conf file ending with ".com".
That Nginx tries to load files in ../sites-available/ in its main config file. Maybe it does not and looks instead in the conf.d directory (the default).
That you can do a ping and nslookup on the subdomain. If you cannot, then you have to fix that first (DNS, firewall...).
For the sake of others - the configuration I wrote was correct, and my problem was in 2 things:
I had to remove the listen 80 directive, since there is another configuration file already, that specifies that nginx should listen on port 80. One should not tell nginx twice to listen on the same port, even if it's in two separate configuration files
Permissions on the /var/www/docs-internal folder. Opening a folder requires x (execute) permissions, while opening a file requires r (read) perm. I had to provide the according permissions to all the folders in this hierarchy, so that the content could be open globally (from everyone), which is basically accessing it from the browser.