Nextcloud Docker Compose: eigene Cloud in vier Containern

Im offiziellen Compose-Beispiel für das Nextcloud-Image stehen zwei Zeilen, die mit einem Gleichheitszeichen enden und dann nichts mehr: MYSQL_ROOT_PASSWORD= und MYSQL_PASSWORD=. Das ist kein Fehler, das ist eine Einladung. Die Entwickler haben alles hingeschrieben, was ein Heimnetz braucht, und die zwei Stellen freigelassen, an denen nur du etwas eintragen kannst. Vier Dienste, zwei Passwörter, ein Port. Mehr ist eine eigene Cloud im Kern nicht.

Nextcloud ist die Software, die aus einem Rechner im Schrank einen Ersatz für Google Drive, Dropbox und den Kalender bei Apple macht: Dateien, die auf allen Geräten gleich sind, Kalender und Kontakte, Freigaben per Link, alles unter deinem Dach. Version 35 ist seit dem 15-09-2026 final, und seit ein paar Tagen liefert auch das offizielle Docker-Image sie aus. Was in 35 neu ist, steht in einem eigenen Beitrag. Hier geht es darum, sie zum Laufen zu bringen, mit einer Datei, die du in einem Jahr noch verstehst.

Vier Container, und was jeder tut

Nextcloud ist eine PHP-Anwendung, und eine PHP-Anwendung kann alleine nichts speichern. Sie braucht eine Datenbank, in der steht, welche Datei wem gehört, wer was freigegeben hat und wann der Kalender klingeln soll. Die Dateien selbst liegen daneben ganz normal auf der Platte. Dazu kommen zwei Helfer, die man weglassen könnte und deren Fehlen Nextcloud dir dann jeden Tag auf der Übersichtsseite vorhält.

MariaDB ist die Datenbank. Nextcloud 35 unterstützt laut Systemanforderungen MariaDB 10.11, 11.4, 11.8 und 12.3, empfohlen ist 12.3, und genau das steckt hinter dem Docker-Tag lts, den das offizielle Beispiel benutzt. Redis ist ein Zwischenspeicher im Arbeitsspeicher. Nextcloud legt dort zwei Dinge ab: Antworten, die es sonst jedes Mal neu aus der Datenbank holen müsste, und die Sperren, die verhindern, dass zwei Geräte gleichzeitig dieselbe Datei beschreiben. Ohne Redis geht beides über die Datenbank, langsamer und mit einer Warnung im Admin-Bereich. Der Cron-Helfer ist derselbe Nextcloud-Container noch einmal, nur mit einem anderen Startbefehl: Statt Apache läuft darin ein kleiner Zeitplaner, der alle fünf Minuten cron.php aufruft. Das sind die Hintergrundaufgaben, also Vorschaubilder rechnen, Papierkorb leeren, Aktivitäten verschicken. Die Nextcloud-Doku nennt diesen Weg ausdrücklich den bevorzugten; die Alternative, bei der jeder Seitenaufruf nebenbei eine Aufgabe erledigt, ist die Voreinstellung und funktioniert nur, solange ständig jemand die Seite offen hat.

Und warum nicht Nextcloud AIO, das Paket, das alles auf einmal installiert? Weil AIO für eine Nextcloud im Internet gebaut ist: Es will laut seiner Doku eine Domain, die Ports 80 und 443 am Router und richtet dann selbst Zertifikate ein. Für den Rechner im Heimnetz, der über eine IP-Adresse erreichbar ist, ist das der falsche Werkzeugkasten. Der Weg hier ist der aus dem offiziellen Image, mit einer Compose-Datei, in der du jede Zeile kennst. Wer später eine Domain und HTTPS will, setzt einen Reverse Proxy davor; das steht am Ende.

Was du brauchst

• Einen Linux-Rechner mit Docker und Docker Compose v2. Die Images gibt es für amd64 und arm64; ein Raspberry Pi 4 mit 4 GB reicht für den Anfang. Wer Docker noch nicht hat: Bei Paperless-ngx steht der Weg.
• Arbeitsspeicher: Nextcloud empfiehlt 512 MB pro PHP-Prozess. Mit Datenbank und Redis daneben würde ich 2 GB als untere Kante für den ganzen Rechner ansetzen; das ist meine Faustregel, keine Zahl aus der Doku.
• Platz für die Dateien, auf dem Rechner selbst oder auf einer dort eingehängten Platte.
• Port 8080 frei.
• Zwei lange Passwörter für die Datenbank und eines für dein Admin-Konto, am besten aus dem Passwort-Manager, weil du sie gleich in eine Datei tippst und nie wieder brauchst.

