Nginx reverse proxy woes

I'm trying to set up Metabase behind nginx, and it looks like something isn't quite getting proxied correctly, as attempts to load the page generate a bunch of "No such file or directory" errors.

I can go directly to http://my.server.com:3000, and the Metabase setup wizard renders correctly. But when I try to access it through nginx at https://my.server.com/metabase, the page is just a blank white page. The nginx error log contains errors like

2021/01/26 18:56:52 [error] 14594#14594: *7 open() "/usr/share/nginx/html/app/assets/img/favicon-16x16.png" failed (2: No such file or directory) while sending to client, client: 192.168.0.8, server: my.server.com, request: "GET /app/assets/img/favicon-16x16.png HTTP/1.1", host: "my.server.com", referrer: "https://my.server.com/metabase/setup"

2021/01/26 18:56:52 [error] 14594#14594: *1 open() "/usr/share/nginx/html/app/assets/img/apple-touch-icon.png" failed (2: No such file or directory) while sending to client, client: 192.168.0.8, server: my.server.com, request: "GET /app/assets/img/apple-touch-icon.png HTTP/1.1", host: "my.server.com", referrer: "https://my.server.com/metabase/setup"

On the blank unrendered page I can view page source & see the source loaded correctly, it just didn't render due to unresolvable assets

The nginx sites-available files looks like the below (the commented-out proxy_pass's represent things I've tried)

