Was bauen wir?

Am Ende zeigt die Sicherheits- & Einrichtungsübersicht deiner Nextcloud keine Warnungen mehr. Konkret bauen wir auf der Installation aus Teil 1 auf und ergänzen: den fehlenden HSTS-Sicherheitsheader über Traefik, ein konfiguriertes Wartungsfenster, den funktionierenden E-Mail-Versand (für Passwort-Resets und Benachrichtigungen), eine erzwungene Zwei-Faktor-Authentifizierung und einen Brute-Force-Schutz, der die echten Angreifer-IPs sieht – die Grundlage für Fail2ban.

Getestet ist alles gegen Nextcloud 34.0.1 hinter Traefik v3.7 auf Debian 13 mit PHP 8.5. Das ist Fleißarbeit, aber genau die Fleißarbeit, die in 90 % aller Nextcloud-Anleitungen fehlt – und die den Unterschied zwischen „irgendwie online" und „vernünftig betrieben" ausmacht.

Voraussetzungen

• Eine laufende Nextcloud wie in Nextcloud selbst hosten (Teil 1) aufgesetzt: klassisches nextcloud-Image hinter Traefik, mit MariaDB, Redis und Cron-Sidecar. Die Container-Namen aus Teil 1 (nc-app, nc-db, nc-redis, nc-cron) und der Compose-Ordner ~/nextcloud sind hier die Basis.
• SSH-Zugriff auf den Server und das Kommandozeilen-Werkzeug occ – wir rufen es wie in Teil 1 im App-Container auf: docker exec -u www-data nc-app php occ <befehl>.
• Ein Traefik-Reverse-Proxy mit dem proxy-Netz und dem Resolver le wie im Tutorial Reverse Proxy mit Traefik – die Sicherheits-Header hängen wir als Traefik-Middleware an.

docker exec -u www-data nc-app php occ status

Schritt für Schritt

Schritt 1: Die Admin-Übersicht als Bestandsaufnahme lesen

Melde dich als Administrator an und öffne Administrationseinstellungen → Übersicht. Oben steht der Abschnitt „Sicherheits- & Einrichtungswarnungen". Direkt nach einer Standardinstallation sieht das so aus:

Nextcloud unterscheidet drei Stufen: gelbe Warnungen (⚠, solltest du beheben), blaue Hinweise (ℹ, meist optional) und stillschweigend bestandene Prüfungen. Bei unserer frischen Instanz stehen drei Warnungen und ein paar Hinweise an:

• ⚠ Beginn des Wartungsfensters ist nicht gesetzt (Schritt 2)
• ⚠ MIME-Type-Migrationen verfügbar (Schritt 2)
• ⚠ HTTP-Header – der Strict-Transport-Security-Header fehlt (Schritt 3)
• ℹ E-Mail-Test – noch kein Mailserver hinterlegt (Schritt 4)
• ℹ Zwei-Faktor-Konfiguration – 2FA ist verfügbar, aber nicht verpflichtend (Schritt 5)

Denselben Bericht bekommst du auch auf der Kommandozeile – praktisch, um den Fortschritt zwischendurch zu prüfen, ohne durch die Weboberfläche zu klicken:

docker exec -u www-data nc-app php occ setupchecks

Der Befehl gibt jede Prüfung mit ✓, ⚠ oder ✗ aus. Genau diese Liste arbeiten wir jetzt von oben nach unten ab.

Schritt 2: Die zwei schnellen Warnungen beheben

Zwei Warnungen sind mit je einem Befehl erledigt.

Wartungsfenster festlegen. Nextcloud führt einmal täglich rechenintensive Aufräumjobs aus (Vorschauen, Aktivitäten, Kalender-Wiederholungen). Ohne definiertes Zeitfenster laufen die irgendwann – auch mitten am Tag. Leg einen Startzeitpunkt fest, zu dem kaum jemand arbeitet. Der Wert ist eine volle Stunde in UTC; 1 legt den Beginn auf 01:00 UTC – der Check meldet danach das Fenster von 1:00 bis 7:00 UTC:

docker exec -u www-data nc-app php occ config:system:set maintenance_window_start --type=integer --value=1

Zur Kontrolle bestätigt der Setup-Check danach:

✓ Maintenance window start: Maintenance window to execute heavy background jobs is between 1:00 UTC and 7:00 UTC