Die prüfbaren Punkte klärst du auf dem Server. Zuerst Docker:

docker --version
docker compose version

Beide Zeilen liefern eine Versionsnummer. Kennt dein Rechner nur docker-compose mit Bindestrich, ist das die alte Version 1; die Anleitung setzt v2 voraus.

Dann Speicher und Port:

free -h | grep Mem
sudo ss -tulpn | grep ':8080 ' || echo "Port 8080 ist frei"

Mem:           4.0Gi        78Mi       3.6Gi       136Ki       365Mi       3.9Gi
Port 8080 ist frei

Die erste Zeile zeigt in der ersten Zahl den Arbeitsspeicher insgesamt, in der dritten, was davon frei ist. Steht bei der zweiten statt der Meldung eine Zeile mit einem Programmnamen, sitzt dort schon jemand; dann nimmst du unten in der Compose-Datei einen anderen Port, etwa 8081.

Alle Befehle rechnen mit denselben Beispielwerten. Wo sie unten auftauchen, setzt du deine ein:

Schritt 1: Ordner anlegen

Alles, was Nextcloud schreibt, kommt in Unterordner neben der Compose-Datei: nextcloud für den Programmcode, die Konfiguration und die Apps, data für deine Dateien, db für die Datenbank. Die Doku des Images erlaubt beides, Docker-Volumes oder Ordner auf dem Rechner. Ich nehme Ordner, weil ein Backup dann ein Ordner ist, den du sehen kannst, und kein Volume irgendwo unter /var/lib/docker.

mkdir -p ~/nextcloud/nextcloud ~/nextcloud/data ~/nextcloud/db
cd ~/nextcloud
ls

data  db  nextcloud

Die drei Ordner gehören jetzt dir. Das ändert der erste Start gleich: Nextcloud läuft im Container als Benutzer www-data mit der Kennung 33, und das Startskript des Images übergibt ihm beim Kopieren die Ordner nextcloud und data. Die Datenbank macht es mit db genauso. Wundere dich also nicht, wenn ls -ln später eine 33 und eine 999 zeigt, wo eben noch deine 1000 stand.

Schritt 2: Die Compose-Datei

Grundlage ist das Compose-Beispiel aus dem Nextcloud-Docker-Repository, Variante MariaDB mit Apache, samt Cron-Container. Ich habe die Passwörter aus der ausgelagerten db.env direkt in die Datei geholt, die Volumes durch die Ordner aus Schritt 1 ersetzt und das Image auf die Hauptversion festgenagelt. Was jede Zeile tut, steht unter der Datei. Die zwei Passwörter ersetzt du vor dem Speichern, das Datenbank-Passwort steht zweimal drin und muss beide Male gleich sein.

nano compose.yaml

services:
  db:
    image: mariadb:lts
    restart: always
    command: --transaction-isolation=READ-COMMITTED
    volumes:
      - ./db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=root-passwort-aendern
      - MYSQL_PASSWORD=db-passwort-aendern
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MARIADB_AUTO_UPGRADE=1
      - MARIADB_DISABLE_UPGRADE_BACKUP=1

  redis:
    image: redis:alpine
    restart: always

  app:
    image: nextcloud:35-apache
    restart: always
    ports:
      - 8080:80
    depends_on:
      - db
      - redis
    volumes:
      - ./nextcloud:/var/www/html
      - ./data:/var/www/html/data
    environment:
      - MYSQL_HOST=db
      - MYSQL_PASSWORD=db-passwort-aendern
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - REDIS_HOST=redis

  cron:
    image: nextcloud:35-apache
    restart: always
    depends_on:
      - db
      - redis
    volumes:
      - ./nextcloud:/var/www/html
      - ./data:/var/www/html/data
    entrypoint: /cron.sh

docker compose config --quiet && echo OK

OK

Kommt eine Fehlermeldung mit Zeilennummer statt OK, ist an dieser Stelle fast immer ein Leerzeichen zu viel oder zu wenig; YAML zählt die Einrückung.

