Nextcloud selbst hosten: Was ich anders als die Standardeinstellungen konfiguriere

Nextcloud ist ein ständiges Thema bei Kunden, die dringend eine selbstgehostete Alternative zu Dropbox oder Google Drive suchen. Die Motivation dafür ist in der Regel eine Mischung aus Kosten (Abrechnungsmodelle pro Nutzer summieren sich für ein Team aggressiv schnell auf) und strengen Vorgaben zur Datenhaltung (Unternehmensdateien müssen zwingend auf einer Infrastruktur liegen, die man exklusiv kontrolliert).

Die Installation an sich ist absolut unkompliziert; ein webbasierter Installer übernimmt den Großteil der Arbeit. Aber was eine Nextcloud-Instanz, die einfach nur "irgendwie funktioniert", von einer unterscheidet, die die Leute tatsächlich weiterhin nutzen – anstatt heimlich wieder zu dem zurückzukehren, was sie vorher genutzt haben –, ist eine Handvoll spezifischer Einstellungen. Diese sind im Standard nicht unbedingt "falsch", aber sie sind absolut nicht für den echten Praxiseinsatz optimiert.

Cron statt AJAX

Wenn man absolut nichts an den Standardeinstellungen ändert, laufen die Hintergrundjobs von Nextcloud (wie Datei-Scans, Benachrichtigungen und Aufräumarbeiten) über AJAX. Sie werden passiv durch Seitenaufrufe im Browser getriggert.

Das funktioniert technisch gesehen, bedeutet aber, dass Hintergrundjobs nur dann ausgeführt werden, wenn zufällig gerade jemand das Web-Interface geöffnet hat. Außerdem kann es dazu führen, dass sich Seitenaufrufe unfassbar träge anfühlen, weil der Browser gezwungen ist, stellvertretend für den Server zusätzliche Hintergrundarbeit zu verrichten.

Dies auf einen dedizierten System-Cronjob (oder noch viel besser: einen systemd-Timer) umzustellen, der exakt alle fünf Minuten läuft, erfordert nur eine winzige Änderung in den Admin-Einstellungen plus exakt eine einzige Zeile im Terminal:

# crontab für den Webserver-User
*/5 * * * * php -f /var/www/nextcloud/cron.php

Nach dieser winzigen Änderung laufen die Hintergrundjobs hochgradig zuverlässig nach Plan, völlig unabhängig davon, ob gerade jemand das Web-Interface benutzt oder nicht. Und die Seitenaufrufe müssen diese schwere Zusatzlast nicht mehr mitschleppen.

Memory Caching: APCu und Redis

Die Basis-Performance von Nextcloud – ganz besonders für das Web-Interface und für Desktop-Clients, die tausende kleiner Dateien synchronisieren – hängt extrem stark davon ab, ob das Caching sauber konfiguriert ist.

Ohne Caching liest jeder einzelne Request aggressiv die Konfiguration und die File-Locking-Zustände direkt aus der Datenbank neu aus. Das dringend empfohlene Setup nutzt beides: APCu für brutal schnelles lokales Memory-Caching und Redis für verteiltes File-Locking (welches absolut zwingend über Requests hinweg geteilt werden muss – und über mehrere App-Server, falls man nach oben skaliert).

// config/config.php
'memcache.local' => '\OC\Memcache\APCu',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
    'host' => '127.0.0.1',
    'port' => 6379,
],

Der Unterschied, den das macht, ist im Web-Interface auf die Sekunde spürbar. Ordnernavigation und das Auflisten von Dateien wechseln von "spürbaren Wartezeiten" zu nahezu instantan. Die Metadaten, die Nextcloud so verzweifelt benötigt, kommen nun endlich direkt aus dem Arbeitsspeicher, anstatt bei jedem einzelnen Request einen Roundtrip zur Datenbank und zum physischen Dateisystem machen zu müssen.

Upload-Limits leben an drei verschiedenen Orten

"Ich kann keine Dateien größer als X hochladen" ist mit Leichtigkeit eine der häufigsten Beschwerden bei Nextcloud. Der Grund dafür ist, dass das Limit für die Upload-Größe zwischen PHP, dem Webserver und der internen Nextcloud-Einstellung explizit übereinstimmen muss. Welches Limit auch immer das absolut kleinste ist, gewinnt schlichtweg.

; php.ini
upload_max_filesize = 16G
post_max_size = 16G

# nginx
client_max_body_size 16G;

// config/config.php
'upload_max_filesize' => '16G',

Vergisst man auch nur eine einzige dieser Stellen, schlagen Uploads gnadenlos bei dem Wert fehl, der zufällig das niedrigste Limit darstellt. Meistens wird dabei eine extrem vage Fehlermeldung ausgespuckt, die nicht im Entferntesten verrät, welcher der drei Layer der tatsächliche Übeltäter ist. Setzt man alle drei Werte konsistent, gerne auch großzügig, vermeidet man aggressiv eine extrem verwirrende Fehlersuch-Session bei dem ersten Mal, wenn jemand versucht, ein riesiges Video hochzuladen.

Trusted Domains, bevor jemand gegen eine Wand läuft

Nextcloud weigert sich strikt zu laden, wenn es über einen Hostnamen aufgerufen wird, der nicht explizit in seiner trusted_domains-Liste steht. Das ist eine sehr clevere Sicherheitsmaßnahme, produziert aber eine unfassbar verwirrende Fehlermeldung für die allererste Person, die versehentlich die "falsche" URL ausprobiert (wie etwa einen internen Hostnamen, eine nackte IP-Adresse oder eine neue Domain nach einer Server-Migration).

// config/config.php
'trusted_domains' => [
  'cloud.example.com',
  '10.0.0.5',
],

Fügt man jeden einzelnen Hostnamen oder jede IP, die legitimerweise auf die Instanz zugreifen darf – inklusive interner IPs für Health Checks oder Admin-Zugriff – direkt von Anfang an hinzu, vermeidet man sauber, dass dies der allererste Fehler ist, den jemand debuggen muss.

Erwartungen an die Größe und Backups

Für ein kleines Team (eine Handvoll bis ein paar Dutzend aktive User) läuft Nextcloud extrem komfortabel auf exakt derselben Art von VPS, die auch eine normale WordPress-Seite stemmt. Die Last pro Nutzer ist generell moderat, es sei denn, Leute führen massiv viele große Dateioperationen gleichzeitig durch.

Was allerdings aggressiv wächst, ist logischerweise der Speicherplatz. Und das ist der Teil, den man tatsächlich planen sollte. Das data-Verzeichnis braucht zwingend eine solide Backup-Strategie, exakt wie eine Datenbank auch. Für einen Dienst, dessen einziger Existenzzweck es ist, "der definitive Ort zu sein, an dem die Unternehmensdateien leben", lohnt es sich absolut, mindestens einmal zu testen, ob man das Ganze auch korrekt wiederherstellen kann (Dateiberechtigungen, die Struktur des Datenverzeichnisses, die Datenbank und die Config müssen perfekt zueinander passen). Genau wie bei der Wiederherstellung eines Datenbank-Backups ist es unendlich viel besser, dies an einem ruhigen Mittwochnachmittag zu testen, als an dem Tag, an dem man es bitterernst braucht.

Keine dieser spezifischen Änderungen ist schwierig, und keine davon ist etwas, das der Standard-Installer per se "falsch" macht. Sie sind schlichtweg der Unterschied zwischen einer Nextcloud-Instanz, die am ersten Tag technisch gesehen funktioniert, und einer, die sich selbst nach einem Jahr, nach echtem Praxiseinsatz und massiven Dateivolumen, noch immer rasend schnell, zuverlässig und unauffällig anfühlt – lange nachdem diese Belastung jede Standardeinstellung, die nicht dafür getunt war, offengelegt hat.