Persistent password desynchronization between Nextcloud and PostgreSQL on TrueNAS SCALE – authentication errors

ℹ️ Support
, , , ,
1
Support intro

Sorry to hear you’re facing problems. :slightly_frowning_face:

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

Hello everyone,

First of all, thank you for taking the time to read this. Any help or insight is greatly appreciated – we are genuinely stuck and eager to learn a proper solution for our home setup.

We have been working on integrating Nextcloud with LocalAI and Context Chat via AppAPI, and hit a persistent database authentication issue that blocks further progress.

The Basics

    1. Nextcloud Server version: 33.0.2
    2. Operating system and version: TrueNAS SCALE 25.10.3 (Linux 6.12.33, Debian bookworm based)
    3. Web server and version: Apache 2.4.66 (inside the Nextcloud container)
    4. Reverse proxy and version: Cloudflare
    5. PHP version: 8.4.19
    6. Is this the first time you’ve seen this error?: No, it has recurred after snapshot rollbacks
    7. When did this problem seem to first start?: After a TrueNAS snapshot rollback was performed
    8. Installation method: TrueNAS SCALE App (Docker)
    9. Are you using Cloudflare, mod_security, or similar?: Yes, Cloudflare

Summary of the issue you are facing:

Nextcloud returns error 500 with “FATAL: password authentication failed for user oc_administrador”, even though the password in config.php matches the value in the TrueNAS GUI’s “Database Password” field. Manual ALTER USER inside the PostgreSQL container temporarily fixes the issue, but it reappears after container restart.

Steps to replicate it (hint: details matter!):

  1. Perform a TrueNAS snapshot rollback of the Nextcloud app volumes.

  2. Start (or restart) the Nextcloud app from the TrueNAS GUI.

  3. Observe that Nextcloud logs show password authentication failures for oc_administrador.

  4. Manually reset the password inside the PostgreSQL container using ALTER USER.

  5. Verify successful connection with PGPASSWORD.

  6. Restart the Nextcloud container again – the error sometimes returns.

Log entries

Nextcloud

[Thu Apr 30 14:18:38.943815 2026] [php:error] [pid 634:tid 634] [client 172.16.8.1:47070] PHP Fatal error:  Uncaught Doctrine\\DBAL\\Exception: Failed to connect to the database: An exception occurred in the driver: SQLSTATE[08006] [7] connection to server at "postgres" (172.16.8.6), port 5432 failed: FATAL:  password authentication failed for user "oc_administrador" in /var/www/html/lib/private/DB/Connection.php:238

PostgreSQL log:

2026-04-30 13:00:29.459 -03 [74] FATAL: password authentication failed for user "oc_administrador"
2026-04-30 13:00:29.459 -03 [74] DETAIL: Connection matched file "/var/lib/postgresql/18/docker/pg_hba.conf" line 99: "host all all all md5"

Web Browser

If the problem is related to the Web interface, open your browser inspector Console and Network tabs while refreshing (reloading) and reproducing the problem. Provide any relevant output/errors here that appear.

PASTE

Web server / Reverse Proxy

The output of your Apache/nginx/system log in /var/log/____:

PASTE HERE

Configuration

Nextcloud

Nextcloud (config.php excerpt):

'dbtype' => 'pgsql',
'dbname' => 'nextcloud',
'dbhost' => 'postgres:5432',
'dbport' => '',
'dbtableprefix' => 'oc_',
'dbuser' => 'oc_administrador',
'dbpassword' => 'PASSWORD',

PostgreSQL container pg_hba.conf (relevant line):

host all all all md5

What we have already tried:

  1. Reset the password using ALTER USER:

    bash

    sudo docker exec -it ix-nextcloud-postgres-1 psql -U nextcloud -d nextcloud -c "ALTER USER oc_administrador WITH PASSWORD 'SENHADBNOVA';"

    Returns ALTER ROLE.

  2. Verified the new password:

    bash

    sudo docker exec -e PGPASSWORD='SENHADBNOVA' ix-nextcloud-postgres-1 psql -U oc_administrador -d nextcloud -c "SELECT 1;"

    Returns 1 (success).

  3. Temporarily modified pg_hba.conf to trust for local connections, performed the password change, and restored the file.

  4. Replaced the trusted_domains array in config.php after discovering it had been corrupted with error-log fragments.