image: mariadb:lts und command: --transaction-isolation=READ-COMMITTED Beides aus dem offiziellen Beispiel. Der Tag lts zeigt heute auf MariaDB 12.3, die Version, die Nextcloud 35 empfiehlt. Die Option dahinter ist keine Feinheit: Die Nextcloud-Doku verlangt diese Isolationsstufe, um Datenverlust zu vermeiden, wenn viele Geräte gleichzeitig synchronisieren. MARIADB_AUTO_UPGRADE lässt die Datenbank nach einem Image-Update ihre Systemtabellen selbst anpassen, und die zweite Variable verzichtet auf die Sicherungskopie, die MariaDB dabei sonst anlegt; auch das steht so im Beispiel. Das Root-Passwort brauchst du nach der Installation nie wieder, es muss nur gesetzt sein.

image: redis:alpine Ein Container ohne eine einzige Einstellung. Nextcloud findet ihn über REDIS_HOST=redis, und das Image trägt Redis dann von selbst als Zwischenspeicher und für die Dateisperren ein; den schnellen lokalen Cache APCu bringt es ohnehin mit.

image: nextcloud:35-apache Das offizielle Image mit eingebautem Apache, festgenagelt auf die Hauptversion. Der Tag 35-apache bekommt alle 35.x-Updates und springt nie von selbst auf 36. Heute zeigen 35-apache, 35, apache und latest auf dasselbe Image, das steht so in der Tag-Liste. Der Unterschied kommt in einem halben Jahr: Nextcloud erlaubt laut Image-Doku nur einen Hauptversionssprung auf einmal, und latest würde ihn dir bei einem beiläufigen pull unterschieben. So einen Sprung will man bewusst machen, nach einem Backup.

ports: 8080:80 Innen lauscht Apache auf 80, außen erreichst du ihn auf 8080. Das Beispiel im Repository bindet den Port an 127.0.0.1, damit nur der Rechner selbst ihn sieht; das ist für den Fall gedacht, dass ein Reverse Proxy davor steht. Hier soll dein Laptop im Heimnetz die Seite erreichen, also ohne Adresse davor.

volumes Links der Ordner auf deinem Rechner, rechts, wie der Container ihn sieht. /var/www/html ist laut Image-Doku der Hauptordner, den Nextcloud fürs Updaten braucht; /var/www/html/data darin sind deine Dateien. Der zweite Eintrag ist eigentlich schon im ersten enthalten. Ich ziehe ihn trotzdem einzeln heraus, weil der Datenordner der ist, der wächst, und du ihn so später auf eine andere Platte legen kannst, ohne den Rest anzufassen. Die Doku merkt an, dass app und cron exakt dieselben Volumes haben müssen, deshalb stehen die zwei Zeilen unten noch einmal.

MYSQL_HOST=db und die drei Zeilen danach sind die Zugangsdaten, die das Image beim ersten Start in eine Autoconfig-Datei schreibt. Der Installationsassistent findet sie dort und füllt die Datenbankfelder vor. Du tippst im Browser also nur noch dein Admin-Konto.

entrypoint: /cron.sh Dasselbe Image, ein anderer Startbefehl. cron.sh startet laut Quelltext nur den Zeitplaner von BusyBox, und im Image steht der Eintrag */5 * * * * php -f /var/www/html/cron.php für den Benutzer www-data. Alle fünf Minuten, so wie es die Nextcloud-Doku empfiehlt.

Schritt 3: Starten und zusehen

docker compose up -d

Beim ersten Mal lädt Docker drei Images; an einer normalen Leitung ist das in ein, zwei Minuten erledigt. Danach passiert etwas, das man sehen sollte: Das Startskript kopiert die komplette Nextcloud aus dem Image in deinen Ordner nextcloud. Das dauert je nach Platte eine halbe bis eine Minute, und solange antwortet der Port noch nicht. Zusehen kannst du im Log:

docker compose logs -f app

app-1  | Initializing nextcloud 35.0.0.8 ...
app-1  | New nextcloud instance
app-1  | Next step: Access your instance to finish the web-based installation!
app-1  | Initializing finished

Die vier Zeilen stehen so im Startskript des Images; die Nummer hinter nextcloud ist die interne Versionsnummer und darf bei dir anders enden. New nextcloud instance heißt: Das Skript hat einen leeren Ordner gefunden und Nextcloud hineingelegt. Der Satz mit Next step ist die Ansage, dass der Rest im Browser passiert. Mit Strg+C verlässt du das Log, der Container läuft weiter. Dann der Blick auf alle vier:

docker compose ps