MIME-Type-Migrationen ausführen. Gelegentlich lernt Nextcloud neue Dateitypen (etwa für bessere Icons und Vorschauen). Diese Migration läuft bei Updates nicht automatisch, weil sie auf großen Instanzen dauern kann. Auf einer frischen Cloud ist sie in Sekunden durch:

docker exec -u www-data nc-app php occ maintenance:repair --include-expensive

Du siehst eine Liste abgearbeiteter Reparaturschritte (u. a. Repair mime types). Danach meldet der Check Mimetype migrations available: None. Zwei Warnungen weniger.

Schritt 3: Den HSTS-Sicherheitsheader über Traefik setzen

Die dritte Warnung ist die wichtigste: Der Strict-Transport-Security-Header (HSTS) fehlt. Er weist den Browser an, diese Domain ausschließlich über HTTPS anzusprechen – auch dann, wenn jemand http:// eintippt oder ein Angreifer die Verbindung umzubiegen versucht. Ohne HSTS bleibt ein kleines Zeitfenster für Downgrade-Angriffe offen.

Weil unsere Nextcloud hinter Traefik sitzt, setzen wir den Header im Proxy, nicht in Nextcloud – dort gehört er hin, denn Traefik terminiert das TLS. Ergänze in der compose.yaml deiner Nextcloud (aus Teil 1) die Middleware nc-secure und häng sie an den Router. Konkret ändern sich zwei Stellen im labels-Block von nc-app.

Erstens die Router-Zeile um nc-secure erweitern:

      - "traefik.http.routers.nc.middlewares=nc-dav,nc-secure"

Zweitens die Header-Middleware definieren (direkt bei den anderen nc-app-Labels):

      - "traefik.http.middlewares.nc-secure.headers.stsSeconds=15552000"
      - "traefik.http.middlewares.nc-secure.headers.stsIncludeSubdomains=true"

stsSeconds=15552000 sind 180 Tage – der von Nextcloud geforderte Mindestwert. Übernimm die Änderung und lade nur den App-Container neu:

docker compose up -d nc-app

Prüfe nach ein paar Sekunden von deinem eigenen Rechner aus, dass der Header wirklich ausgeliefert wird:

curl -sS -I https://cloud.DEINE_DOMAIN/ | grep -i strict-transport

Du solltest genau das sehen:

strict-transport-security: max-age=15552000; includeSubDomains

In der Admin-Übersicht wird die HTTP-Header-Warnung damit grün: „Your server is correctly configured to send security headers." Die übrigen Header (X-Content-Type-Options, X-Frame-Options, Referrer-Policy …) liefert Nextcloud selbst aus – nur HSTS musste vom Proxy kommen.

Schritt 4: E-Mail-Versand einrichten

Ohne funktionierenden Mailversand kann Nextcloud keine Passwort-Resets verschicken, keine Freigabe-Benachrichtigungen und keine Sicherheitswarnungen – und der Hinweis „E-Mail-Test" bleibt stehen. Das holen wir nach.

Öffne Administrationseinstellungen → Grundeinstellungen und scroll zum Abschnitt „E-Mail-Server". Trag die Zugangsdaten deines Mail-Anbieters ein:

• Sendemodus: SMTP
• Verschlüsselung: SSL/TLS (Port 465) oder STARTTLS (Port 587) – nie unverschlüsselt
• Absenderadresse: z. B. cloud @ DEINE_DOMAIN
• Serveradresse: Host und Port deines Anbieters
• Authentifizierung: einschalten und Benutzername/Passwort hinterlegen

Trag oben unter Persönliche Informationen eine E-Mail-Adresse für dein Admin-Konto ein (dorthin geht die Testmail). Dann klick auf „Test-E-Mail senden". Kommt die Mail an, bestätigt Nextcloud das mit einer grünen Meldung:

Schritt 5: Zwei-Faktor-Authentifizierung erzwingen

Ein gestohlenes Passwort ist der häufigste Weg, wie Konten übernommen werden. Ein zweiter Faktor (ein zeitbasierter Code aus einer Authenticator-App, TOTP) macht das Passwort allein wertlos. Nextcloud bringt den passenden Anbieter schon mit – wir müssen ihn nur aktivieren und zur Pflicht machen.