Despite these steps, the error sometimes reappears after container restarts.

Hypothesis:

Is there a startup script inside the PostgreSQL container (e.g., under /docker-entrypoint-initdb.d/) that recreates the oc_administrador role with an old password on every container start?

Questions:

  • How can we make the password change permanent and immune to container restarts?

  • Is there any environment variable or TrueNAS App setting that might be forcing the original password?

  • Any other debugging suggestions are very welcome.

Thank you very much in advance for your time and expertise. We truly appreciate any guidance you can provide

2

I don’t have any true answers, but perhaps some context will help you get things sorted.

The TrueNAS Nextcloud “app” is sort of a wrapper around the Nextcloud micro-services image as well as some other images (like PosgreSQL), which is used to build a full stack.

In general the underlying Nextcloud image:

  • Uses the POSTGRES* environment variable for it’s configuration.

  • The PosgreSQL image uses similar variables

The TrueNAS “app” / stack template takes the answers/field values you enter and pushes them out the appropriate places, such as populating those environment variables.

The source code for the app is here:

I’m unclear from your report when you say “restart” whether you’re literally just referring to the Nextcloud container or if you’re always referring to the “app” and if so… I suppose the entire stack.

If restarting just the Nextcloud container (that is, not restarting the PosgreSQL container) triggers this, that would be one thing… But I get the sense this is being triggered when you either restart the whole stack or, at the very least, your PosgreSQL container.

EDIT: Make sure you’re using occ config:list system on the Nextcloud side to see your real merged config. Looking just at config.php, particularly on the Docker images, is not sufficient to see your real config. In your case you may also need to add the --private parameter to see actual passwords.

3

Hi JTR,

Thank you so much for your guidance – pointing us to occ config:list system --private and the environment variables was the key to unlock the whole situation.

After extensive testing, we discovered that the root cause was a DNS resolution conflict between two PostgreSQL containers on the same Docker network (ix-internal-nextcloud-nextcloud-net).

  • The Nextcloud app (TrueNAS SCALE) ships its own PostgreSQL container (ix-nextcloud-postgres-1) which gets the alias postgres.

  • We had separately installed a second PostgreSQL container (ix-postgres-postgres-1) which also got the alias postgres when connecting it to the same network.

  • As a result, getent hosts postgres returned two IPs, and the Nextcloud container sometimes resolved postgres to the wrong database instance, which did not contain the role oc_administrador with the expected password. That caused intermittent FATAL: password authentication failed errors.

Additionally, a startup script inside the Nextcloud container (/docker-entrypoint-hooks.d/before-starting/ix-update-hosts-script.sh) was rewriting config.php using the environment variables POSTGRES_* injected by the TrueNAS App template. This overwrote our manual password changes and occasionally changed the dbuser field, making the problem even more elusive.

What solved the issue permanently:

  1. Removed the alias postgres from the external PostgreSQL container and kept it only on the internal one:

    bash

    sudo docker network disconnect ix-internal-nextcloud-nextcloud-net ix-postgres-postgres-1
sudo docker network connect --alias ix-postgres-externo ix-internal-nextcloud-nextcloud-net ix-postgres-postgres-1

  2. Verified that getent hosts postgres now returns a single IP (the internal container).

  3. Aligned the password inside the internal PostgreSQL container using ALTER USER oc_administrador WITH PASSWORD '...'.

  4. Disabled the offending startup script to prevent it from overwriting config.php on subsequent restarts:

    bash

    sudo docker exec ix-nextcloud-nextcloud-1 mv /docker-entrypoint-hooks.d/before-starting/ix-update-hosts-script.sh /docker-entrypoint-hooks.d/before-starting/ix-update-hosts-script.sh.disabled

  5. Manually edited config.php to ensure dbuser is oc_administrador, dbpassword matches the database, and the trusted_domains array is correct.

  6. Restarted the Nextcloud container and confirmed everything with occ config:list system --private, direct psql connection tests, and monitoring logs.

Now the environment is stable, occ config:list system --private works without errors, and no more authentication failures appear in the logs.

Your hint about the real merged config and the environment variables was truly the turning point. Many thanks again for your time and help!

Best regards.