Vier Zeilen, in der Spalte STATUS viermal Up. Fehlt eine Zeile oder steht dort Restarting, ist unten bei „Wo es klemmt“ der erste Absatz dein Freund. Sind es vier, hat der Rechner gerade eine Datenbank angelegt, einen Zwischenspeicher gestartet und eine komplette Cloud in deinen Ordner kopiert. Das darf man kurz würdigen, bevor man weiterklickt.

Schritt 4: Der Assistent im Browser

Nextcloud hat keinen sechsseitigen Assistenten, sondern eine einzige Seite. Sie fragt nach dem Admin-Konto, zeigt darunter zusammengeklappt Speicher und Datenbank, und weil das Image die Datenbank schon eingetragen hat, ist der zweite Teil nur noch ein Blick zur Kontrolle.

Die Installation läuft eine halbe Minute, dann fragt Nextcloud, ob es die empfohlenen Apps installieren soll: Kalender, Kontakte, Mail, Talk und ein Office. Ich würde hier Überspringen wählen und die Apps später einzeln aus dem App-Store holen, wenn du weißt, welche du brauchst. Jede App ist Code, der mit deinen Daten arbeitet und mit jedem Update mitgezogen werden will; ein Talk-Server, den niemand benutzt, ist nur eine Warnung mehr im Log.

Diese Übersicht ist die Erfolgskontrolle für alles bisher, und sie ist die ehrlichste Seite in Nextcloud: Sie zählt auf, was noch nicht stimmt. Bei einer frischen Installation nach dieser Anleitung bleiben typischerweise zwei Punkte stehen, die Telefonregion und das Wartungsfenster. Direkt nach der Installation stehen darüber hinaus noch ein roter Hinweis zu HTTPS-Zugriff und URLs, einer zu HTTP-Headern (HSTS), einer zu verfügbaren MIME-Type-Migrationen und einer zur Datenbankkonfiguration mit fehlgeschlagenen Prüfungen. Beides klären wir jetzt. Fehlt dagegen jede Warnung zum Speicher-Cache, hat Redis seinen Job schon angetreten.

Was am Ende eingestellt ist

Nextcloud läuft, du bist drin. Fünf Dinge würde ich jetzt noch klären, bevor die ersten Fotos hochgeladen werden.

1. Die Hintergrundaufgaben laufen über Cron. Der Cron-Container ruft cron.php alle fünf Minuten auf, und die Nextcloud-Doku sagt, dass genau das den Modus von selbst auf Cron stellt. Nachsehen kostet einen Klick:

2. Telefonregion und Wartungsfenster. Die beiden Warnungen von der Übersicht. Die Telefonregion braucht Nextcloud, um Telefonnummern ohne Ländervorwahl in Profilen zu verstehen; für Deutschland ist das DE. Das Wartungsfenster ist eine Stunde in UTC, ab der Nextcloud vier Stunden lang die Aufgaben erledigt, die nicht eilig sind, etwa Datenbankpflege. Der Wert 1 heißt ein Uhr UTC, also drei Uhr nachts bei uns im Sommer, zwei im Winter. Beides setzt du mit occ, dem Kommandozeilenwerkzeug von Nextcloud, das im Container als www-data laufen muss:

docker compose exec --user www-data app php occ config:system:set default_phone_region --value="DE"
docker compose exec --user www-data app php occ config:system:set maintenance_window_start --type=integer --value=1

System config value default_phone_region set to string DE
System config value maintenance_window_start set to integer 1

Danach die Übersicht im Browser neu laden: Die beiden Punkte sind weg. Der zweite Befehl steht wörtlich so in der Nextcloud-Doku zu den Hintergrundaufgaben, der erste folgt demselben Muster.

3. Das Upload-Limit ist 512 MB. So ist die Vorgabe des Images, über PHP_UPLOAD_LIMIT. Für Dokumente und Fotos reicht das, für ein Video vom Handy nicht. Willst du mehr, kommt unter environment des app-Containers eine Zeile - PHP_UPLOAD_LIMIT=4G dazu, dann docker compose up -d, und Compose baut nur diesen einen Container neu. Die Apps auf dem Handy und der Desktop-Client teilen große Dateien ohnehin in Stücke; das Limit gilt für den Upload im Browser.

