Auto-configuration based on environment variables does not work #593

pasikarkkainen · 2018-12-30T11:11:52Z

It seems auto-configuration using environment variables does not work when using docker image "nextcloud:15.0.0-apache".

docker-compose.yml:

version: "2"

services:

  nextcloud:
    image: nextcloud:15.0.0-apache
    container_name: nextcloud
    expose:
      - "80"
    links:
      - mariadb
    depends_on:
      - mariadb
    volumes:
      - "./data:/var/www/html:z"
    environment:
      - MYSQL_HOST=mariadb
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASS=secretpassword
      - NEXTCLOUD_ADMIN_USER=ncadmin
      - NEXTCLOUD_ADMIN_PASSWORD=supersecretpassword
    restart: always

Results in the first-time wizard having empty admin user/password, sqlite as the chosen database, and when one chooses mysql the mysql infos aren't filled in. So for some reason all those environment variables are ignored by the first-time wizard.

If I start a bash shell in the container, I can see the environment variables there just fine.

The text was updated successfully, but these errors were encountered:

chrisallenlane · 2019-01-05T18:07:02Z

I am encountering the same issue.

J0WI · 2019-01-11T16:15:14Z

I'm not able to reproduce this

literally-dan · 2019-01-19T22:02:52Z

I'm having the same issue using the example docker container configuration (tried both docker-compose/with-nginx-proxy/mariadb/fpm and docker-compose/with-nginx-proxy/postgres/fpm)

EDIT:
Figured out what my issue is, it's a case of RTFM...
When switching between mariadb and postgres, the environment variables for database name are:
MYSQL_DATABASE and POSTGRES_DB, so a :%s/MYSQL/POSTGRES/g didn't work.

J0WI · 2019-02-21T08:08:33Z

I used the example in #593 (comment)

dve · 2019-02-22T09:44:03Z

I got the same problem, but only on an existing installation. Copy & Pasting the nextcloud parts into a new docker-compose file and starting it works like a charme...

SnowMB · 2019-02-23T00:51:44Z

Auto configuration will not overwrite settings if you already have an existing installation. If you are migrating or already have installed nextcloud, you have to edit the config file manually by attaching to the container or copying additional files into the container/volume.

SnowMB · 2019-02-25T17:58:08Z

normally docker-compose down -v should be enough (-v ensures that the created volumes get deleted)

Can you please post your docker-compose file?

SnowMB · 2019-02-25T20:13:20Z

You forgot the MySQL info for nextcloud to automatically configure the database connection. That's why the setup page is coming up. You need to add the following variables:

... 
  - MYSQL_HOST=mariadb
  - MYSQL_PASSWORD=pass  
  - MYSQL_DATABASE=nextcloud
  - MYSQL_USER=nextcloud

SnowMB · 2019-03-03T14:22:06Z

Are you sure you started a fresh install? Remove the created volumes with docker-compose down -v

dve · 2019-03-04T08:35:30Z

Auto configuration will not overwrite settings if you already have an existing installation.

Ok, thanks for clarification - if restored my files and it works again

Unrud · 2019-08-19T00:44:35Z

I think the problem is caused by a race condition.
The first start of MariaDB takes a long time (~2 minutes in my case).
The setup script in the nextcloud docker image only tries a limited number of times to run the install command (for ~30 seconds):

docker/16.0/apache/entrypoint.sh

Line 104 in 2acb1df

    
           until run_as "php /var/www/html/occ maintenance:install $install_options" || [ "$try" -gt "$max_retries" ]

antonio-antuan · 2019-11-01T22:13:38Z

the same problem with postgres:

➜  nextcloud cat docker-compose.yml 
version: '3.3'

services:
  db:
    image: postgres:12.0-alpine
    restart: unless-stopped
    volumes:
      - ./db:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: nextcloud

  app:
    image: nextcloud:15.0.12-apache
    ports:
      - 7180:80
    links:
      - db
    volumes:
      - ./nextcloud:/var/www/html
    restart: always
    depends_on:
      - db
    environment:
      NEXTCLOUD_ADMIN_USER: admin
      NEXTCLOUD_ADMIN_PASSWORD: admin
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: nextcloud
      POSTGRES_HOST: db:5432

