Nextcloud 33 im Docker auf Synology: „Configuration was not read or initialized correctly, not overwriting config.php“

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).

Hallo zusammen

ich kämpfe seit Stunden mit einem Nextcloud‑Problem auf meiner Synology‑NAS (Docker) und hoffe, dass hier jemand mit mehr Nextcloud‑Know‑how als ich einen entscheidenden Hinweis hat.

Umgebung

Synology NAS mit DSM 7, Docker / Container Manager

Nextcloud als Docker‑Container
Image: nextcloud:latest

Container‑Name: nextcloud-MBM

Port: Host 8889 → Container 80 (Direktzugriff im LAN: http://192.168.178.22:8889)

Reverse Proxy: nginx‑proxy‑manager (eigener Container npm), extern erreichbar z.B. über http://91.x.x.x:8080

Datenbank: SQLite (keine separate DB, alles im Container)
Ausgangslage / Update

Nextcloud lief vorher, Update wurde über das Webinterface angestoßen und ist hängen geblieben.

Danach kam nur noch die Meldung „Aktualisierung erforderlich“.

Ich habe das Update dann per CLI im Docker‑Container nachgezogen.
Aktueller Nextcloud‑Status (CLI)
Auf der Synology als root:
bash
docker exec -u 1026 -it nextcloud-MBM php /var/www/html/occ status

Ausgabe:
text

  • installed: true
  • version: 33.0.2.2
  • versionstring: 33.0.2
  • edition:
  • maintenance: false
  • needsDbUpgrade: false
  • productname: Nextcloud
  • extendedSupport: false

Das Upgrade lief vorher mit:
bash
docker exec -u 1026 -it nextcloud-MBM php /var/www/html/occ upgrade

und endete mit „Update successful“, „Turned off maintenance mode“, „Resetting log level“.
Besonderheit: User‑ID 1026

Wenn ich occ ohne -u 1026 ausführe, kommt:
text
Console has to be executed with the user that owns the file config/config.php
Current user id: 0 (oder 33)
Owner id of config.php: 1026

Daher führe ich alle occ‑Befehle mit -u 1026 aus, damit passt es.
Daten und Rechte
SQLite‑DB und Daten:
bash
docker exec -it nextcloud-MBM bash
cd /var/www/html/data
ls -l

ergibt u.a.:
text
-rw-r–r-- 1 www-data www-data 16482304 Apr 8 13:00 owncloud.db

Die Rechte auf data wurden angepasst auf:
bash
chown -R 1026:1026 /var/www/html/data
chmod 770 /var/www/html/data

occ status funktioniert damit wie oben gezeigt ohne DB‑Fehler.
config.php
Datei liegt im Container unter /var/www/html/config/config.php.
Besitzer/Rechte:
bash
cd /var/www/html/config
ls -l config.php*

Ausgabe:
text
-rw-r----- 1 1026 1026 1535 Apr 8 13:50 config.php
-rw------- 1 1026 1026 1535 Apr 8 13:59 config.php.bak

Auszug aus config.php (Passwörter/Secrets anonymisiert):
php

<?php $CONFIG = array ( 'htaccess.RewriteBase' => '/', 'apps_paths' => array ( 0 => array ( 'path' => '/var/www/html/apps', 'url' => '/apps', 'writable' => false, ), 1 => array ( 'path' => '/var/www/html/custom_apps', 'url' => '/custom_apps', 'writable' => true, ), ), 'upgrade.disable-web' => true, 'instanceid' => '****', 'passwordsalt' => '****', 'secret' => '****', 'trusted_domains' => array ( 0 => 'localhost', 1 => '192.168.178.22', 2 => '100.103.62.89', 3 => '91.x.x.x', ), 'overwrite.cli.url' => 'http://91.x.x.x:8080', 'overwritehost' => '91.x.x.x', 'overwriteport' => '8080', 'trusted_proxies' => array ( 0 => '172.19.0.0/16', 1 => '172.17.0.0/16', ), 'forwarded_for_headers' => array ( 0 => 'HTTP_X_FORWARDED_FOR', 1 => 'HTTP_X_FORWARDED_PROTO', 2 => 'HTTP_X_FORWARDED_HOST', ), 'datadirectory' => '/var/www/html/data', 'dbtype' => 'sqlite3', 'version' => '33.0.2.2', 'installed' => true, 'session' => array ( 'save_handler' => 'files', 'save_path' => '/tmp/', ), 'php_memory_limit' => '1G', 'memcache.local' => '\\OC\\Memcache\\APCu', 'sharing.enable_public_links' => true, 'allow_public_uploads' => false, 'public_share_expiry_date' => 'never', 'allow_local_remote_servers' => true, 'loglevel' => 2, 'maintenance' => false, 'config_is_read_only' => true, ); Symptom im Browser Aufruf im LAN: http://192.168.178.22:8889 Ergebnis (Fehlerseite): Fehler Configuration was not read or initialized correctly, not overwriting /var/www/html/config/config.php Gleiches Bild über den Reverse Proxy. Laut Doku scheint das eine Schutzmaßnahme zu sein, damit config.php nicht überschrieben wird, wenn die Konfiguration nicht „sauber initialisiert“ ist – aber ich finde nicht heraus, warum Nextcloud das in meinem Fall annimmt, obwohl occ status sauber ist und die Datei lesbar ist. Was ich mir von euch erhoffe Idee, welche interne Prüfung diese Fehlermeldung auslöst (Code‑Stelle / Bedingung). Hinweise, ob das in NC 33.0.2 mit Docker/angepasster UID 1026 ein bekannter Bug ist. Konkreten Vorschlag, welche Rechte / Owner / zusätzliche Option in config.php korrekt gesetzt sein müssen, damit diese Meldung verschwindet. Falls jemand eine funktionierende NC‑33‑Docker‑Installation auf Synology mit angepasster UID/GID hat: Beispiel‑Config bzw. docker‑run / docker‑compose Ausschnitt wäre Gold wert. Backups von data (inkl. owncloud.db) und config habe ich inzwischen erstellt, ich kann also auch einen gezielten Schritt testen, solange ich die Daten nicht verliere. Vielen Dank schon mal fürs Draufschauen – im Moment bin ich mit meinem Latein am Ende. Viele Grüße Manfred

Hallo,
ich würde mich sehr über ein konkretes Docker‑/Synology‑Beispiel freuen. Mein ursprünglicher Post oben enthält alle Details.

Ich würde in dem Fall dir raten ein Rollback zu machen bevor du halt das Upgrade ausgeführt hast!.

Ich gehe mal davon aus das du sowas hast ansonsten halt ein Backup zurückspielen bevor du das Upgrade aufgespielt hast weil wenn während des Upgrade das ganze hängen geblieben ist ist davon auszugehen das einiges noch fehlt.

Ich kann nur von meinem Truenas reden weil ich keine Synalogy habe dort ist aber so das beim meinen Apps die möglichkeit besteht ein Rollback zu machen z.b von der Version 33.0.2 auf 33.0.0 so das dann wieder alles so ist als es noch gut funktionierte ich denke mal sowas sollte es bei Dir eigentlich auch geben. Ansonsten halt Restore machen vom Backup das sollte man sowie immer haben bevor man ein Upgrade durchführt.

Viele Grüsse