Hi! Are you using a firewall such as UFW? If you are, could you verify that the port you are running your database on it open, and unrestricted and that your database user is configured correctly to connect to the Postgres database with the external IP?
In addition, are you connecting to a database that is located on the same server as your Mattermost instance, or is this a remote database?
Hello! Thanks for your response! To address your questions:
There is currently no firewall on the server.
The database and mattermost instance are located on the same server and I can connect to the postgres database with mmuser. Should I change the ip address to something else in my config.json?
Sorry if the question seem basic, Iām pretty new to this.
@markll80 Iām thinking this may be a networking error.
If you are hosting the Mattermost instance on the same server as the database, but you have the configured database user attempting to connect to the database as if it was connecting to a remote database on a different server (which is done by using the public IP address), then you may be having a routing conflict. This would be due to the Mattermost database connection agent attempting to connect to itself remotely, when instead, you should be using a database user that is configured to only be able to connect from the localhost.
For example, with MySQL, the database user that I am using, is mmuser@localhost. This means that the database user is directly connecting back to the local database, which is knows due to being an account connecting at the localhost, is on the local machine.
I hope this makes sense and helps, let me know if it works out, and if it doesnāt, Iāll continue to help you troubleshoot!
Also, I ran a nmap scan on the IP address you included in the sample code, and it doesnāt have any ports open, so could not possibly connect to the database even if everything else was setup correctly. Is the IP in the code example you initially provided the actual production IP address, or just a placeholder?
Hello, I am having the same issue but I cannot resolve by changing the ip address to localhost and removing the port number.
I am using the docker-compose from this repo ā> GitHub - mattermost/docker: Install Mattermost server via Docker
and launching it on a Ubuntu EC2 ami. The only thing I am editing is the env.example where I set the domain to my machineās ip address and changing the image to the āteamā edition.
I get the same error when Mattermost goes to ping the DB on postgres
`"timestamp":"2023-03-21 15:15:49.867 Z","level":"error","msg":"Failed to ping DB","caller":"sqlstore/store.go:250","error":"dial tcp 127.0.0.1:5432: connect: connection refused","retrying in seconds":10}`
This is the env var responsible for talking to the DB
I have replaced @postgres:5432 with the eth0 ip of the postgres container . I have tried the localhost address. I have also tried using @localhost:5432.
I donāt know what the magical incantation is and I donāt know why it runs perfectly fine on my local machine.
Hi @KnifeHand and welcome to the Mattermost forums!
When using the docker-compose deployment, the postgres host should not be localhost because that would mean itās running inside the Mattermost application container, which it doesnāt. It needs to be set to postgres (the defaultand this should also be the container name/alias of the database container you've spun up. So as long as your Mattermost containers both are running and if your docker network and name resolution works, the application container should be able to connect to your database container namedpostgres` within the same network.
Can you post the output of the following two commands, please?
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
70b91290ab28 mattermost/mattermost-team-edition:7.1 "/entrypoint.sh mattā¦" 9 hours ago Up About a minute (health: starting) 8067/tcp, 0.0.0.0:8065->8065/tcp, :::8065->8065/tcp, 8074-8075/tcp, 0.0.0.0:8443->8443/udp, :::8443->8443/udp docker_mattermost_1
7dc8981817f9 postgres:13-alpine "docker-entrypoint.sā¦" 9 hours ago Up 9 hours 5432/tcp docker_postgres_1
Alright, this looks good - please use postgres as the name of your database host in the connection string, the connection should work that way and at least not return a connection refused.
I kept the following variable (line 83) to connect to the DB the same:
## Below one can find necessary settings to spin up the Mattermost container
MM_SQLSETTINGS_DRIVERNAME=postgres
MM_SQLSETTINGS_DATASOURCE=postgres:${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}?sslmode=disable&connect_timeout=10
Unfortunately, I have the same error message result.
{"timestamp":"2023-03-22 14:21:22.985 Z","level":"info","msg":"Server is initializing...","caller":"app/server.go:264","go_version":"go1.18.1"}
{"timestamp":"2023-03-22 14:21:22.985 Z","level":"info","msg":"Pinging SQL","caller":"sqlstore/store.go:228","database":"master"}
I cannot see an error message in your logs - Pinging SQL is OK, itās just a status message here, it does not say that the ping is unsuccessful. Do you have any other logs after that?
OK, can you please try to start the container in foreground? If you use docker-compose, then please run:
docker-compose down
docker-compose -f docker-compose.yml -f docker-compose.without-nginx.yml up
(no -d at the end of the up and you should stay in foreground and hopefully see more logs).
Thereās also a logfile called mattermost.log which should be available in the subdirectory volumes/app/mattermost/logs/ (relative to your docker-compose files), maybe this file contains more information.
It is again trying to connect to 127.0.0.1:5432, not postgres:5432.
I think your .env file is broken, hereās my MM_SQLSETTINGS_DATASOURCE variable, it looks different than yours:
Each time I make an edit to the env.example file, I copy it to the .env.
I had to take out the double slashes ā//ā before ${POSTGRES_USER} due to a parsing error. However, when I keep the slashes and run docker compose up on my local machine, no problems.
OK, now we get closer to the real problem. I guess that your docker-compose version is too old and is unable to use variable substitution and therefore fails. The first working version is 1.26.0, yours is probably older.
If youāre using docker-compose from your distribution and the package is outdated and you cannot upgrade it, then please remove it and download the binary. If you have the binary distribution already, replace it with a newer version: