Nextcloud selbst hosten: was ich anders einstelle als die Defaults

Nextcloud kommt regelmäßig bei Kunden auf, die eine selbst gehostete Alternative zu Dropbox oder Google Drive wollen, meist aus einer Mischung von Kostengründen (Cloud-Storage-Preise pro Nutzer summieren sich bei einem Team) und Gründen der Datenresidenz (Firmendateien auf Infrastruktur behalten, die man selbst kontrolliert). Die Installation selbst ist unkompliziert, ein Web-Installer übernimmt das meiste. Was eine Nextcloud-Instanz, die funktioniert, von einer unterscheidet, die Leute auch tatsächlich weiter nutzen, statt still wieder zu dem zurückzukehren, was sie vorher hatten, ist eine Handvoll Einstellungen, die im Default nicht falsch sind, nur nicht auf echte Nutzung abgestimmt.

Cron statt AJAX

Standardmäßig laufen Nextclouds Hintergrundjobs (Datei-Scans, Benachrichtigungen, Aufräumarbeiten) über AJAX, ausgelöst durch Seitenaufrufe im Browser. Das funktioniert technisch, bedeutet aber, dass Hintergrundjobs nur laufen, wenn gerade jemand das Web-UI offen hat, und kann Seitenaufrufe träge wirken lassen, weil sie zusätzliche Arbeit erledigen. Der Wechsel zu einem System-Cron-Job (oder besser, einem systemd-Timer), der alle fünf Minuten läuft, ist eine Konfigurationsänderung in den Admin-Einstellungen plus einer Zeile:

# crontab für den Benutzer des Webservers
*/5 * * * * php -f /var/www/nextcloud/cron.php

Nach dieser Änderung laufen Hintergrundjobs verlässlich nach Zeitplan, unabhängig davon, ob jemand das Web-Interface nutzt, und Seitenaufrufe tragen diese zusätzliche Arbeit nicht mehr mit sich.

Memory-Caching: APCu und Redis

Nextclouds Performance, besonders für das Web-UI und für Clients, die viele kleine Dateien synchronisieren, hängt stark davon ab, ob Caching konfiguriert ist. Ohne Caching liest jede Anfrage Konfiguration und File-Locking-Status erneut aus der Datenbank. Die empfohlene Einrichtung nutzt beides: APCu für lokales Memory-Caching, und Redis für File-Locking (das über Anfragen hinweg geteilt werden muss, und über mehrere App-Server, falls es mehr als einen gibt):

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

Der Unterschied ist im Web-UI am deutlichsten spürbar, Ordnernavigation und Dateilisten gehen von "merklichem Warten" zu fast augenblicklich, weil die Metadaten, die Nextcloud braucht, aus dem Speicher kommen, statt bei jeder Anfrage einen Roundtrip zu Datenbank und Dateisystem zu machen.

Upload-Limits leben an drei Stellen

"Ich kann keine Dateien größer als X hochladen" ist eines der häufigsten Nextcloud-Probleme, und der Grund ist, dass das Upload-Größenlimit über PHP, den Webserver und Nextclouds eigene Einstellung hinweg übereinstimmen muss, das kleinste gewinnt:

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

# nginx
client_max_body_size 16G;

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

Fehlt eine dieser Einstellungen, schlagen Uploads beim jeweils niedrigsten Limit fehl, oft mit einer Fehlermeldung, die nicht klar macht, welche der drei Ebenen der eigentliche Übeltäter ist. Alle drei konsistent zu setzen, auch großzügig, erspart eine verwirrende Troubleshooting-Session, wenn jemand zum ersten Mal versucht, ein großes Videofile hochzuladen.

Trusted Domains, bevor jemand gegen die Wand läuft

Nextcloud verweigert das Laden, wenn der Zugriff über einen Hostnamen erfolgt, der nicht in der trusted_domains-Liste steht, eine Sicherheitsmaßnahme, die aber für die erste Person, die die "falsche" URL ausprobiert (ein interner Hostname, eine IP-Adresse, eine neue Domain nach einer Migration), zu einem verwirrenden Fehler führt:

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

Jeden Hostnamen oder jede IP, die die Instanz sinnvollerweise erreichen sollte, von vornherein hinzuzufügen, einschließlich interner, die für Health-Checks oder Admin-Zugriff genutzt werden, erspart, dass das das erste ist, was jemand debuggen muss.

Größenordnung und Backups

Für ein kleines Team (eine Handvoll bis ein paar Dutzend Nutzer) läuft Nextcloud bequem auf derselben Art von VPS, die auch eine kleine WordPress-Seite betreibt, die Last pro Nutzer ist überschaubar, solange nicht viele große Dateioperationen gleichzeitig passieren. Was wächst, ist natürlich der Speicherplatz, und das ist der Teil, für den sich Planung lohnt: Das data-Verzeichnis braucht ein Backup genau wie eine Datenbank, und für einen Dienst, dessen gesamter Zweck "der Ort, an dem Dateien leben" ist, lohnt es sich, das korrekte Wiederherstellen (Dateiberechtigungen, die Struktur des Datenverzeichnisses, die Datenbank und die Config müssen alle zusammenpassen) einmal zu testen, genauso wie es sich lohnt, das Wiederherstellen eines Datenbank-Backups einmal zu testen, bevor es am Tag X wirklich gebraucht wird.

Keine dieser Änderungen ist schwierig, und keine davon macht der Installer falsch, genau genommen. Sie sind einfach der Unterschied zwischen einer Nextcloud-Instanz, die am ersten Tag technisch funktioniert, und einer, die sich auch nach einem Jahr noch schnell und zuverlässig anfühlt, nachdem echte Nutzung, echte Dateimengen und echte Upload-Größen Gelegenheit hatten, jeden Default zu finden, der nicht ganz darauf abgestimmt war.