4. Nur im Heimnetz, und per HTTP. Port 8080 spricht unverschlüsselt, und die Adresse aus dem Assistenten ist die einzige, die Nextcloud als vertrauenswürdig kennt. Im Router gibt es keine Weiterleitung dafür, und so bleibt es. Wer von unterwegs an seine Dateien will, braucht ein VPN oder einen Reverse Proxy mit HTTPS davor; der Nginx Proxy Manager ist dafür der Einstieg. Für Nextcloud gehören dann drei Zeilen in die Compose-Datei: TRUSTED_PROXIES mit der Adresse des Proxys, OVERWRITEPROTOCOL=https und OVERWRITEHOST mit deiner Domain. Alle drei stehen in der Image-Doku, und das ist ein eigener Beitrag.

5. Updates und Backup. Nextcloud aktualisiert sich im Container nicht selbst; die Image-Doku beschreibt den Weg so: neues Image ziehen, alten Container wegwerfen, neuen starten. In Compose sind das zwei Befehle:

cd ~/nextcloud
docker compose pull && docker compose up -d

Das Startskript erkennt die neue Version und führt das Upgrade selbst durch; im Log steht dann Upgrading nextcloud from …. Der Tag 35-apache sorgt dafür, dass das nur innerhalb von 35 passiert. Steht eines Tages die 36 an, änderst du den Tag von Hand, und zwar nach einem Backup. Das Backup laut Nextcloud-Doku besteht aus dem Config-Ordner, dem Datenordner, den Apps und einem Auszug der Datenbank. Die ersten drei liegen bei dir unter ~/nextcloud/nextcloud und ~/nextcloud/data. Den Datenbank-Auszug erzeugt MariaDB selbst:

docker compose exec db mariadb-dump --single-transaction -u nextcloud -p"db-passwort-aendern" nextcloud > ~/nextcloud-db-$(date +%F).sql
ls -lh ~/nextcloud-db-*.sql

Die Datei ist ein paar Megabyte groß und enthält alles, was Nextcloud über deine Dateien weiß, nicht die Dateien selbst. Die Doku empfiehlt, vor einem Backup den Wartungsmodus einzuschalten, damit niemand währenddessen schreibt; für eine Cloud mit einem Benutzer nachts um drei ist das verzichtbar, für eine Familie nicht. Ja, das ist wieder der Backup-Absatz. Er steht in jeder Anleitung hier, und bei einer Cloud, in die du gleich deine Fotos schiebst, steht er zu Recht.

Wo es klemmt

Der Container app startet immer wieder neu, und im Log steht „Cannot write into config directory“. Der Klassiker in den Issues des Nextcloud-Docker-Repositories, mit den Nummern #544 und #1158 gleich zweimal unter demselben Titel: Der Ordner gehört jemandem, dem Nextcloud nicht hineinschreiben darf. Das passiert, wenn du die Ordner als root angelegt oder später von Hand hineinkopiert hast. Nachsehen und beheben:

docker compose logs --tail 30 app
sudo chown -R 33:33 ~/nextcloud/nextcloud ~/nextcloud/data
docker compose restart app cron

33 ist die Kennung von www-data im Image; bei den Alpine-Varianten wäre es 82, aber die benutzen wir nicht.

Im Browser steht „Zugriff über eine nicht vertrauenswürdige Domain“. Du hast Nextcloud unter einer anderen Adresse aufgerufen als der, mit der du den Assistenten bedient hast, etwa per Hostname statt IP. Nextcloud trägt bei der Installation genau die eine Adresse aus dem Assistenten ein, das steht so im Quelltext der Setup-Klasse. Jede weitere kommt per occ dazu, mit einer laufenden Nummer:

docker compose exec --user www-data app php occ config:system:set trusted_domains 1 --value="homelab.fritz.box"

Im Log steht „Retrying install...“ oder „Installing of nextcloud failed!“. Das Datenbank-Passwort steht in der Compose-Datei zweimal, und die beiden Stellen sind verschieden. Oder MariaDB war beim ersten Anlauf noch nicht fertig; das Startskript versucht es dann laut Quelltext zehnmal im Abstand von zehn Sekunden, bevor es aufgibt. Passwörter vergleichen, und wenn die Datenbank schon einmal mit dem falschen Passwort angelegt wurde, hilft nur der saubere Neustart: docker compose down, den Ordner db leeren, docker compose up -d. Vor der Installation ist darin nichts, was du vermissen würdest.