Aktiviere zunächst die TOTP-App (sie ist im Lieferumfang enthalten):

docker exec -u www-data nc-app php occ app:enable twofactor_totp

Jeder Nutzer richtet seinen zweiten Faktor danach selbst ein – unter Persönliche Einstellungen → Sicherheit → „TOTP (Authenticator-App)". Beim Aktivieren zeigt Nextcloud einen QR-Code, den man mit einer App wie Aegis, andOTP oder Google Authenticator scannt. Zusätzlich empfiehlt sich die App „Zwei-Faktor-Backup-Codes" – die einmaligen Codes retten dich, wenn das Handy verloren geht.

Damit niemand die Absicherung „vergisst", erzwingst du 2FA für die Administratoren. Im Web findest du das unter Administrationseinstellungen → Sicherheit → „Zwei-Faktor- Authentifizierung erzwingen", per Kommandozeile geht es so:

docker exec -u www-data nc-app php occ twofactorauth:enforce --on --group=admin

Schritt 6: Brute-Force-Schutz mit echten IPs – Basis für Fail2ban

Nextcloud drosselt fehlgeschlagene Logins von Haus aus: Nach mehreren Fehlversuchen verzögert es weitere Anfragen derselben IP. Dieser Schutz steht und fällt aber damit, dass Nextcloud die echte Client-IP sieht – und nicht die interne IP von Traefik. Genau das leistet die TRUSTED_PROXIES-Einstellung aus Teil 1.

Ob es funktioniert, siehst du unter Administrationseinstellungen → Sicherheit im Kasten „Brute-Force-Zulassungsliste" (im Screenshot oben). Dort steht deine aktuelle, korrekt erkannte öffentliche IP:

Ihre aktuelle IP-Adresse wird als "DEINE_IP" erkannt. Diese Adresse wird derzeit nicht gedrosselt.

Steht da stattdessen eine 172.x.x.x-Adresse aus dem Docker-Netz, greift TRUSTED_PROXIES nicht – dann würde der Brute-Force-Schutz alle Nutzer über einen Kamm scheren und im Zweifel Traefik selbst sperren. In dem Fall zurück zu Teil 1, Schritt 2/3.

Harte Sperren mit Fail2ban. Die eingebaute Drosselung verzögert nur; wer Angreifer richtig aussperren will, kombiniert Nextcloud mit Fail2ban. Nextcloud protokolliert jeden Fehlversuch im JSON-Log – und dank TRUSTED_PROXIES mit der echten IP:

{"level":2,"time":"2026-07-18T08:14:05+00:00","remoteAddr":"203.0.113.47","user":"--","app":"no app in context","method":"POST","url":"/login","message":"Login failed: BENUTZER (Remote IP: 203.0.113.47)"}

Dieses Log liegt im Nextcloud-Volume. Den Pfad auf dem Host findest du so:

docker inspect -f '{{ range .Mounts }}{{ if eq .Destination "/var/www/html" }}{{ .Source }}{{ end }}{{ end }}' nc-app

Darunter liegt die Datei data/nextcloud.log. Auf die zeigst du einen Fail2ban-Filter, der auf remoteAddr matcht, plus ein Jail nach dem Muster aus dem Fail2ban-Tutorial. So wandert nach ein paar Fehlversuchen die Angreifer-IP direkt in die Firewall – bevor die Anfrage Nextcloud überhaupt erreicht.

Schritt 7: Caching & PHP prüfen – das Performance-Fundament

Zum Schluss vergewissern wir uns, dass die Performance-Basis steht. Vieles davon hat Teil 1 über die REDIS_HOST-Variable schon automatisch eingerichtet – prüfen schadet trotzdem nicht, denn genau hier wird eine Nextcloud zäh oder flott.

Nextcloud nutzt drei Cache-Rollen. Kontrolliere alle drei:

docker exec -u www-data nc-app php occ config:system:get memcache.local
docker exec -u www-data nc-app php occ config:system:get memcache.distributed
docker exec -u www-data nc-app php occ config:system:get memcache.locking

Erwartet:

\OC\Memcache\APCu
\OC\Memcache\Redis
\OC\Memcache\Redis

