jj9987

User `postgres` is configured with ID 999 in the container. The docker entrypoint script configures the postgres data directories to be owned by that user, if container is started as root (but postgres is run as postgres user). https://github.com/docker-library/postgres/blob/master/15/bookworm/docker-entrypoint.sh#L59

That's normal PostgreSQL log at default level (LOG: indicates informative message). What's the exact error you are seeing?

What update did you do? What tag are you using?

PostgreSQL has a process, that you must follow for major version upgrades.

Seems like the user, that is connecting to the database, does not have the correct permissions. What have you done so far? How did you configure the database and the users?

Postgres doesn't change the permissions, unless it is run the first time (when it needs to initialize the data directory) even then it sets them to 775. 600 might not be enough for PostgreSQL data directory anyway. https://github.com/docker-library/postgres/blob/master/14/bullseye/docker-entrypoint.sh The owner can be unknown, because it is configured for the user ID that Postgres image runs as within the container. Just because host doesn't know the UID, doesn't mean it's broken. But it needs to match the userID, that the postgres process in Docker runs as. PUID and PGID don't do anything, they are specific to Linuxserver images, not Docker in general. It feels like something else is changing the permissions.

PostgreSQL upgrades aren't as easy as increasing the version. To do it properly, you have three options: 1) Dump all data from the old version, import it into the new version. 2) Go through the pg_upgrade process, which requires you to have binaries for both versions, but can be done in-place. 3) Using replication. Follow the official documentation on how to do each one of them, whichever suits you best: https://www.postgresql.org/docs/current/upgrading.html In case of containerized PostgreSQL, dump/import is probably the easiest to do, but will cause downtime.

Added the template for postgres 15. Postgres CLI tools default to the same database name as the user you are trying to connect with. Maybe your database has a different name?

pg_dumpall tries to dump the whole database instance (all databases) and needs root/superuser permissions. If you want to dump a single database, use pg_dump.

It's a password failure error. Have you tried resetting the password?

What are the errors you are seeing?

These logs are normal, nothing alarming. It says it is ready to accept connections, so could it be something else? Wrong IP perhaps?

Howdy Docker works by mounting host paths to container paths. These are called volumes. Check where /var/lib/postgresql/data is mounted to. Latest version of the template defaults to /mnt/cache/appdata/postgresql<version>, e.g. /mnt/cache/appdata/postgresql14. That directory either should not exist, be empty or only contain PostgreSQL own files.

Port 5432 is not WebUI, it is PostgreSQL TCP port. This container only runs the database engine itself. If you want a webUI, you need to find and deploy some other tool.

What version of psql are you using to connect to it? What error is psql giving? Server logs do not give very much information what the error is.

Howdy. Just deleting the Docker won't wipe your data, unless you specifically also delete the appdata folder (whether it is on the array or cache drive). So if the appdata is still there and you recreate the container (has to be the same major version of PostgreSQL), all the databases and the data should still be there. As for recovery, standard data recovery applies, but it is much harder to do with databases, since it is not just one file. And if part of it is missing, basically all is gone. You can add additional databases when you log in as superuser `postgres` and run `CREATE DATABASE <name>;`. Security-wise I'd also recommend to have different users with the necessary permissions (e.g. one user can only access one database etc). For auto-backups, you can run a cron job, that runs `pg_dump` or `pg_dumpall`. Alternatively you could use pgBackRest, but there is no template for it at this moment, it needs additional configuration and is more complicated. --- Made some changes to the templates: - BREAKING CHANGE: Database volume paths now include version tag, e.g. `/mnt/cache/appdata/postgresql10` so you can run multiple instances with different versions at the same time. - BREAKING CHANGE: PostgreSQL 10 template got changed, this could have broken stuff on old users. I am not familiar with the template changes on older versions. - Added PostgreSQL 12, 13 and 14 templates. - Container names changed to lowercase and includes version, e.g. `postgresql14`. This should make it easier for using in custom networks. - Brought the templates up to date with current schema version. Hopefully it is more user-friendly now. Feedback welcome. Sorry, it's been too long since I updated them.

The upgrade is sorta complicated, you need both old and new binaries available, which the official docker images do not provide. Backup and restore might be more convenient and easier.

It's absolutely okay to use one database instance with multiple databases for multiple apps. You will just have to create the new databases (and preferably also new roles) through the psql shell. Postgres upgrades can't be done by simply changing the version tags, they often have changes that require additional steps (e.g. pg_upgrade). So definitely don't use the latest tag. I changed the templates long time ago, haven't added newer templates to the repo though. Here's the information on how to do it: https://www.postgresql.org/docs/14/upgrading.html

I started to use unRAID because it was a complete package. It includes well-tested software that was designed to be working together and do it reliably. Plus it came with community support. I would love to see VM snapshots being added in 2020. Would make testing and creating new base VMs (with some initial configuration) so much more convenient.

Happy birthday! Unraid has really improved over the years and awesome features just keep coming and coming. Keep up the good work!

Postgres 11 has some breaking changes apparently. Made a not-so-smart move to configure this to latest tag. I'll fix this to PostgreSQL 10 and create another template for Postgres 10.

It shows all the Docker volumes, that you can usually see with "docker volume list". By default these get mounted to /var/lib/docker/volumes/[volume id]/_data and are used by the container internally. More on Docker volumes.

Application: Docker Registry @ https://github.com/docker/distribution-library-image DockerHub: https://registry.hub.docker.com/_/registry/ GitHub: https://github.com/juusujanar/unraid-templates/blob/master/DockerRegistry.xml This template uses the official Docker Registry image to quickly set up your own private repository for storing Docker images. If you have any issues/questions/suggestions regarding this Docker or the template, feel free to contact here.

Application: Portainer @ https://portainer.io/ DockerHub:https://hub.docker.com/r/portainer/portainer/ GitHub: https://github.com/juusujanar/unraid-templates/blob/master/Portainer.xml This template uses the official Portainer Docker image to quickly set up a Portainer instance. It is used for graphical Docker management and gives more information than unRAID itself. If you have any issues/questions/suggestions regarding this Docker or the template, feel free to contact here.

Application: Redis @ https://redis.io/ DockerHub: https://hub.docker.com/_/redis/ GitHub: https://github.com/juusujanar/unraid-templates/blob/master/Redis.xml This template uses the official Redis Docker image to quickly set up a Redis cache instance according to your configuration. If you have any issues/questions/suggestions regarding this Docker or the template, feel free to contact here.