➜  nextcloud docker-compose up -d db      
Creating nextcloud_db_1 ... 
Creating nextcloud_db_1 ... done
➜  nextcloud docker-compose logs db 
Attaching to nextcloud_db_1
db_1   | 2019-11-01 22:05:02.091 UTC [1] LOG:  starting PostgreSQL 12.0 on x86_64-pc-linux-musl, compiled by gcc (Alpine 8.3.0) 8.3.0, 64-bit
db_1   | 2019-11-01 22:05:02.092 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
db_1   | 2019-11-01 22:05:02.092 UTC [1] LOG:  listening on IPv6 address "::", port 5432
db_1   | 2019-11-01 22:05:02.112 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
db_1   | 2019-11-01 22:05:02.172 UTC [18] LOG:  database system was shut down at 2019-11-01 22:04:35 UTC
db_1   | 2019-11-01 22:05:02.194 UTC [1] LOG:  database system is ready to accept connections
➜  nextcloud docker-compose up -d app
nextcloud_db_1 is up-to-date
Creating nextcloud_app_1 ... 
Creating nextcloud_app_1 ... done
➜  nextcloud docker inspect nextcloud_app_1|grep -A 20 Env        
            "Env": [
                "POSTGRES_HOST=db:5432",
                "POSTGRES_USER=nextcloud",
                "NEXTCLOUD_ADMIN_PASSWORD=admin",
                "POSTGRES_PASSWORD=nextcloud",
                "NEXTCLOUD_ADMIN_USER=admin",
                "POSTGRES_DB=nextcloud",
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "PHPIZE_DEPS=autoconf \t\tdpkg-dev \t\tfile \t\tg++ \t\tgcc \t\tlibc-dev \t\tmake \t\tpkg-config \t\tre2c",
                "PHP_INI_DIR=/usr/local/etc/php",
                "APACHE_CONFDIR=/etc/apache2",
                "APACHE_ENVVARS=/etc/apache2/envvars",
                "PHP_EXTRA_BUILD_DEPS=apache2-dev",
                "PHP_EXTRA_CONFIGURE_ARGS=--with-apxs2 --disable-cgi",
                "PHP_CFLAGS=-fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64",
                "PHP_CPPFLAGS=-fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64",
                "PHP_LDFLAGS=-Wl,-O1 -Wl,--hash-style=both -pie",
                "GPG_KEYS=CBAF69F173A0FEA4B537F470D66C9593118BCCB6 F38252826ACD957EF380D39F2F7956BC5DA04B5D",
                "PHP_VERSION=7.3.11",
                "PHP_URL=https://www.php.net/get/php-7.3.11.tar.xz/from/this/mirror",
                "PHP_ASC_URL=https://www.php.net/get/php-7.3.11.tar.xz.asc/from/this/mirror",

On the first URL checking I see "Create an admin account" message.

UPD. when I trying to put admin/admin as login and password on that screen, I got that error:
"SQLSTATE[08006] [7] FATAL: permission denied for database "nextcloud" DETAIL: User does not have CONNECT privilege. "
Then I tried to use postgres:11.5:

  ~ dc logs -f db
Attaching to anton_db_1
...
db_1   | 2019-11-02 08:19:15.358 UTC [1] LOG:  database system is ready to accept connections
^CERROR: Aborting.
➜  ~ dc up -d app
anton_db_1 is up-to-date
Creating anton_app_1 ... done
-%                                                                                                                                                                                                                                                                             ➜  ~ dc logs -f app
Attaching to anton_app_1
app_1  | Initializing nextcloud 15.0.12.1 ...
app_1  | Initializing finished
app_1  | New nextcloud instance
app_1  | Installing with PostgreSQL database
app_1  | starting nextcloud installation
app_1  | Error while trying to create admin user: Failed to connect to the database: An exception occured in driver: SQLSTATE[08006] [7] FATAL:  permission denied for database "nextcloud"
app_1  | DETAIL:  User does not have CONNECT privilege.
app_1  |  -> 
app_1  | retrying install...
app_1  | Error while trying to create admin user: Failed to connect to the database: An exception occured in driver: SQLSTATE[08006] [7] FATAL:  permission denied for database "nextcloud"
app_1  | DETAIL:  User does not have CONNECT privilege.
app_1  |  -> 
app_1  | retrying install...
app_1  | Error while trying to create admin user: Failed to connect to the database: An exception occured in driver: SQLSTATE[08006] [7] FATAL:  permission denied for database "nextcloud"
app_1  | DETAIL:  User does not have CONNECT privilege.
app_1  |  -> 
app_1  | retrying install...
^CERROR: Aborting.
➜  ~ dc exec db psql -U nextcloud
psql (11.5 (Debian 11.5-3.pgdg90+1))
Type "help" for help.

nextcloud=# GRANT CONNECT ON DATABASE nextcloud TO nextcloud;
GRANT
nextcloud=# \q
➜  ~ dc logs -f app              
Attaching to anton_app_1
...
app_1  |  -> 
app_1  | retrying install...
app_1  | Error while trying to create admin user: Failed to connect to the database: An exception occured in driver: SQLSTATE[08006] [7] FATAL:  permission denied for database "nextcloud"
app_1  | DETAIL:  User does not have CONNECT privilege.
app_1  |  -> 
app_1  | retrying install...
app_1  | Error while trying to create admin user: Failed to connect to the database: An exception occured in driver: SQLSTATE[08006] [7] FATAL:  permission denied for database "nextcloud"
app_1  | DETAIL:  User does not have CONNECT privilege.
app_1  |  -> 
app_1  | installing of nextcloud failed!
➜  ~

Feels like nextcloud tries to connect with another user. But:

➜  ~ dc exec db psql -U nextcloud
psql (11.5 (Debian 11.5-3.pgdg90+1))
Type "help" for help.

nextcloud=# \l
                                  List of databases
   Name    |   Owner   | Encoding |  Collate   |   Ctype    |    Access privileges    
-----------+-----------+----------+------------+------------+-------------------------
 nextcloud | nextcloud | UTF8     | en_US.utf8 | en_US.utf8 | nextcloud=CTc/nextcloud
 postgres  | nextcloud | UTF8     | en_US.utf8 | en_US.utf8 | 
 template0 | nextcloud | UTF8     | en_US.utf8 | en_US.utf8 | =c/nextcloud           +
           |           |          |            |            | nextcloud=CTc/nextcloud
 template1 | nextcloud | UTF8     | en_US.utf8 | en_US.utf8 | =c/nextcloud           +
           |           |          |            |            | nextcloud=CTc/nextcloud
(4 rows)

sgreiner · 2019-11-07T00:40:39Z

Autoconfig based on ENV Vars is still broken in v17.
Tested with absolute blank system.

huhudev-git · 2019-11-23T15:22:06Z

same issue in v17, NEXTCLOUD_ADMIN_PASSWORD and NEXTCLOUD_ADMIN_USER not work.

straumer · 2019-12-04T20:18:23Z

Tried with version 16 and 17 and this issue pops up.

Xananax · 2019-12-17T03:30:50Z

Broken for me too. Possible mitigations:

Wait longer, as suggested by @Unrud
Provide a way to trigger installation even if the container runs a second time (that is, allow passing an argument that triggers the install, additionally to the version check)
Remove any mention of the option of passing installation parameters in Readme, or at least mention it's not working right now.

If you've already created your volumes

Mitigation without intervening on the source, for us users consists in removing the faulty Nextcloud volume, and recreating it:

sudo docker volume ls to get the nextcloud volume. It will be called <project_name>_<volume_name> (where project_name is the name of the directory).
sudo docker volume rm project_nextcloud will give you an error with the name of the containers using this volume. Take this list, remove the commas, and paste it below:
sudo docker container rm <id1, id2, id3...>
run sudo docker-compose up again

If you're fresh

If you haven't ever ran docker-compose up, instead of the above, you can let docker-compose create the db volume first.
Assuming your database service is called db, you can run

sudo docker-compose -f docker-compose.yml up db

Let it do its thang, then kill it, and run:;

sudo docker-compose up

Both those solutions work, which confirms it's a racing condition, though I have no idea why.

eblondel · 2019-12-20T16:37:03Z

would be great to have an argument to auto-configure the nextcloud (triggering the install) when running the container.

J0WI · 2020-01-11T00:52:31Z

This is due a performance regression in recent MariaDB releases, see MariaDB/mariadb-docker#262

bhammack · 2020-01-11T16:22:26Z

For anyone that's still struggling with this issue, I was able to come up with a solution in my docker-compose project. The cause of the issue has already been discussed above (mariadb takes ~60 seconds to setup on first launch, whereas nextcloud only performs 10 install attempts. If mariadb doesn't start up before nextcloud, the installation will fail and the parameters won't be applied)...

To resolve it, I mount the wait-for-it script found here https://github.com/vishnubob/wait-for-it into the container, override the entrypoint in my docker-compose file to call the script which then calls the entrypoint when the database container is accepting connections.

volumes:
      - ./configs/nextcloud/wait-for-it.sh:/bin/wait-for-it.sh # make sure this file is marked as executable on the host!
entrypoint: sh -c '/bin/wait-for-it.sh nextcloud-db:3306 --timeout=120 && /entrypoint.sh apache2-foreground'
depends_on:
      - nextcloud-db

eblondel · 2020-01-15T11:11:27Z

Hello, i'm still struggling with this, Is there a way to auto-config a docker nextcloud instance sticking with sqlite (default database)? I tried to configure this instance through Travis CI yaml file here https://github.com/eblondel/ocs4R/blob/master/.travis.yml#L52 Thanks

choma · 2020-02-19T17:00:16Z

#963 didn't solve this, MariaDB is still taking too much time to start in some cases. And, since the related MariaDB issue is still open, maybe this issue should be reopen too so people can see workarounds.

By now, I guess the best option is to use wait-for-it, as suggested by @bhammack .

eblondel · 2020-02-19T17:07:45Z

Thanks, I've finally resolved my issue, and to me it works well, including with a SQLITE database.

Aetherus · 2020-10-10T11:01:45Z

When installing with PostgreSQL/MySQL/MariaDB, nextcloud tries to use "oc_${NEXTCLOUD_ADMIN_USER}" as the database user, whether it's configured using environment variable or created on the webpage after installation.

jakkso · 2020-11-23T20:57:23Z

Values set in docker-compose.yml are still being ignored and auto configuration does not work. I ran the db container separately prior to running all containers, as suggested by #593, which did not fix the problem.
Additionally, after setting NEXTCLOUD_TRUSTED_DOMAINS=mydomain in nextcloud's environment section of docker-compose, I'm still greeted by the untrusted domain error message. I remoted into a running container and was able to see that while docker is passing NEXTCLOUD_TRUSTED_DOMAINS correctly, config.php doesn't contain the domain.

piperubio · 2020-11-23T23:37:46Z

Values set in docker-compose.yml are still being ignored and auto configuration does not work. I ran the db container separately prior to running all containers, as suggested by #593, which did not fix the problem.
Additionally, after setting NEXTCLOUD_TRUSTED_DOMAINS=mydomain in nextcloud's environment section of docker-compose, I'm still greeted by the untrusted domain error message. I remoted into a running container and was able to see that while docker is passing NEXTCLOUD_TRUSTED_DOMAINS correctly, config.php doesn't contain the domain.

@jakkso I have the same issue here! Apparently it is a problem with the new release of the latest image, since a few days ago the environment variables were working normally

jakkso · 2020-11-24T19:44:11Z

@krouw and anyone else having this problem: as a stopgap solution I copied config.php onto the host drive, mounted it as a volume, and hardcoded the needed values into it. If anyone else goes this route, be sure to adjust the permissions on config.php. I'm not a fan of hardcoding values, but I really just needed to get it running.

TheFlow0360 · 2021-02-08T09:08:33Z

any news here? I went and chose to use docker because it's "nice and clean", and now I have to integrate hacks like the wait-for-it script? I don't really get why this isn't fixed yet (or broken again), anyone running a real docker compose setup will run into this problem.

EDIT: Now i tried the wait-for-it, and it didn't work - the db container taking too long doesn't seem to be the problem. The logs don't really show any problem, either...


The files belonging to this database system will be owned by user "postgres".,
This user must also own the server process.,
,
The database cluster will be initialized with locale "en_US.utf8".,
The default database encoding has accordingly been set to "UTF8".,
The default text search configuration will be set to "english".,
,
Data page checksums are disabled.,
,
fixing permissions on existing directory /var/lib/postgresql/data ... ok,
creating subdirectories ... ok,
selecting dynamic shared memory implementation ... posix,
selecting default max_connections ... 100,
selecting default shared_buffers ... 128MB,
selecting default time zone ... Etc/UTC,
creating configuration files ... ok,
running bootstrap script ... ok,
performing post-bootstrap initialization ... ok,
syncing data to disk ... ok,
,
,
Success. You can now start the database server using:,
,
    pg_ctl -D /var/lib/postgresql/data -l logfile start,
,
initdb: warning: enabling "trust" authentication for local connections,
You can change this by editing pg_hba.conf or using the option -A, or,
--auth-local and --auth-host, the next time you run initdb.,
waiting for server to start....2021-02-08 09:42:39.179 UTC [48] LOG:  starting PostgreSQL 13.1 (Debian 13.1-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit,
2021-02-08 09:42:39.183 UTC [48] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432",
2021-02-08 09:42:39.198 UTC [49] LOG:  database system was shut down at 2021-02-08 09:42:38 UTC,
2021-02-08 09:42:39.207 UTC [48] LOG:  database system is ready to accept connections,
 done,
server started,
CREATE DATABASE,
,
,
/usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*,
,
2021-02-08 09:42:39.431 UTC [48] LOG:  received fast shutdown request,
waiting for server to shut down....2021-02-08 09:42:39.435 UTC [48] LOG:  aborting any active transactions,
2021-02-08 09:42:39.438 UTC [48] LOG:  background worker "logical replication launcher" (PID 55) exited with exit code 1,
2021-02-08 09:42:39.439 UTC [50] LOG:  shutting down,
2021-02-08 09:42:39.472 UTC [48] LOG:  database system is shut down,
 done,
server stopped,
,
PostgreSQL init process complete; ready for start up.,
,
2021-02-08 09:42:39.591 UTC [1] LOG:  starting PostgreSQL 13.1 (Debian 13.1-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit,
2021-02-08 09:42:39.591 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432,
2021-02-08 09:42:39.591 UTC [1] LOG:  listening on IPv6 address "::", port 5432,
2021-02-08 09:42:39.600 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432",
2021-02-08 09:42:39.612 UTC [76] LOG:  database system was shut down at 2021-02-08 09:42:39 UTC,
2021-02-08 09:42:39.623 UTC [1] LOG:  database system is ready to accept connections,

wait-for-it.sh: waiting 120 seconds for db:5432,
wait-for-it.sh: db:5432 is available after 0 seconds,
Conf remoteip disabled.,
To activate the new configuration, you need to run:,
  service apache2 reload,
Initializing nextcloud 20.0.6.1 ...,
Initializing finished,
New nextcloud instance,
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.0.2.239. Set the 'ServerName' directive globally to suppress this message,
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.0.2.239. Set the 'ServerName' directive globally to suppress this message,
[Mon Feb 08 09:42:41.695768 2021] [mpm_prefork:notice] [pid 19] AH00163: Apache/2.4.38 (Debian) PHP/7.4.15 configured -- resuming normal operations,
[Mon Feb 08 09:42:41.695797 2021] [core:notice] [pid 19] AH00094: Command line: 'apache2 -D FOREGROUND',

mr-karan · 2021-02-13T07:33:45Z

Unsure why the issue is closed when so many of us are reporting that this issue still persists.

ryjelsum · 2021-02-15T03:16:58Z

Unsure why the issue is closed when so many of us are reporting that this issue still persists.

(EDIT: FIXED, SEE BELOW!)
I've gotta second this. I've been having this issue for a number of days - cannot get the trusted domain environment variable to pass, from what I can tell looking at what I've done, no matter what I try. I can provide some more concrete details about my setup if someone asks, but I am new to Docker and am trying to use this as a trial run to understand it, so I'm kind of fumbling around in the dark here, so unfortunately I cannot be a greater help unless someone points me to some specific issues that could be causing this. Whether it's something broken in the provided containers or some poorly documented behavior, it needs to be fixed in some way.
(EDIT: FIXED, SEE BELOW)

For anyone who comes across this thread for the same reasons I did: The issue that I was having not getting TRUSTED_DOMAINS env variable to pass through was related to this issue. I did not realize that both the db container and the nextcloud container, confusingly, have MYSQL_PASSWORD/DATABASE/USER environmental variables as it is not really stated in the documentation which environmental variables go with the nextcloud container and which go with the mariadb container. This is partially because the readme page linked from the hub.docker.com page is not the proper, fully updated one - this is linked as opposed to the readme.md from this repository., which contains a small modification to a pertinent section - see the issue linked above, an edit to the readme.md was made as a result.

Is this something I should open an issue for, or is this not the proper place to do it considering that the issue is more related to the hub.docker.com page?

giomf · 2021-05-25T19:27:22Z

I have similar problems.
I am trying to connect a postgres database.
All ENV variables are set correctly except dbuser and dbpassword. The dbuser is always oc_admin. The password looks generated. I don't understand why the other variables are taken over correctly.
EDIT: i found some related thread to my problem https://help.nextcloud.com/t/postgres-as-database-backend-with-nextcloud-on-docker-doesnt-work/37722 Unfortunately without solution

wcdgit · 2022-03-12T22:27:51Z

I had the exact same behaviour as the the OP. I solved the problem by setting the environment variables
NEXTCLOUD_ADMIN_USER and NEXTCLOUD_ADMIN_PASSWORD. Without them there was no way to get the DB info to auto configure.

clayrisser · 2022-12-22T20:39:55Z

@Giom-fm I'm facing the same issue. Did you ever figure this out?

abraxaswd · 2023-02-24T08:57:27Z

This still does not work with postgresql and nextcloud 25. After configuring all ENV-vars and starting the container. There are errors as the installer tries to use the admin user of the install script. Furthermore it is not possible to use hyphens in admin user names.
With mysql it works perfectly smooth....

giomf · 2023-02-24T09:52:47Z

@clayrisser Sorry for the delay.
Unfortunately, I still do not have a solution. To be honest, I don't even try anymore. This is such a basic feature and is not taken into account by the devs.

Jannik44 · 2023-12-24T10:57:17Z

Hello, same issue here, but with an already existing mariadb database, i verified that the database works and configured 'nextcloud' ad the database user in the cdocker compose file but in the logs i still see it using oc_admin, this is weird, and also cant get past the first run configuration page because it always says my db username or password is wrong, why is that still an issue after a so long time?

joshtrichards · 2024-01-16T00:11:25Z

This Issue is a hodgepodge of loads of different situations. Many of these are unrelated. Some have since been fixed. There have also been numerous documentation revisions.

The original report was also already addressed so I'm closing this issue. But not without some awareness there are possibly some legitimate bug reports in here.

Unfortunately it's impossible to isolate each of the remaining situations without a full bug report from each person because similar symptoms do not always equal the same underlying cause. I'm going to re-close this, but feel free to open individual issues if you think there is bug in the image that you are experiencing today.

To head off a few things, here's a quick summary of a few things off the top of my head I see above that weren't already addressed or seem worthy of re-mentioning:

most of the auto-config variables are ineffective after you've installed/ran the image once against a given container's volume because the Nextcloud installer will not be re-triggered. The Compose file/environment variables are designed for deployment not ongoing configuration changes
the oc_admin behavior is an upstream matter in Server. There may be some inconsistencies in how it's handled with PG vs MySQL/MariaDB - I dunno; But that's not a matter the image can solve. All the image does is pass along things to the Nextcloud installer which handles the actual db user creation. I do know I'm able to make both MariaDB and PG deployments from scratch, fully via Docker Compose, using any reasonably recent image here (take that for what it's worth: a sample size of one)
the other matters where some combinations of variables work and others don't - either post on the Help Forums or create a dedicated issue for your situation if you think it's an actual image bug. I think one more relevant issue was already mentioned so there also already may be existing issues covering some of those
let's try to keep each Issue focused on one matter

J0WI added the question label Jan 11, 2019

J0WI changed the title ~~Auto-configuration based on environment variables does not work (15.0.0)~~ Auto-configuration based on environment variables does not work Nov 7, 2019

eblondel mentioned this issue Nov 28, 2019

Make integration tests work with nextcloud eblondel/ocs4R#2

Closed

This was referenced Jan 13, 2020

Change sleep time from 3s to 10s in all entrypoint.sh files #835

Closed

Change sleep time from 3s to 10s in all entrypoint.sh files #963

Merged

J0WI closed this as completed in #963 Jan 13, 2020

jacksgt mentioned this issue Apr 29, 2023

dbpassword value doesn't match sealed secret nextcloud/helm#364

Open

tmo1 mentioned this issue Jan 7, 2024

Auto configuration via environment variables not working correctly #2139

Closed

joshtrichards reopened this Jan 8, 2024

joshtrichards added the feature: auto config (environment variables) Auto configuring via environment variables label Jan 15, 2024

joshtrichards closed this as completed Jan 16, 2024

Auto-configuration based on environment variables does not work #593

Auto-configuration based on environment variables does not work #593

Comments

pasikarkkainen commented Dec 30, 2018 • edited Loading

chrisallenlane commented Jan 5, 2019

J0WI commented Jan 11, 2019

literally-dan commented Jan 19, 2019 • edited Loading

J0WI commented Feb 21, 2019

dve commented Feb 22, 2019

SnowMB commented Feb 23, 2019

SnowMB commented Feb 25, 2019

SnowMB commented Feb 25, 2019

SnowMB commented Mar 3, 2019 • edited Loading

dve commented Mar 4, 2019

Unrud commented Aug 19, 2019

antonio-antuan commented Nov 1, 2019 • edited Loading

sgreiner commented Nov 7, 2019

huhudev-git commented Nov 23, 2019

straumer commented Dec 4, 2019

Xananax commented Dec 17, 2019

If you've already created your volumes

If you're fresh

eblondel commented Dec 20, 2019

J0WI commented Jan 11, 2020

bhammack commented Jan 11, 2020 • edited Loading

eblondel commented Jan 15, 2020

choma commented Feb 19, 2020

eblondel commented Feb 19, 2020

Aetherus commented Oct 10, 2020

jakkso commented Nov 23, 2020

piperubio commented Nov 23, 2020 • edited Loading

jakkso commented Nov 24, 2020

TheFlow0360 commented Feb 8, 2021 • edited Loading

mr-karan commented Feb 13, 2021

ryjelsum commented Feb 15, 2021 • edited Loading

giomf commented May 25, 2021 • edited Loading

wcdgit commented Mar 12, 2022

clayrisser commented Dec 22, 2022

abraxaswd commented Feb 24, 2023

giomf commented Feb 24, 2023

Jannik44 commented Dec 24, 2023

joshtrichards commented Jan 16, 2024

pasikarkkainen commented Dec 30, 2018 •

edited

Loading

literally-dan commented Jan 19, 2019 •

edited

Loading

SnowMB commented Mar 3, 2019 •

edited

Loading

antonio-antuan commented Nov 1, 2019 •

edited

Loading

bhammack commented Jan 11, 2020 •

edited

Loading

piperubio commented Nov 23, 2020 •

edited

Loading

TheFlow0360 commented Feb 8, 2021 •

edited

Loading

ryjelsum commented Feb 15, 2021 •

edited

Loading

giomf commented May 25, 2021 •

edited

Loading