• Lokaler Cache (APCu): hält häufig genutzte Daten im RAM des PHP-Prozesses – der spürbarste Beschleuniger im Alltag.
• Verteilter Cache (Redis): teilt Cache-Daten über Prozesse hinweg, wichtig sobald App- und Cron-Container zusammenspielen.
• File-Locking (Redis): verhindert, dass zwei Zugriffe dieselbe Datei gleichzeitig verändern und sie beschädigen. Der Grund, warum wir in Teil 1 überhaupt Redis eingebaut haben.

Passt das Zusammenspiel, meldet docker exec -u www-data nc-app php occ setupchecks die Zeile ✓ Memcache: Configured. (Bestandene Prüfungen zeigt die Web-Übersicht nicht an – dort tauchen nur Warnungen und Hinweise auf, deshalb kontrollierst du das hier per CLI.)

OPcache – der Bytecode-Cache von PHP – ist im offiziellen nextcloud-Image bereits sinnvoll vorkonfiguriert (u. a. opcache.interned_strings_buffer=32). Du musst hier also nichts nachziehen; die früher berüchtigte OPcache-Warnung taucht mit aktuellen Images gar nicht mehr auf. Nachschauen kannst du bei Bedarf so:

docker exec -u www-data nc-app php -i | grep opcache.interned_strings_buffer

Damit ist die Übersicht warnungsfrei:

Wenn es nicht funktioniert

Symptom: Nach dem Traefik-Neustart erscheint der HSTS-Header nicht in der curl-Ausgabe.

Ursache & Lösung: Meist ist die Middleware nicht am Router. Prüfe, dass die Zeile traefik.http.routers.nc.middlewares beide Middlewares nennt (nc-dav,nc-secure) und dass die drei nc-secure-Header-Labels im nc-app-Block stehen. Danach docker compose up -d nc-app. Traefik übernimmt geänderte Labels erst beim Neu-Erstellen des Containers.