Der Port antwortet erst nach einer Minute. Kein Fehler, siehe Schritt 3: Der erste Start kopiert Nextcloud in deinen Ordner, und bis Initializing finished im Log steht, ist die Seite nicht da. Auf einem Raspberry Pi mit SD-Karte kann das auch zwei Minuten dauern.

Vier Container, eine Datei, zwei Passwörter, ein Admin-Konto. Was mir an diesem Weg gefällt: Es gibt keinen Installer, der dir etwas hinstellt, was du nicht bestellt hast. Jede Zeile in der Compose-Datei hat einen Satz in der Doku, und wenn in einem Jahr etwas hakt, weißt du, wo du suchen musst. Das ist der Unterschied zwischen einer Cloud, die du benutzt, und einer, die du betreibst.

Welche App kommt bei dir als Erstes in die frische Nextcloud, Kalender, Fotos oder gleich der Desktop-Client für den Dokumentenordner? Schreib's in die Kommentare, gern mit dem Rechner, auf dem sie läuft.

Und wenn du wissen willst, was in dieser 35 eigentlich drinsteckt: Der Beitrag zum Nextcloud-35-Release geht die Neuerungen durch, samt der Frage, ob sich das Warten auf 35.0.1 lohnt.

Quellen

• Nextcloud Docker: README (Compose-Beispiel mit mariadb:lts und READ-COMMITTED, Autoconfig per MYSQL_*, REDIS_HOST, PHP_UPLOAD_LIMIT 512M, TRUSTED_PROXIES und OVERWRITE*, Update nur eine Hauptversion auf einmal, occ per docker compose exec --user www-data, Volume oder Host-Ordner)
• Nextcloud Docker: Beispiel insecure/mariadb/apache (db, redis, app, cron mit entrypoint /cron.sh, MARIADB_AUTO_UPGRADE, gleiche Volumes für app und cron)
• Nextcloud Docker: Beispiele (insecure nur fürs lokale Netz, HTTPS Pflicht bei Erreichbarkeit aus dem Internet)
• Nextcloud Docker: Startskript (rsync mit chown www-data, „New nextcloud instance“, „Retrying install...“ zehnmal, „Initializing finished“, Upgrade-Meldung)
• Nextcloud Docker: Dockerfile 35/apache (php:8.5-apache, Crontab */5 für www-data)
• Nextcloud Docker: cron.sh (busybox crond)
• Nextcloud Docker: autoconfig.php (Datenbankwerte aus MYSQL_*, Datenverzeichnis)
• Docker Official Images: Tags nextcloud (35.0.0-apache, 35-apache, apache, 35, latest identisch)
• Docker Official Images: Tags mariadb (lts = 12.3)
• Docker Hub: mariadb (MARIADB_AUTO_UPGRADE, MARIADB_DISABLE_UPGRADE_BACKUP)
• Nextcloud-Doku: Systemanforderungen 35 (MariaDB 10.11/11.4/11.8/12.3, PHP 8.5, 512 MB pro Prozess)
• Nextcloud-Doku: Datenbank (READ COMMITTED gegen Datenverlust unter Last)
• Nextcloud-Doku: Hintergrundaufgaben (AJAX Voreinstellung, Cron bevorzugt, alle 5 Minuten, Modus wird automatisch gesetzt, maintenance_window_start per occ)
• Nextcloud-Doku: Caching (APCu lokal, Redis für verteilten Cache und Dateisperren)
• Nextcloud-Doku: config.php-Parameter (default_phone_region, maintenance_window_start in UTC, trusted_domains, overwrite.cli.url)
• Nextcloud-Doku: Installationsassistent (Admin-Konto, Speicher & Datenbank, SQLite nur für Tests, trusted domains)
• Nextcloud-Doku: Backup (config, data, apps, Datenbank; mysqldump --single-transaction; Wartungsmodus)
• Nextcloud Server: Setup.php (trusted_domains bei der Installation aus dem aufgerufenen Host)
• Nextcloud Server: deutsche Oberflächentexte des Assistenten (Administrationskonto erstellen, Autoconfig-Datei erkannt, Speicher & Datenbank, Empfohlene Apps, Zugriff über eine nicht vertrauenswürdige Domain)
• Nextcloud Server: deutsche Texte der Einstellungen (Administrationseinstellungen, Übersicht, Grundeinstellungen, Hintergrundaufgaben, Cron (Empfohlen))
• Nextcloud AIO: README (Domain und Ports 80/443 erforderlich)
• Nextcloud Docker: Issues #544 und #1158, „Cannot write into config directory“