server {
  listen 80;
  listen [::]:80; 
  server_name my.server.com;

  location /oauth2/ {
    proxy_pass http://127.0.0.1:4180;   
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Scheme $scheme;
    proxy_set_header X-Auth-Request-Redirect $request_uri;  
  }

  location / {
    auth_request /oauth2/auth; 
    error_page 401 = /oauth2/sign_in;
    # pass information via X-User and X-Email headers to backend
    # requires running with --set-xauthrequest flag auth_request_set $user $upstream_http_x_auth_request_user; 
    auth_request_set $email $upstream_http_x_auth_request_email; 
    #proxy_set_header X-User $user;
    proxy_set_header X-Email $email;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass_header Server;
    proxy_connect_timeout 3s; 
    proxy_read_timeout 10s;

    # if you enabled --cookie-refresh, this is needed for it to work with auth_request
    auth_request_set $auth_cookie $upstream_http_set_cookie; add_header Set-Cookie $auth_cookie;
    #proxy_pass http://127.0.0.1:3000;
    #proxy_pass http://my.server.com:3000;
  }  
  location /metabase {
    proxy_pass http://127.0.0.1:3000;
    #proxy_pass http://my.server.com:3000;
  }

listen 443 ssl; # managed by Certbot
#ssl_certificate /etc/letsencrypt/live/<(sub)domain>/fullchain.pem;
#ssl_certificate_key /etc/letsencrypt/live/<(sub)domain>/privkey.pem;
#include /etc/letsencrypt/options-ssl-nginx.conf;
#ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
include snippets/self-signed.conf;
include snippets/ssl-params.conf;

Any help is appreciated

Hi @AccurateHamilton
If you opened your browser developer console, then you should see a warning.
You need to update the “Site URL” in Metabase Admin > Settings > General. Alternatively site-url in application database table setting (or MB_SITE_URL).

I would also recommend having a look at this tool, which can help creating Nginx configs: https://do.co/nginxconfig

Then make sure that you are not able to access Metabase directly, but only through the proxy. By default Metabase only listens on localhost, so I’m not sure how you are able to see it directly.

Hi @flamber,

I’ve found a series of bug reports showing that putting MB behind a reverse proxy isn’t nearly as straightforward as the docs make it out to be in most cases.

I’m going to go in a different direction.

Thanks,

@AccurateHamilton It’s not a problem with using a reverse-proxy - but everything gets a lot more complicated with sub-path.

OK, let me ask the question differently - Do you have an example of a working configuration that successfully reverse-proxies MB and reroutes http requests to https?

I got rid of the subpath and the oauth2_proxy to try to keep it as bare-bones as possible, and it has the same problem. Here’s my new config. Metabase is at the root and it’s doing nothing else but putting it behind https. To the best of my knowledge, this is the bare minimum required, and it works when I use it with other sites like a dokuwiki:

server {
listen 80;
listen [::]:80; 
server_name my.server.com;

location / {
    proxy_pass http://127.0.0.1:3000/;

  }

listen 443 ssl; # managed by Certbot
include snippets/self-signed.conf;
include snippets/ssl-params.conf;
include snippets/general.conf;


if ($scheme != "https") {
    return 301 https://$host$request_uri;
  }
}

Here’s the new environment file for the MB service (ubuntu) with the MB_SITE_URL path set:

MB_DB_TYPE=mysql
MB_DB_DBNAME=metabase
MB_DB_PORT=3306
MB_DB_USER=metabase
MB_DB_PASS=<redacted>
MB_DB_HOST=localhost
MB_SITE_URL=https://my.server.com/

And it still can not find the required assets to render the page:

GEThttps://my.server.com/app/dist/vendor.bundle.js?be17dd105cdbaacd79af
[HTTP/1.1 404 Not Found 12ms]

GEThttps://my.server.com/app/dist/styles.bundle.js?be17dd105cdbaacd79af
[HTTP/1.1 404 Not Found 31ms]

GEThttps://my.server.com/app/dist/app-main.bundle.js?be17dd105cdbaacd79af
[HTTP/1.1 404 Not Found 68ms]

GEThttps://my.server.com/app/assets/img/apple-touch-icon.png
[HTTP/1.1 404 Not Found 0ms]

GEThttps://my.server.com/app/assets/img/favicon-16x16.png
[HTTP/1.1 404 Not Found 0ms]

And again, when I open a private window and navigate to http://my.server.com:3000/ it connects directly to the Jetty server and renders the page properly. I can point the private window at any of the “missing” resources directly and it resolves them just fine.

It seems that whatever was failing in the translation from “/app/dist” to a “/metabase/app/dist” sub-path for those specific assets is also failing to translate “http://” to “https://”. This seems to me like there is a problem with using a reverse proxy, but if I’m missing some critical piece of config I would be very grateful to know what it is.

@AccurateHamilton

Post “Diagnostic Info” from Admin > Troubleshooting.

I don’t understand how Metabase is accessible on port 3000, so you must have been doing something that you’re not listing. Or you are using NAT/firewall redirect too. It’s hard to tell.

And I don’t understand your Nginx error log, and then you say “…failing in the translation…”, but your config is now not using sub-path. Did you remember to restart Nginx after changing the config?

I would highly recommend that you visit a Nginx forum, since they can provide much better help. There’s a million small tweaks and changes you can make, but it’s not really specific to running Metabase.

But this will make Metabase available on https://my.server.com/

server {
  server_name my.server.com;
  listen 80;
  listen [::]:80;
  return 301 https://my.server.com$request_uri;
}

server {
  server_name my.server.com;

  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  include snippets/self-signed.conf;
  include snippets/ssl-params.conf;
  include snippets/general.conf;

  location / {
    proxy_pass http://127.0.0.1:3000/;
  }
}

I tried your config, it fails the same way. Metabase specific assets are 404. To address some of your specific points:

I spent a long time in Support. I get it, all users lie - whether intentionally or by not understanding or forgetting something important. I'm trying to be as thorough as I can, but I can't promise I'm finding everything relevant. Hence, I've provided a full terminal session below, with netstat and firewall output. Please tell me if something seems amiss or forgotten.

Why wouldn't it be directly accessible? Isn't the reverse-proxy basically just playing the middle man between the client browser and the Jetty server? What would nginx serve up if MB wasn't available on port 3000? I opened the port on purpose for testing and will close it when I'm done testing, but as long as the port is open this is exactly the expected behavior, isn't it?

My first configuration used a subpath. That failed. I took out the subpath. That failed too, in the exact same way. The new config you just gave me also fails in the exact same way. No matter what I put in proxy_pass or MB_SITE_URL, my client can not resolve some of the /app/* assets. I did not forget to restart the service. See the terminal session below. Does that clear up the confusion?

I'm going to do that, but please understand my point of view - This is a brand new install of ubuntu 18.04 (arguably the most well supported Linux OS), with a brand new download of MB 0.37.7 with nginx v 1.14 (a fairly popular piece of software in its space) with the second-most basic of "reverse-proxy" configs and Metabase doesn't work. Other software does.

The last time I tried to deploy Metabase managing the certificates itself. It became a brittle hacky mess of manually creating keystores and importing keys, not to mention had a bug where the SSO didn't work quite right & I still have to manually create an account for anyone that wants to log in. At the time you told me to "make my life easier" by setting it up behind a reverse proxy.

I'm trying to follow your advice, but it's still problematic, and despite the previous known bugs that did the exact same thing and customers who let you know that they'd "noticed a few issues like the lack of proxy awareness for site.manifest", you're telling me to go somewhere else for help.

We're going to be spending money on a BI solution sometime in the next year or so. I really want to like Metabase, but these experiences are not making my life easier, and definitely not helping me make an argument that Metabase would be a better choice than the other popular BI tool that people are championing.

Here's the terminal from the session I just ran, you can see if I restarted the services or forgot any other step. I'm going to go elsewhere in search of a magic incantation to get this to work, starting with that guy from issue #12722. I'm hoping that googling "proxy aware site.manifest" will yield some clues. That seems promising.

root@my-dev:/etc/nginx/sites-enabled# ufw status
Status: active

To                         Action      From
--                         ------      ----
127.0.0.1 80/tcp           ALLOW       127.0.0.1                 
443                        ALLOW       Anywhere                  
22                         ALLOW       Anywhere                  
127.0.0.1                  ALLOW       127.0.0.1                 
Nginx Full                 ALLOW       Anywhere                  
4180                       ALLOW       Anywhere                  
3000                       ALLOW       Anywhere                  
443 (v6)                   ALLOW       Anywhere (v6)             
22 (v6)                    ALLOW       Anywhere (v6)             
Nginx Full (v6)            ALLOW       Anywhere (v6)             
4180 (v6)                  ALLOW       Anywhere (v6)             
3000 (v6)                  ALLOW       Anywhere (v6)
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# netstat -antp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      6049/nginx: master  
tcp        0      0 127.0.0.1:4180          0.0.0.0:*               LISTEN      894/oauth2-proxy    
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      819/systemd-resolve 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      996/sshd            
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      6049/nginx: master  
tcp        0    356 192.168.0.18:22         192.168.0.8:63770       ESTABLISHED 2386/sshd: fritz [p 
tcp        0      0 192.168.0.18:22         192.168.0.8:49580       ESTABLISHED 3835/sshd: fritz [p 
tcp        0      0 192.168.0.18:22         192.168.0.8:63605       ESTABLISHED 1580/sshd: fritz [p 
tcp6       0      0 :::33060                :::*                    LISTEN      1118/mysqld         
tcp6       0      0 :::3306                 :::*                    LISTEN      1118/mysqld         
tcp6       0      0 :::80                   :::*                    LISTEN      6049/nginx: master  
tcp6       0      0 :::22                   :::*                    LISTEN      996/sshd            
tcp6       0      0 :::3000                 :::*                    LISTEN      6009/java           
tcp6       0      0 :::443                  :::*                    LISTEN      6049/nginx: master  
tcp6       0      0 127.0.0.1:3306          127.0.0.1:58000         ESTABLISHED 1118/mysqld         
tcp6       0      0 127.0.0.1:58004         127.0.0.1:3306          ESTABLISHED 6009/java           
tcp6       0      0 127.0.0.1:58002         127.0.0.1:3306          ESTABLISHED 6009/java           
tcp6       0      0 127.0.0.1:3306          127.0.0.1:58002         ESTABLISHED 1118/mysqld         
tcp6       0      0 127.0.0.1:3306          127.0.0.1:58004         ESTABLISHED 1118/mysqld         
tcp6       0      0 127.0.0.1:58000         127.0.0.1:3306          ESTABLISHED 6009/java           
tcp6       0      0 127.0.0.1:3306          127.0.0.1:57998         ESTABLISHED 1118/mysqld         
tcp6       0      0 127.0.0.1:57998         127.0.0.1:3306          ESTABLISHED 6009/java           
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
    root@my-dev:/etc/nginx/sites-enabled# pwd
/etc/nginx/sites-enabled
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 my-dev my.server.com

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# cat default
server {
  server_name  my.server.com;
  listen 80;
  listen [::]:80;
  return 301 https://$server_name$request_uri;
}

server {
  server_name  my.server.com;

  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  include snippets/self-signed.conf;
  include snippets/ssl-params.conf;
  include snippets/general.conf;

  location / {
    proxy_pass http://127.0.0.1:3000/;
  }
}
root@my-dev:/etc/nginx/sites-enabled#
root@my-dev:/etc/nginx/sites-enabled#
root@my-dev:/etc/nginx/sites-enabled#
root@my-dev:/etc/nginx/sites-enabled# nginx -t
nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/certs/nginx-selfsigned.crt"
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok 
nginx: configuration file /etc/nginx/nginx.conf test is successful

root@my-dev:/etc/nginx/sites-enabled# systemctl restart metabase
root@my-dev:/etc/nginx/sites-enabled# systemctl restart nginx
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# systemctl status metabase
â—Ź metabase.service - Metabase server
   Loaded: loaded (/etc/systemd/system/metabase.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-01-27 22:09:57 UTC; 1min 32s ago
 Main PID: 6009 (java)
    Tasks: 52 (limit: 4915)
   CGroup: /system.slice/metabase.service
           └─6009 /usr/bin/java -jar /opt/metabase/metabase.jar

Jan 27 22:10:28 my-dev:metabase[6009]: 2021-01-27 22:10:28,348 INFO metabase.task :: Initializing task SendAnonymousUsageStats 📆
Jan 27 22:10:28 my-dev:metabase[6009]: 2021-01-27 22:10:28,388 INFO metabase.task :: Initializing task SendAbandomentEmails 📆
Jan 27 22:10:28 my-dev:metabase[6009]: 2021-01-27 22:10:28,427 INFO metabase.task :: Initializing task SendPulses 📆
Jan 27 22:10:28 my-dev:metabase[6009]: 2021-01-27 22:10:28,484 INFO metabase.task :: Initializing task SendFollowUpEmails 📆
Jan 27 22:10:28 my-dev:metabase[6009]: 2021-01-27 22:10:28,532 INFO metabase.task :: Initializing task TaskHistoryCleanup 📆
Jan 27 22:10:28 my-dev:metabase[6009]: 2021-01-27 22:10:28,589 INFO metabase.core :: Looks like this is a new installation ... pr
Jan 27 22:10:28 my-dev:metabase[6009]: 2021-01-27 22:10:28,601 INFO metabase.core :: Please use the following URL to setup your M
Jan 27 22:10:28 my-dev:metabase[6009]: http://localhost:3000/setup/
Jan 27 22:10:28 my-dev:metabase[6009]: 
Jan 27 22:10:28 my-dev:metabase[6009]: 2021-01-27 22:10:28,623 INFO metabase.core :: Metabase Initialization COMPLETE
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# systemctl status nginx
â—Ź nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-01-27 22:10:03 UTC; 1min 57s ago
     Docs: man:nginx(8)
  Process: 6035 ExecStop=/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid (code=exited, status=0/SUCCESS)
  Process: 6047 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
  Process: 6036 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
 Main PID: 6049 (nginx)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/nginx.service
           ├─6049 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
           └─6054 nginx: worker process

Jan 27 22:10:03 my-dev:systemd[1]: Stopped A high performance web server and a reverse proxy server.
Jan 27 22:10:03 my-dev:systemd[1]: Starting A high performance web server and a reverse proxy server...
Jan 27 22:10:03 my-dev:nginx[6036]: nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/
Jan 27 22:10:03 my-dev:nginx[6047]: nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/
Jan 27 22:10:03 my-dev:systemd[1]: nginx.service: Failed to parse PID from file /run/nginx.pid: Invalid argument
Jan 27 22:10:03 my-dev:systemd[1]: Started A high performance web server and a reverse proxy server.
lines 1-19/19 (END)
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled# 
root@my-dev:/etc/nginx/sites-enabled#

@AccurateHamilton

I have posted the configuration that I use - I can guarantee it works (Ubuntu 18.04, Nginx 1.18, Metabase 0.37.7), but I have no idea what is hiding in your includes - I’m just using manual LetEncrypt references for certificates.

I would recommend enabling debug logging in Nginx to see where the requests are going:
http://nginx.org/en/docs/debugging_log.html

Otherwise you can try Caddy or Apache, if you’re more familiar with those webservers.

There’s thousands of Metabase installations behind proxies, so I know it works, but I don’t know why it’s causing problems for you.
We have created a hosted solution for anyone who doesn’t want to deal with the self-hosting: https://www.metabase.com/start/hosted/

The problem was in the general.conf file, which was created by that config generator you’d recommended https://do.co/nginxconfig. It wasn’t part of my original config. When I removed both that include and the subpath, the reverse proxy works.

I tracked it down today with the help of a co-worker. I see here you also came to that conclusion. Just as an FYI, “Check the includes” would have been a much more helpful and less frustrating piece of guidance yesterday; as opposed to “you must be doing something else” - especially considering you copied and pasted that include back at me as a “known good” config.

You might want to make a note that the defaults generated by that configurator break things. \

Thanks for your time.

@AccurateHamilton

Nginx is a very complicated piece of software - with many configurations - just like most other webservers. This is why we try to avoid writing documentation for that, just like we don’t write documentation for how to optimize and run your databases, since that’s very complicated software too.

I have no idea how you used the configuration tool, or what all your configs looked like. You didn’t even write that you had used the tool.

Your initial configs were not “best practice”, which is why I recommended using a tool to help you, and the includes were present there too.
But it might be helpful to others if you write what the problem was (which include you removed/changed)

@AccurateHamilton

It seems that the MB_SITE_URL is not necessarily important as the site should load without it as well.

What actually solved this issue for me was adding a trailing "/" to the nginx location entry. This seems to be important as nginx handles no-trailing-slash and trailing-slash somewhat differently when handling URIs.

This works (name metabase refers to the metabase instance):

location /metabase/ {
proxy_pass http://metabase:3000/;
}

This does not:

location /metabase {
proxy_pass http://metabase:3000/;
}

This tries to access http:// metabase:3000/metabase which is also not correct:

location /metabase {
proxy_pass http://metabase:3000;
}

Hi

I have read this thread and re-read it a few times and played with all different configurations and I for some reason am doing something wrong here as I am not able to access the site with nginx.

I am not using SSL yet, so my nginx file is pretty basic:

server {
listen 80;
listen [::]:80;
server_name my-site.com;

access_log  /var/log/nginx/my-site.com.access.log;
error_log   /var/log/nginx/my-site.com.error.log warn;
# reverse proxy
location / {                                            [here i tried with /my-site.com/ as well]
    proxy_pass http://127.0.0.1:3000;   [here i tried with a trailing / as well]

}

when i try hit my site at http://my-site.com I get the following error messages:
2021/07/22 18:17:50 [error] 6189#6189: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 84.223.122.61, server: bi.surge.media, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host:

So i wanted to check that I had nginx configured correctly and add in
root /var/www/test;

and then when i go there i see my Hello World index.html

if i try go to http://my-site.com:3000/. I am able to access metabase no problem. Which after reading above @flamber comment:
[I don’t understand how Metabase is accessible on port 3000, so you must have been doing something that you’re not listing. Or you are using NAT/firewall redirect too. It’s hard to tell]
made me think I am doing something wrong here.

I am not using any firewall/NAT.

My Diagnostic Info is as follows:
{
"browser-info": {
"language": "en-US",
"platform": "MacIntel",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36",
"vendor": "Google Inc."
},
"system-info": {
"file.encoding": "UTF-8",
"java.runtime.name": "OpenJDK Runtime Environment",
"java.runtime.version": "11.0.11+9-Ubuntu-0ubuntu2.20.04",
"java.vendor": "Ubuntu",
"java.vendor.url": "https://ubuntu.com/",
"java.version": "11.0.11",
"java.vm.name": "OpenJDK 64-Bit Server VM",
"java.vm.version": "11.0.11+9-Ubuntu-0ubuntu2.20.04",
"os.name": "Linux",
"os.version": "5.4.0-80-generic",
"user.language": "en",
"user.timezone": "Etc/UTC"
},
"metabase-info": {
"databases": [
"h2",
"mysql"
],
"hosting-env": "unknown",
"application-database": "mysql",
"application-database-details": {
"database": {
"name": "MariaDB",
"version": "10.3.29-MariaDB-0ubuntu0.20.04.1"
},
"jdbc-driver": {
"name": "MariaDB Connector/J",
"version": "2.6.2"
}
},
"run-mode": "prod",
"version": {
"date": "2021-07-14",
"tag": "v0.40.1",
"branch": "release-x.40.x",
"hash": "ed8f9c8"
},
"settings": {
"report-timezone": null
}
}
}

My /etc/default/metabase
looks like this:
MB_PASSWORD_COMPLEXITY=normal
MB_PASSWORD_LENGTH=10
MB_JETTY_HOST=MY.SERVER.IP.AD
MB_JETTY_PORT=3000
MB_DB_TYPE=mysql
MB_DB_DBNAME=metabase_db_name
MB_DB_PORT=3306
MB_DB_USER=metabase_user
MB_DB_PASS=my_passwd
MB_DB_HOST=localhost
MB_EMOJI_IN_LOGS=true

I am able to run metabase as a service as well.

@Surge This is your problem MB_JETTY_HOST=MY.SERVER.IP.AD
Change it to MB_JETTY_HOST=127.0.0.1 and restart the Metabase service, then it should be accessible via Nginx.

1 Like

@flamber I wanted to hit that heart button like 20 times now!!

You have been an amazing asset helping me today. I am highly active member in the mautic community and do my best to answer as much as I can on the forum and I can say that I highly appreciate your precise and exact answers!!

Thank you very much.

I am going to now run certbot to add SSL, usually I use the following command:
certbot --nginx --agree-tos --redirect --hsts --staple-ocsp --email myemail@mydomain.com -d my-site.com

Any pointers before i hit enter ?

@Surge Hit it 21 times, then it stays on :wink:
I only create certificates via certbot - I have never used the built-in --nginx or --apache, since it was not very good in the beginning (and I used quite advanced configs), but it looks correct.
But as with anything - just make sure you got backups of the Nginx configs, then run certbot - if it goes totally haywire, then revert to your backup configs.

Remember to update Admin > Settings > General > Site URL after you have a working certificate. If I remember correctly, you do not want to enable redirection in Metabase, since that's already handled by Nginx (at least from looking at your certbot command), which is much faster/better at doing that.

wonderful. It is now SSL secured and I am up and running and feeling more confidence to move to production with the mysql rather than H2.

Once again thank you. I do hope that these threads will be able to help other newbies like me.

Regards,

Mike