Symptom: Der E-Mail-Test schlägt fehl („Es gab ein Problem beim Senden der E-Mail").

Ursache & Lösung: Fast immer Port/Verschlüsselung oder Authentifizierung. Kombiniere SSL/TLS mit Port 465 oder STARTTLS mit Port 587 – nicht kreuzweise. Nutzt dein Anbieter 2FA, brauchst du ein App-Passwort (siehe Schritt 4). Details stehen im Nextcloud-Log: docker exec -u www-data nc-app php occ log:tail 20.

Symptom: Du kommst nach dem Erzwingen von 2FA selbst nicht mehr rein.

Ursache & Lösung: Du hattest noch keinen zweiten Faktor eingerichtet. Hebe die Pflicht per Kommandozeile auf, richte deinen Faktor in Ruhe ein und schalte sie danach wieder scharf: docker exec -u www-data nc-app php occ twofactorauth:enforce --off.

Symptom: Im Brute-Force-Kasten steht eine 172.x.x.x-Adresse statt deiner echten IP.

Ursache & Lösung: TRUSTED_PROXIES passt nicht zum tatsächlichen proxy-Subnetz. Ermittle es mit docker network inspect proxy -f '{{(index .IPAM.Config 0).Subnet}}' und trag den Wert in der nc-app-Umgebung ein (Teil 1, Schritt 2). Sonst sperrt der Brute-Force-Schutz im Ernstfall den Proxy und damit alle Nutzer.

Symptom: Nach einem Reboot meldet Nextcloud „Redis went away" oder wird sehr langsam.

Ursache & Lösung: Der App-Container ist vor Redis gestartet. Stelle sicher, dass nc-redis in depends_on steht (Teil 1) und mit restart: unless-stopped läuft – dann fängt Docker den Startreihenfolge-Fall selbst ab.

Wartung & Backups

• Übersicht nach jedem Update prüfen. Neue Nextcloud-Versionen bringen neue Checks mit. Wirf nach jedem Upgrade einen Blick auf Administrationseinstellungen → Übersicht oder lass occ setupchecks laufen – so fängst du neue Warnungen früh ab.
• Regelmäßig den offiziellen Security-Scan nutzen. Der Nextcloud Security Scan prüft deine Domain von außen und vergibt eine Note. Mit HSTS und aktuellen Versionen ist A/A+ das realistische Ziel; fällt die Note, ist meist ein Update überfällig.
• Zweite Faktoren im Blick behalten. Bewahre die Backup-Codes getrennt vom Handy auf. Verliert ein Nutzer sein Gerät, entfernst du seinen Faktor mit occ twofactorauth:disable BENUTZER totp, danach richtet er ihn neu ein.
• App-Passwörter aufräumen. Jeder verbundene Client (Desktop, Handy) bekommt ein eigenes App-Passwort. Unter Persönliche Einstellungen → Sicherheit siehst du alle Geräte und kannst einzelne bei Verlust gezielt widerrufen.
• Die Absicherung ersetzt kein Backup. All das schützt vor fremdem Zugriff, nicht vor Datenverlust. Die konsistente Sicherung aus Datenbank-Dump und Datenverzeichnis bleibt Pflicht – siehe den Wartungsabschnitt in Teil 1 und Backups mit Restic. Ehrlich zum Aufwand: Plane den monatlichen Update-Durchgang mit einem kurzen Blick auf die Übersicht fest ein – dann bleibt deine Cloud dauerhaft grün.

Was bauen wir?

Am Ende läuft Nextcloud 34 hinter deinem Traefik-Proxy, erreichbar unter https://cloud.DEINE_DOMAIN mit gültigem Let’s-Encrypt-Zertifikat. Nextcloud ist deine private Cloud: Dateien synchronisieren (wie bei Dropbox), Kalender und Kontakte über alle Geräte, Fotos, Notizen, Office-Dokumente. Du verbindest den offiziellen Desktop-Sync-Client und die Handy-Apps mit deinem Server – die Daten liegen dabei ausschließlich bei dir.

Wir setzen bewusst auf das klassische nextcloud-Image (nicht auf „Nextcloud All-in-One") plus MariaDB als Datenbank und Redis fürs Caching und File-Locking. Diese Kombination ist stabil, gut dokumentiert und passt exakt in das Traefik-Muster aus der Serverküche.

Voraussetzungen

• Ein laufender Traefik-Reverse-Proxy mit dem gemeinsamen proxy-Netzwerk und dem Let’s-Encrypt-Resolver le – wie im Tutorial Reverse Proxy mit Traefik aufgebaut.
• Eine Subdomain cloud.DEINE_DOMAIN, deren DNS-Record (A/AAAA) auf deine Server-IP zeigt – siehe Domain mit Server verbinden.
• Ein funktionierendes Backup. Eine Cloud ist der Ort, an dem Datenverlust am meisten wehtut – richte zuerst Backups mit Restic ein.

Wie groß dein Server für deine Nutzerzahl sein sollte, schätzt dir der Server-Rechner in ein paar Klicks.

Schritt für Schritt

Schritt 1: DNS-Record anlegen

Lege bei deinem DNS-Anbieter einen Eintrag cloud.DEINE_DOMAIN an, der auf deine Server-IP zeigt (A-Record für IPv4, AAAA für IPv6). Prüfe, dass er aufgelöst wird:

dig +short cloud.DEINE_DOMAIN

Du solltest deine Server-IP sehen. Erst wenn der Record steht, kann Traefik später das HTTPS-Zertifikat holen.

Schritt 2: Das proxy-Subnetz ermitteln

Nextcloud sitzt hinter Traefik. Damit Nextclouds Brute-Force-Schutz die echte Besucher-IP erkennt (und nicht die interne Traefik-IP sperrt), müssen wir Traefik als „vertrauenswürdigen Proxy" eintragen. Dazu brauchst du das Subnetz deines proxy-Netzwerks:

docker network inspect proxy -f '{{(index .IPAM.Config 0).Subnet}}'

Du bekommst etwas wie 172.18.0.0/16. Merke dir diesen Wert – er kommt gleich als TRUSTED_PROXIES in die Konfiguration.

Schritt 3: Die compose.yaml anlegen

Leg einen Ordner an und wechsle hinein:

mkdir -p ~/nextcloud && cd ~/nextcloud

Erstelle die compose.yaml. Ersetze cloud.DEINE_DOMAIN, alle Passwörter und das TRUSTED_PROXIES-Subnetz aus Schritt 2:

services:
  nc-db:
    image: mariadb:11.4
    container_name: nc-db
    command: --transaction-isolation=READ-COMMITTED --log-bin=binlog --binlog-format=ROW
    environment:
      MARIADB_ROOT_PASSWORD: EIN_STARKES_ROOT_PASSWORT
      MARIADB_DATABASE: nextcloud
      MARIADB_USER: nextcloud
      MARIADB_PASSWORD: EIN_STARKES_DB_PASSWORT
    volumes:
      - nc_db:/var/lib/mysql
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 6
    networks: [default]
    restart: unless-stopped

  nc-redis:
    image: redis:8-alpine
    container_name: nc-redis
    command: redis-server --requirepass EIN_STARKES_REDIS_PASSWORT
    networks: [default]
    restart: unless-stopped

  nc-app:
    image: nextcloud:34-apache
    container_name: nc-app
    depends_on:
      nc-db:
        condition: service_healthy
      nc-redis:
        condition: service_started
    environment:
      MYSQL_HOST: nc-db
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: EIN_STARKES_DB_PASSWORT
      REDIS_HOST: nc-redis
      REDIS_HOST_PASSWORD: EIN_STARKES_REDIS_PASSWORT
      NEXTCLOUD_TRUSTED_DOMAINS: cloud.DEINE_DOMAIN
      OVERWRITEPROTOCOL: https
      OVERWRITECLIURL: https://cloud.DEINE_DOMAIN
      TRUSTED_PROXIES: 172.18.0.0/16
      PHP_MEMORY_LIMIT: 1024M
      PHP_UPLOAD_LIMIT: 10G
    volumes:
      - nc_html:/var/www/html
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.nc.rule=Host(`cloud.DEINE_DOMAIN`)"
      - "traefik.http.routers.nc.entrypoints=websecure"
      - "traefik.http.routers.nc.tls.certresolver=le"
      - "traefik.http.routers.nc.middlewares=nc-dav"
      - "traefik.http.services.nc.loadbalancer.server.port=80"
      # .well-known-Redirect für CalDAV/CardDAV (siehe unten)
      - "traefik.http.middlewares.nc-dav.redirectregex.regex=https://(.*)/.well-known/(?:card|cal)dav"
      - "traefik.http.middlewares.nc-dav.redirectregex.replacement=https://cloud.DEINE_DOMAIN/remote.php/dav/"
      - "traefik.http.middlewares.nc-dav.redirectregex.permanent=true"
    networks: [default, proxy]
    restart: unless-stopped

volumes:
  nc_html:
  nc_db:

networks:
  default:
  proxy:
    external: true

Was hier wichtig ist:

• Drei Container: nc-app (Nextcloud), nc-db (MariaDB), nc-redis. Nur nc-app hängt im proxy-Netz (für Traefik) und im internen default-Netz. Datenbank und Redis bleiben ausschließlich intern – sie haben kein ports: und sind von außen nicht erreichbar.
• Zwei Named Volumes: nc_html (Programmcode, config.php, Nutzerdaten) und nc_db (die MariaDB-Daten). Das nc_db-Volume ist Pflicht: Ohne den Eintrag landet die Datenbank in einem anonymen Volume, und ein docker compose down gefolgt von up würde sie unwiederbringlich verlieren.
• healthcheck + depends_on: service_healthy: Nextcloud startet schneller als die Datenbank initialisiert ist. Ohne diesen Healthcheck scheitert die Erstinstallation an einem „Connection refused". So wartet der App-Container, bis MariaDB wirklich bereit ist.
• NEXTCLOUD_TRUSTED_DOMAINS: ohne die eigene Domain hier begrüßt dich Nextcloud mit „Zugriff über eine nicht vertrauenswürdige Domäne".
• OVERWRITEPROTOCOL: https sagt Nextcloud, dass es hinter HTTPS läuft – sonst baut es interne Links als http:// und Logins/Redirects brechen.
• TRUSTED_PROXIES: das Subnetz aus Schritt 2. Damit erkennt Nextcloud die echte Client-IP; sonst sperrt der Brute-Force-Schutz die Traefik-IP.
• PHP_MEMORY_LIMIT / PHP_UPLOAD_LIMIT: die Defaults (512 MB) sind für große Uploads zu klein. Hier großzügig gesetzt.
• loadbalancer.server.port=80: das Apache-Image lauscht im Container auf Port 80.
• Die nc-dav-Middleware löst ein klassisches Nextcloud-Problem – dazu gleich mehr.

Schritt 4: Starten und den Erst-Setup durchlaufen

Starte den Stack:

docker compose up -d

Beim ersten Start initialisiert MariaDB die Datenbank und Nextcloud entpackt sich – das dauert ein bis zwei Minuten. Verfolge es im Log:

docker compose logs -f nc-app

Beim ersten Lauf entpackt das Image Nextcloud ins Volume; du siehst Zeilen wie Initializing nextcloud 34.0.1.2 ... und schließlich Initializing finished, gefolgt vom Apache-Start. Erscheint stattdessen wiederholt restarting, wirf einen Blick in den Abschnitt „Wenn es nicht funktioniert". Mit Strg+C verlässt du die Log-Ansicht wieder (der Container läuft weiter).

Ruf dann https://cloud.DEINE_DOMAIN auf. Traefik holt beim ersten Zugriff das Zertifikat (kann ein paar Sekunden dauern). Weil wir Datenbank und Redis schon per Umgebungsvariablen konfiguriert haben, erkennt Nextcloud das automatisch und fragt nur noch nach einem Administrationskonto:

Vergib einen Admin-Namen und ein starkes Passwort und klick auf Installieren. Nextcloud richtet die Instanz ein – danach landest du auf der Anmeldeseite:

Nach dem Login begrüßt dich das Dashboard, und unter Dateien findest du deine Cloud mit ein paar Beispieldateien:

Schritt 5: Hintergrund-Jobs (Cron) einrichten

Nextcloud muss regelmäßig Aufgaben erledigen (Aufräumen, Benachrichtigungen, Vorschaubilder). Standardmäßig passiert das per „AJAX" bei jedem Seitenaufruf – das ist unzuverlässig. Der empfohlene Weg ist ein Cron-Sidecar: ein zweiter Container mit demselben Image, der nur cron.php ausführt. Ergänze in der compose.yaml einen Service:

  nc-cron:
    image: nextcloud:34-apache
    container_name: nc-cron
    entrypoint: /cron.sh
    depends_on:
      nc-db:
        condition: service_healthy
    volumes:
      - nc_html:/var/www/html
    networks: [default]
    restart: unless-stopped

Der Sidecar teilt sich das nc_html-Volume mit der App und führt die Jobs alle fünf Minuten aus. Übernimm die Änderung und stell den Modus in Nextcloud auf „Cron":

docker compose up -d
docker exec -u www-data nc-app php occ background:cron

Unter Verwaltung → Grundeinstellungen sollte jetzt „Cron" aktiv sein.

docker exec -u www-data nc-app php occ db:add-missing-indices
docker exec -u www-data nc-app php occ config:system:set default_phone_region --value=DE

Schritt 6: Die Clients verbinden

Jetzt der eigentliche Nutzen. Es gibt drei Wege, deine Cloud zu benutzen:

1. Desktop-Sync-Client (Windows/macOS/Linux): Installiere den „Nextcloud Desktop"- Client, gib als Server-Adresse https://cloud.DEINE_DOMAIN ein, melde dich an und wähle einen lokalen Ordner. Dateien werden wie bei Dropbox synchronisiert. Mit den virtuellen Dateien (Windows/macOS) belegen sie erst dann Platz auf der Platte, wenn du sie öffnest – praktisch, wenn deine Cloud größer ist als die lokale Festplatte.
2. Handy-App (Android/iOS): die offizielle Nextcloud-App, gleiche Server-Adresse. Ideal für den automatischen Foto-Upload vom Smartphone.
3. Kalender & Kontakte: In den Systemeinstellungen deines Geräts ein CalDAV-/ CardDAV-Konto mit der Adresse https://cloud.DEINE_DOMAIN anlegen – dank der .well-known-Middleware aus Schritt 3 funktioniert die automatische Erkennung.

Funktionen wie Kalender, Kontakte oder Mail sind eigene Apps, die du unter Verwaltung → Apps mit einem Klick nachinstallierst – Nextcloud ist also erweiterbar, ohne dass du am Server etwas anfassen musst.

Wenn es nicht funktioniert

Symptom: „Zugriff über eine nicht vertrauenswürdige Domäne" statt der Login-Seite.

Ursache & Lösung: Deine Domain steht nicht in trusted_domains. Prüfe NEXTCLOUD_TRUSTED_DOMAINS in der Compose-Datei. Nachträglich setzen geht per occ: docker exec -u www-data nc-app php occ config:system:set trusted_domains 1 --value=cloud.DEINE_DOMAIN.

Symptom: Der Sicherheits-Check meldet „Your web server is not set up properly to resolve .well-known/caldav".

Ursache & Lösung: Der CalDAV/CardDAV-Redirect greift nicht. Kontrolliere die nc-dav-Middleware-Labels (Schritt 3) und dass der Router sie über ...routers.nc.middlewares=nc-dav einbindet. Das Regex muss die volle https://…-URL matchen – redirectregex prüft die komplette URL, nicht nur den Pfad.

Symptom: Warnung „The ‘Strict-Transport-Security’ HTTP header is not set".

Ursache & Lösung: Der HSTS-Header fehlt. Setz ihn als Traefik-Middleware und häng sie an den Router: traefik.http.middlewares.nc-secure.headers.stsSeconds=15552000. Häng sie zusätzlich zur nc-dav-Middleware an den Router (...routers.nc.middlewares=nc-dav,nc-secure). Der Header muss vom Proxy kommen, nicht von Nextcloud. In Teil 2 richten wir genau diese nc-secure-Middleware vollständig ein (inklusive includeSubdomains).

Symptom: Große Uploads brechen ab oder enden mit einem Timeout / „413".

Ursache & Lösung: Das PHP-Limit ist zu klein. Erhöhe PHP_UPLOAD_LIMIT und PHP_MEMORY_LIMIT (Schritt 3) und starte den Container neu. In seltenen Fällen greifen diese Variablen nicht – dann ein eigenes php.ini-Snippet ins Image mounten.

Symptom: Beim ersten Start bricht die Installation mit „MySQL server has gone away" oder „Connection refused" ab.

Ursache & Lösung: Der App-Container war schneller als die Datenbank. Genau dagegen ist der healthcheck mit depends_on: condition: service_healthy da – prüfe, dass beide in deiner Compose-Datei vorhanden sind, und starte mit docker compose up -d neu.

Wartung & Backups

• Backups sind bei einer Cloud Pflicht. Ein konsistentes Backup braucht drei Dinge: die Datenbank (MariaDB-Dump), das Datenverzeichnis (deine Dateien) und die Konfiguration (config.php). Versetze Nextcloud vor dem Backup kurz in den Wartungsmodus, damit Datenbank und Dateien zueinander passen:

  Terminal

  docker exec -u www-data nc-app php occ maintenance:mode --on
  docker exec nc-db mariadb-dump -u root -pEIN_STARKES_ROOT_PASSWORT nextcloud > nextcloud-db.sql
  docker exec -u www-data nc-app php occ maintenance:mode --off

  Sichere den Dump zusammen mit dem nc_html-Volume verschlüsselt und off-site mit Restic – das rohe nc_db-Volume musst du dank des Dumps nicht zusätzlich sichern. Im nc_html-Volume stecken sowohl der Programmcode und die config.php als auch – unter data/ – deine eigentlichen Nutzerdateien. Wächst deine Cloud stark, kannst du dieses data/-Verzeichnis später auf ein eigenes, größeres Volume auslagern; fürs erste reicht ein Volume für alles.

• Updates: immer nur eine Hauptversion pro Schritt. Von 34 auf 35, nie direkt auf 36. Setz den Image-Tag hoch (nextcloud:35-apache), dann docker compose pull und docker compose up -d. Der Container führt das nötige occ upgrade beim Start automatisch aus. Vorher immer ein Backup anlegen. Den Cron-Sidecar auf dieselbe Version heben.

• Sicherheit prüfen. Lass nach dem Aufsetzen den offiziellen Nextcloud Security Scan gegen deine Domain laufen (Ziel: Note A) und arbeite die Warnungen aus der Admin-Übersicht ab. Die Übersicht unter Verwaltung → Übersicht führt automatische Prüfungen durch und zeigt genau, was noch fehlt. Halte Nextcloud aktuell – Sicherheitslücken werden zeitnah geschlossen, aber nur, wenn du updatest.

• Ehrlich zum Aufwand: Eine selbst gehostete Cloud will gepflegt werden. Rechne mit einem Update-Durchgang etwa monatlich und einem regelmäßigen Blick in die Admin-Übersicht. Dafür gehören die Daten dann wirklich dir.