Nextcloud auf Ubuntu Der Tiefgang zählt

Nextcloud auf Ubuntu – Mehr als nur eine Dateiablage

Nextcloud auf Ubuntu – das ist für viele Organisationen die erste Wahl, wenn es um selbstgehostete Dateiablage und Kollaboration geht. Aber der Teufel steckt, wie so oft, im Detail. Ubuntu ist als Betriebssystem für Server weit verbreitet, gilt als stabil, gut dokumentiert und bietet mit seinen Langzeitunterstützungsversionen (LTS) eine verlässliche Grundlage. Nextcloud wiederum hat sich in den letzten Jahren von einer reinen Dropbox-Alternative zu einer umfassenden Kollaborationsplattform gemausert: Kalender, Kontakte, E-Mail, Videokonferenzen, Office-Dokumente – alles unter eigener Kontrolle. Klingt gut, ist es auch. Doch die Praxis zeigt, dass eine fehlerfreie Installation und ein reibungsloser Betrieb jenseits der Standard-Doku einiges an Know-how erfordern. Dieser Artikel richtet sich an alle, die nicht nur eine schnelle Installationsanleitung suchen, sondern verstehen wollen, was hinter den Kulissen passiert – und wie man typische Fallstricke umgeht.

Nicht zuletzt die jüngsten Entwicklungen in der Cloud-Branche haben gezeigt: Vertrauen in Anbieter ist gut, eigene Kontrolle ist besser. Nextcloud adressiert genau dieses Bedürfnis nach digitaler Souveränität. Ubuntu als Unterbau ist dabei ein logischer Partner – kein Wunder, dass die Nextcloud GmbH selbst Ubuntu-basierte Appliances anbietet. Dennoch: Wer einfach nur ein Paket installiert und dann fröhlich Dateien hochlädt, der wird schnell an Grenzen stoßen. Die Datenbank verkraftet keine 10.000 Benutzer, die PHP‑Konfiguration ist nicht auf die Nextcloud‑Anforderungen abgestimmt, und der Hintergrundjob‑Manager läuft im Standard‑Modus, der bei vielen Nutzern zu Verzögerungen führt. All das sind lösbare Probleme, aber sie müssen bekannt sein. Ein interessanter Aspekt ist, dass viele Administratoren zuerst auf die grafische Oberfläche schauen, während das eigentliche Fundament aus Betriebssystem‑Einstellungen, Webserver‑Tuning und Datenbankoptimierung besteht. Fangen wir also an der Basis an.

Die richtige Ubuntu‑Version und die Qual der Wahl bei der Installation

Ubuntu 22.04 LTS (Jammy) oder 24.04 LTS (Noble) – das sind die üblichen Kandidaten für einen langlebigen Nextcloud‑Server. Die LTS‑Versionen erhalten fünf Jahre Sicherheitsupdates, für Unternehmen gibt es noch längere Zeiträume über Ubuntu Pro. Wer kann, sollte direkt zur aktuellen LTS greifen, also 24.04. Allerdings: Nextcloud selbst benötigt eine bestimmte PHP‑Version. Version 30 von Nextcloud beispielsweise setzt PHP 8.1 bis 8.3 voraus. Ubuntu 24.04 bringt PHP 8.3 mit, das passt perfekt. Ältere LTS‑Versionen liefern oft eine zu alte PHP‑Version, die man über externe Repositories nachrüsten muss – machbar, aber ein zusätzlicher Aufwand und potenzielle Konfliktquelle. Hier zeigt sich ein typisches Dilemma: Ein Administrator, der gewohnt ist, alles aus den offiziellen Ubuntu‑Repos zu beziehen, steht plötzlich vor der Entscheidung, ob er das ondrej/php‑PPA nutzt oder auf Docker setzt.

Die Installationsmethoden sind vielfältig. Nextcloud bietet ein offizielles Snap‑Paket, das viele Abhängigkeiten automatisch mitbringt und in einem isolierten Container läuft. Das klingt verlockend – und für einen schnellen Test ist es das auch. Aber im produktiven Einsatz mit vielen Benutzern und individuellen Anforderungen stößt die Snap‑Version schnell an Grenzen. Die Anpassung des Webservers, die Integration von externen Speichern (S3, NFS) oder die Verwendung eigener SSL‑Zertifikate ist umständlicher als bei einer manuellen Installation. Manche Administratoren berichten von Performance‑Einbußen, weil der Snap‑Mount zusätzliche I/O‑Latenzen verursacht. Ein anderer Weg ist der manuelle Aufbau: Apache oder Nginx, PHP‑FPM, MariaDB oder PostgreSQL, dann die Nextcloud‑Quellen ins Web‑Verzeichnis entpacken. Das klingt nach mehr Arbeit, aber die Flexibilität ist unschlagbar. Man hat die volle Kontrolle über jede Komponente, kann Caching‑Layer wie Redis einbinden, den PHP‑Speicher limitieren und die Datenbank gezielt optimieren. Dafür muss man sich mit den Konfigurationsdateien auskennen – und bereit sein, bei Updates selbst Hand anzulegen.

Dann gibt es noch die Docker‑Variante: Nextcloud als Container, kombiniert mit MariaDB, Redis und eventuell einem Reverse‑Proxy wie Traefik oder Nginx Proxy Manager. Das ist besonders dann attraktiv, wenn man ohnehin eine Docker‑Umgebung betreibt und Wert auf schnelle Bereitstellung und einfache Updates legt. Allerdings: Die Datenpersistenz muss sauber über Volumes organisiert sein, und die Netzwerkkonfiguration – vor allem bei HTTPS hinter einem Proxy – kann knifflig sein. Wer nicht täglich mit Docker arbeitet, wird mehr Zeit mit der Fehlersuche verbringen als mit der eigentlichen Konfiguration. Meine persönliche Empfehlung für den Mittelstand: die manuelle Installation auf Ubuntu LTS, kombiniert mit einem Konfigurationsmanagement wie Ansible. Einmal aufgesetzt, lassen sich Updates und Konfigurationsänderungen reproduzierbar durchführen. Der initiale Aufwand lohnt sich, wenn der Dienst später kritisch ist.

Die Datenbank – Herzstück oder Flaschenhals?

Nextcloud unterstützt offiziell MySQL/MariaDB, PostgreSQL und SQLite. SQLite ist nur für Testinstallationen oder ganz kleine Umgebungen mit einem Benutzer zu empfehlen – sobald mehrere Personen gleichzeitig arbeiten, wird SQLite zum Flaschenhals. Zwischen MariaDB und PostgreSQL gibt es aus Nextcloud‑Sicht keine großen Unterschiede, beide sind leistungsfähig. PostgreSQL hat den Ruf, bei komplexen Abfragen und unter Last etwas stabiler zu sein, während MariaDB durch seine MySQL‑Kompatibilität und einfachere Administration punktet. In der Praxis hängt die Wahl oft von vorhandenen Kenntnissen ab. Wichtig ist, dass die Datenbank auf dem gleichen Host oder zumindest im gleichen Netzwerk mit niedriger Latenz läuft. Ein häufiger Fehler: Die Datenbank wird auf einem separaten Server betrieben, die Netzwerklatenz ist aber hoch, und dann wundert man sich über lahme Seitenaufrufe. Nextcloud führt sehr viele Datenbankabfragen pro Seitenaufruf durch – besonders bei der Anzeige von Dateilisten mit vielen Unterordnern. Da hilft nur: Datenbank lokal oder über schnelles LAN anbinden, und die Abfragen durch Caching entlasten.

Ein interessanter Aspekt ist die Verwendung von MariaDB mit dem Aria‑Speichermodul für die temporären Tabellen – oder die Umstellung auf InnoDB mit Zeilenkomprimierung. Nextcloud speichert Metadaten in großen Tabellen, die schnell wachsen. Ohne regelmäßige Wartung (OPTIMIZE TABLE, ANALYZE) verschlechtert sich die Performance spürbar. Viele Administratoren vergessen, dass der MySQL‑Tuner oder das Tool mysqltuner regelmäßige Laufzeit‑Empfehlungen geben kann. Die Konfigurationsparameter innodb_buffer_pool_size, query_cache_type (inzwischen deaktiviert in MySQL 8, aber in MariaDB noch vorhanden) und max_connections sollten an die RAM‑Größe und die erwartete Benutzerzahl angepasst werden. Für eine Nextcloud‑Instanz mit 500 Benutzern und 2 GB RAM für die Datenbank reicht ein Buffer Pool von 1 GB oft nicht aus. Faustregel: Der Buffer Pool sollte mindestens so groß sein wie die gesamte Datengröße der Nextcloud‑Datenbank (nicht die Dateien, nur die Metadaten). Bei vielen kleinen Dateien kann die Metadatenbank schnell mehrere Gigabyte groß werden.

Webserver und PHP – die oft unterschätzte Performance‑Ebene

Apache mit mod_php ist bequem, aber nicht optimal für Nextcloud. Der Grund: PHP läuft als Modul direkt im Apache‑Prozess, was bei vielen gleichzeitigen Verbindungen zu hohem Speicherverbrauch führt. Besser ist die Kombination aus Apache (oder Nginx) und PHP‑FPM. PHP‑FPM hält einen Pool von PHP‑Prozessen vor, die unabhängig vom Webserver arbeiten. Bei Nextcloud empfiehlt sich die Verwendung von Nginx als Frontend – er ist ressourcenschonender und kann statische Dateien (Bilder, CSS, JS) direkt ausliefern, ohne PHP zu belasten. Die Konfiguration des PHP‑Pools sollte man nicht dem Zufall überlassen: pm = dynamic oder pm = ondemand, je nach Serverauslastung. Die Anzahl der child processes (pm.max_children) sollte auf den verfügbaren Speicher abgestimmt sein. Jeder PHP‑Prozess benötigt je nach PHP‑Version und Erweiterungen zwischen 30 und 50 MB RAM. Bei 8 GB RAM kann man also etwa 150‑200 Kinder zulassen, bevor der Speicher knapp wird. Dazu kommen noch die System‑Reserven. Viele Nextcloud‑Seiten werden dann plötzlich langsam, weil PHP‑Prozesse blockiert sind – eine typische Situation bei unzureichendem Tuning.

Ein weiterer Punkt: Nextcloud selbst benötigt einige PHP‑Erweiterungen, die oft nicht vorinstalliert sind. Dazu gehören bcmath, gmp, imagick, intl, zip, mbstring, xml, curl, gd und – ganz wichtig – redis. Die Redis‑Erweiterung wird für das Caching benötigt. Nextcloud kann ohne Redis auskommen, nutzt dann aber die Datei‑basierte Caching‑Methode, die bei vielen Dateien extrem langsam ist. Die Installation von Redis samt PHP‑Erweiterung ist schnell erledigt, aber man muss auch den Redis‑Server konfigurieren: Speicherbegrenzung (maxmemory), eviction‑Policy (allkeys-lru) und Persistenz (RDB/AOF). Redis dient nicht nur als Caching‑Layer, sondern auch als Lock‑Provider und für die Transaktionsverarbeitung (Transaktionslog). Ohne Redis sind viele Operationen wie das Hochladen großer Dateien über WebDAV deutlich langsamer. Also: Redis ist kein optionales Extra, sondern eine notwendige Komponente für den produktiven Betrieb.

Speicherkonzepte – lokal, S3, NFS und die Fallstricke

Nextcloud speichert die Benutzerdaten standardmäßig im Datenverzeichnis unter data/. Das kann ein lokales Verzeichnis sein, eine NFS‑Freigabe oder ein S3‑kompatibler Objektspeicher. Viele Administratoren unterschätzen, dass das Datenverzeichnis nicht auf einer langsamen Festplatte liegen sollte – SSDs sind heute Pflicht, zumindest für die Metadaten. Nextcloud legt pro Datei eine entsprechende Ordnerstruktur im data/-Verzeichnis an, und bei vielen Dateien führt das zu einer enormen Anzahl von Inodes. Ein ext4‑Dateisystem mit vielen kleinen Dateien kann schnell an seine Grenzen stoßen. Hier hilft es, das Dateisystem mit größeren Inode‑Tabellen zu formatieren (mkfs.ext4 -I 256 -N 20000000 /dev/…) oder auf XFS auszuweichen, das mit vielen Inodes besser umgeht. Manche Administratoren entscheiden sich für S3‑Speicher (z.B. MinIO, Ceph oder AWS S3), der die Dateiflatness umgeht. S3 ist skalierbar, aber es entstehen zusätzliche Kosten für API‑Aufrufe und Datenübertragung. Nextcloud bietet eine Primary Object Storage‑Schnittstelle, die einen S3‑Bucket direkt als primären Speicher nutzt. Die Konfiguration ist nicht trivial – man muss den Bucket vorher anlegen, die Zugriffsschlüssel hinterlegen und die Region korrekt angeben. Ein Tippfehler in der Endpoint‑URL, und Nextcloud kann keine Dateien speichern oder lesen. In der Praxis hat sich gezeigt, dass die Verwendung eines lokalen Speichers mit einer SSD für die meisten Unternehmen bis zu einigen Terabytes ausreicht. Für größere Umgebungen sind verteilte Speicherlösungen wie Ceph oder GlusterFS interessant, aber der Betriebsaufwand steigt erheblich.

Ein häufig übersehener Aspekt: Die Verwaltung von Papierkorb und Versionen. Nextcloud behält standardmäßig gelöschte Dateien 30 Tage im Papierkorb und ältere Versionen von Dateien. Das kann bei vielen Benutzern zu einem unerwarteten Platzverbrauch führen. Man kann die Aufbewahrungsfristen über die Nextcloud‑Konfiguration oder über den Papierkorb‑App anpassen. Auch die maximale Anzahl von Versionen pro Datei sollte begrenzt werden – Standard ist eine unbegrenzte Anzahl, was bei häufig bearbeiteten Dokumenten viel Speicher fressen kann. Ein konservativer Wert: maximal 50 Versionen, ältere als 365 Tage löschen. Das reduziert den Speicherbedarf drastisch, ohne die Benutzer vor unlösbaren Problemen zu stellen. Wer mit S3 arbeitet, sollte bedenken, dass das Löschen von Objekten in S3 nicht sofort den Speicher freigibt – es fallen weiterhin Kosten für die Aufbewahrung an, bis die Versionen endgültig gelöscht werden. Nextclouds eigene Versionsverwaltung ist darauf ausgelegt, aber die Wechselwirkungen mit der S3‑Lebenszyklus‑Policy müssen abgestimmt sein.

Sicherheit – nicht nur eine Frage der Firewall

Nextcloud auf Ubuntu bietet viele Stellschrauben für die Sicherheit. Grundlage ist ein gehärtetes Betriebssystem: nur die benötigten Ports öffnen (443, vielleicht 80 für Redirect), SSH nur mit Public‑Key‑Authentifizierung und Fail2ban aktivieren. Fail2ban sollte nicht nur den SSH‑Dienst überwachen, sondern auch die Nextcloud‑Logs. Nextcloud protokolliert fehlgeschlagene Login‑Versuche in den eigenen Logs. Mit einer entsprechenden Fail2ban‑Konfiguration kann man IP‑Adressen nach wenigen Fehlversuchen für eine Stunde sperren. Das schützt vor Brute‑Force‑Angriffen auf die Weboberfläche. Darüber hinaus empfiehlt sich die Aktivierung der Zwei‑Faktor‑Authentifizierung. Nextcloud bietet verschiedene TOTP‑Apps (z.B. andOTP, Aegis) und unterstützt Hardware‑Token wie YubiKey über die entsprechende App. Gerade bei Administratoren sollte 2FA Pflicht sein. Auch die Verwendung von WebAuthn (passwortlose Authentifizierung mit biometrischen Daten oder Sicherheitsschlüsseln) wird von Nextcloud unterstützt – ein Feature, das noch zu wenig genutzt wird.

Ein wichtiger Punkt, der oft übersehen wird: Die SSL‑Konfiguration. Let’s Encrypt mit Certbot ist einfach einzurichten, aber die standardmäßige Cipher‑Suite ist nicht immer auf dem neuesten Stand. Mit Tools wie SSL Labs Test oder dem Mozilla SSL Configuration Generator kann man die Konfiguration des Webservers (Nginx oder Apache) verbessern. HTTP Strict Transport Security (HSTS) sollte aktiviert sein, um Man‑in‑the‑Middle‑Angriffe zu verhindern. Auch die Absicherung des Datenverzeichnisses ist kritisch: Der Ordner data/ darf nicht über den Webserver direkt erreichbar sein. Nextcloud legt standardmäßig eine .htaccess‑Datei an, aber wenn man Nginx verwendet, muss man selbst im Server‑Block eine deny‑Direktive setzen. Viele Administratoren kopieren die Konfiguration aus Foren und vergessen diesen Schritt – ein Sicherheitsrisiko. Nextcloud selbst führt beim Setup einen Security‑Check durch, der viele Punkte abdeckt. Man sollte regelmäßig die Administrationsseite „Sicherheit & Setup‑Überprüfungen“ aufrufen und die dort aufgeführten Warnungen ernst nehmen. Ein unzureichend konfigurierter Hintergrundjob‑Manager (cron statt AJAX) wird dort ebenfalls bemängelt.

Dann ist da noch die Frage der Updates. Nextcloud veröffentlicht regelmäßig Sicherheitsupdates, manchmal auch außerhalb des normalen Release‑Zyklus. Die Update‑Prozedur ist über die Weboberfläche einfach: Ein Klick auf „Auf Update prüfen“ und dann „Update starten“. Aber bei großen Instanzen mit vielen Dateien kann das Update Minuten oder sogar Stunden dauern – und in dieser Zeit ist die Instanz nicht erreichbar. Besser ist es, Updates über die Kommandozeile mit dem occ‑Befehl durchzuführen: `sudo -u www-data php occ upgrade`. Vor jedem Update sollte ein vollständiges Backup der Datenbank und des data‑Verzeichnisses erstellt werden. Nextcloud bietet hierfür kein eingebautes Backup‑Tool – man muss selbst für eine regelmäßige Sicherung sorgen. Ein Skript, das die Datenbank mit mysqldump sichert und das data‑Verzeichnis rsync‑artig auf ein separates Laufwerk kopiert, ist schnell geschrieben. Die Wiederherstellung sollte mindestens einmal getestet werden, denn im Ernstfall zählt jede Minute. Nicht zuletzt: Firewall‑Regeln sollten auch den ICMP‑Verkehr (Ping) unterbinden – ja, das hört sich paranoid an, aber es reduziert die Angriffsfläche.

Skalierung und Hochverfügbarkeit – Wann wird es richtig komplex?

Nextcloud ist von Haus aus auf einen einzelnen Server ausgelegt. Skalierung bedeutet entweder, die Ressourcen des Einzelservers zu erhöhen (vertikale Skalierung) oder auf eine verteilte Architektur zu setzen (horizontale Skalierung). Vertikale Skalierung ist bis zu einem gewissen Punkt einfach: mehr RAM, schnellere SSDs, eine leistungsfähigere CPU. Allerdings stößt auch der beste Server irgendwann an Grenzen, vor allem bei der I/O‑Leistung bei vielen parallelen Dateizugriffen. Horizontale Skalierung ist mit Nextcloud prinzipiell möglich, aber aufwändig. Man benötigt mehrere Nextcloud‑Instanzen, die auf eine gemeinsame Datenbank und einen gemeinsamen Dateispeicher zugreifen. Das klingt trivial, aber es gibt Fallstricke: Die Datenbank muss hochverfügbar sein (z.B. Galera‑Cluster für MariaDB), und der Speicher muss für alle Instanzen gleichzeitig les‑ und schreibbar sein – das erfordert ein verteiltes Dateisystem wie GlusterFS, CephFS oder einen S3‑kompatiblen Objektspeicher. Die Synchronisation der Hintergrundjobs (z.B. Überprüfung von Änderungen) muss zentral gesteuert werden, damit nicht mehrere Instanzen gleichzeitig denselben Job ausführen. Nextcloud bietet hierfür einen Mechanismus über den occ‑Befehl und das Sperrsystem (Redis Locking) an. Wer mehrere App‑Server betreibt, sollte auch den Load‑Balancer korrekt konfigurieren – Session‑Persistenz ist nicht zwingend erforderlich, da die Authentifizierung über Token läuft, aber der Nextcloud‑Client erwartet eine konsistente Antwortzeit. Ein interessanter Aspekt ist die Verwendung von „Cluster‑fähigen“ Apps wie Talk – hier müssen Medienstreams über ein separates Backend wie Janus Gateway oder Livekit geleitet werden, was die Komplexität noch einmal erhöht. Die meisten Organisationen kommen mit einem gut dimensionierten Einzelserver bis zu 5000 Benutzern aus – die horizontale Skalierung ist eher etwas für Großunternehmen oder Hosting‑Provider.

Erweiterungen und Integration – Das Ökosystem von Nextcloud

Nextcloud lebt von seinen Apps. Die zentrale Nextcloud‑App ist natürlich die Dateisynchronisation. Dazu kommen groupware‑Funktionen (Kalender, Kontakte, Aufgaben), die über CardDAV und CalDAV mit Clients wie Thunderbird, Outlook oder mobilen Geräten kompatibel sind. Die Talk‑App ermöglicht verschlüsselte Video‑ und Audiokonferenzen – ein echter Drop‑in‑Replacement für Teams oder Zoom, wenn man die Server selbst kontrolliert. Die Integration von OnlyOffice oder Collabora Online erlaubt die Bearbeitung von Office‑Dokumenten direkt im Browser. Hier ist Vorsicht geboten: Beide Dienste erfordern einen eigenen Server (Docker‑Container oder separates System) und können bei vielen gleichzeitigen Nutzern sehr ressourcenintensiv sein. OnlyOffice benötigt für eine flüssige Bearbeitung etwa 2‑4 GB RAM pro Container und eine moderne CPU mit mehreren Kernen. Collabora ist ähnlich hungrig. Man sollte vor dem Deployment genau ausrechnen, wie viele gleichzeitige Bearbeitungen erwartet werden, und entsprechend dimensionieren. Ein weiteres Problem: Die Integration mit OnlyOffice oder Collabora erfordert eine korrekte SSL‑Konfiguration und dass die Nextcloud‑Instanz den Office‑Server über HTTPS erreicht – selbst im internen Netzwerk. Viele Administratoren scheitern an den selbstsignierten Zertifikaten, die von beiden Office‑Lösungen standardmäßig verwendet werden. Die Lösung: Entweder richtige Zertifikate verwenden (z.B. von Let’s Encrypt) oder die entsprechenden Einstellungen für die Zertifikatsüberprüfung deaktivieren – letzteres ist nicht empfehlenswert für produktive Umgebungen.

Die Nextcloud‑App‑Sammlung ist riesig – von Backup‑Lösungen über externe Speicheranbindung (S3, FTP, WebDAV, SharePoint) bis hin zu spezialisierten Branchenlösungen. Für Administratoren ist die LDAP‑Integration essentiell. Nextcloud kann Benutzer und Gruppen aus einem Active Directory oder OpenLDAP importieren und die Authentifizierung darüber abwickeln. Die Konfiguration ist über die Weboberfläche möglich, aber nicht intuitiv. Man muss den LDAP‑Server, die Basis‑DN, die Filter für Benutzer und Gruppen sowie die Mapping‑Attribute korrekt angeben. Ein Fehler in der Filterlogik führt entweder dazu, dass keine Benutzer importiert werden oder dass alle Benutzer sichtbar sind – sogar der Administrator. Die LDAP‑App hat in der Vergangenheit viele Bugs gehabt, die durch Updates behoben wurden. Bei der Integration sollte man darauf achten, dass die LDAP‑Verbindung verschlüsselt ist (LDAPS oder StartTLS), denn Passwörter werden im Klartext übertragen. Ein weiteres praktisches Feature: Die „External storage“‑App erlaubt es, Cloud‑Speicher wie Google Drive, Dropbox oder OneDrive einzubinden. Allerdings benötigt man dafür API‑Zugänge und muss OAuth‑Applikationen in den jeweiligen Diensten registrieren. Das ist lästig, aber ermöglicht eine echte Hybrid‑Cloud‑Strategie – eigene Daten auf dem Nextcloud‑Server, extern gespiegelte Ordner in der Public Cloud.

Betrieb und Wartung – Was nach der Installation kommt

Nextcloud zu installieren ist die eine Sache – den Betrieb stabil zu halten, die andere. Regelmäßige Updates der Nextcloud‑Version, der PHP‑Version und der Datenbank sind Pflicht. Die Nextcloud‑Release‑Politik sieht ein großes Update pro Jahr vor (z.B. Version 28, 29, 30). Diese Major‑Updates enthalten neue Features und manchmal auch Änderungen an der Datenbankschema, die für einen reibungslosen Ablauf sorgen, wenn man sie Schritt für Schritt durchführt. Es ist nicht empfehlenswert, direkt von Version 28 auf 30 zu springen – üblicherweise muss man jede Hauptversion durchlaufen. Für Administratoren bedeutet das: Alle sechs bis zwölf Monate ist ein Upgrade‑Marathon angesagt. Glücklicherweise sind die Upgrades in den letzten Jahren stabiler geworden, aber es bleibt ein Eingriff in die Produktion. Die Verwendung von Staging‑Umgebungen, in denen man das Update testet, bevor man es auf dem Produktivsystem durchführt, ist ein absolutes Muss. Viele Unternehmen verzichten darauf aus Zeitmangel – und erleben dann den Super‑Gau, wenn die Datenbank nach dem Update inkonsistent ist.

Ein weiterer Dauerbrenner ist das Monitoring. Nextcloud bietet eine einfache Status‑Seite (Übersicht), aber für eine professionelle Überwachung benötigt man externe Tools. Prometheus mit dem Nextcloud‑Exporter (z.B. nextcloud_exporter von GitHub) sammelt Metriken wie Anzahl der Benutzer, aktive Verbindungen, Speicherplatz, Datenbankabfragen und Hintergrundjobs. Grafana visualisiert diese Daten. Für den schnellen Check zwischendurch reicht ein einfacher Cron‑Job, der den HTTP‑Statuscode abfragt (200 OK). Sollte die Seite nicht erreichbar sein, kann eine Benachrichtigung per Mail oder Matrix ausgelöst werden. Auch die kostenpflichtige Nextcloud Enterprise Edition bietet ein eingebautes Monitoring‑Dashboard. Aber für die meisten Unternehmen ist die Kombination aus Prometheus, Grafana und Uptime‑Robot ausreichend. Wichtig: Auch die Hintergrundjobs (cron) müssen überwacht werden. Wenn der cron‑Job abstürzt, sammeln sich Dateien im Papierkorb, Index‑Aktualisierungen bleiben aus, und die Metadaten veralten. Ein regulärer Check der occ‑Ausgabe (cron.php) gibt Aufschluss. In der Administrationsansicht von Nextcloud sieht man den Status der letzten Cron‑Ausführung – wenn der Wert älter als zwei Stunden ist, stimmt etwas nicht.

Fehlerbehebung – Die häufigsten Stolpersteine

Trotz aller Sorgfalt läuft nicht immer alles glatt. Ein häufiger Fehler: Nach einem Update erscheint eine weiße Seite oder die Meldung „Internal Server Error“. Meistens liegt es an nicht kompatiblen Apps. Nextcloud deaktiviert bei einem Major‑Update standardmäßig inkompatible Apps, aber manchmal übersieht es welche. Der erste Schritt: Über die Kommandozeile alle Apps deaktivieren (`php occ app:list` und dann `php occ app:disable …`) und dann eine nach der anderen reaktivieren. Oder man schaut ins PHP‑Errorlog (meist unter /var/log/phpX.X‑fpm.log). Dort findet man oft konkrete Fehlermeldungen wie „Class not found“ oder „Allowed memory size exhausted“. Letzteres deutet darauf hin, dass die memory_limit in der php.ini zu niedrig ist – für Nextcloud sollten mindestens 512 MB eingestellt sein. Ein weiterer Klassiker: Der Webserver kann die Datei „data/.ocdata“ nicht lesen, weil der Benutzer (www‑data oder nginx) keine Rechte darauf hat. Die Lösung: `chown -R www-data:www-data /var/www/nextcloud/data` und die Berechtigungen mit `find … -type d -exec chmod 755 {} \;` setzen.

Dann gibt es das Problem mit dem Hintergrundjob‑Manager. Standardmäßig ist „AJAX“ eingestellt, was bei geringer Last funktioniert, aber bei vielen Benutzern zu großen Verzögerungen führt. Der Wechsel zu „cron“ erfordert das Einrichten eines Cron‑Jobs: `*/5 * * * * php -f /var/www/nextcloud/cron.php`. Dieser Cron‑Job ruft alle fünf Minuten die Nextcloud‑Hintergrundjobs auf. Wenn der Server viele Benutzer hat oder große Datenmengen verarbeitet, sollte man die Cron‑Intervalle auf eine Minute verkürzen. Aber Vorsicht: Zu häufige Cron‑Aufrufe belasten die Datenbank. Ein guter Wert ist jede Minute bei bis zu 500 Benutzern, alle zwei Minuten bei 1000+ Benutzern. Wer Redis einsetzt, kann auch den „Parallel Worker“‑Modus nutzen, der die Hintergrundjobs parallel verarbeitet – das macht Nextcloud bei großen Uploads deutlich reaktiver. Die Konfiguration erfolgt über den occ‑Befehl: `php occ config:app:set core backgroundjobs_mode –value=“parallel“`. Man sollte aber die Systemlast im Auge behalten, denn parallel bedeuted mehr CPU‑ und RAM‑Verbrauch.

Nextcloud in der Praxis – Ein Beispiel aus dem Mittelstand

Um die Theorie mit Leben zu füllen, ein kurzes Beispiel: Ein mittelständisches Unternehmen mit 200 Mitarbeitern sucht eine selbstgehostete Collaboration‑Plattform. Die Anforderungen: Dateispeicher mit Sync, Kalender, Adressbuch, ein bisschen Aufgabenverwaltung, und gelegentliche Videokonferenzen für kleinere Teams. Kein Active Directory vorhanden, aber eine Benutzerdatenbank in einer MySQL‑Datenbank. Die Wahl fällt auf Nextcloud auf Ubuntu 24.04 LTS. Die Installation erfolgt manuell mit Nginx, PHP‑FPM, MariaDB und Redis. Der Server: eine VM mit 8 vCPUs, 16 GB RAM und einer 500 GB SSD‑Festplatte für das Datenverzeichnis. Die Netzwerkkarte ist mit 1 Gbit/s angebunden. Nach der Grundinstallation wird Redis konfiguriert, der Cron‑Job auf eine Minute gestellt und der Speicher für den Papierkorb auf 14 Tage begrenzt. Die Benutzer werden per CSV‑Import angelegt, Passwörter werden per Mail versendet. Die Talk‑App bleibt deaktiviert, da der Bedarf gering ist und die Videokonferenzen lieber über ein separates System laufen sollen. Nach zwei Monaten Betrieb zeigt sich, dass die Auslastung des Servers unter 30 % liegt – die Lösung ist überdimensioniert, aber das gibt Spielraum für Wachstum. Ein Problem tritt auf: Einige Benutzer berichten, dass der Sync‑Client häufig „Datei in Konflikt“ anzeigt. Die Ursache: Zwei Benutzer bearbeiten gleichzeitig dieselbe Office‑Datei, die nicht über OnlyOffice kollaborativ bearbeitet wird – jeder speichert lokal, Nextcloud erkennt die Änderungen als Konflikt. Die Lösung wäre die Integration von Collabora oder OnlyOffice, aber das Unternehmen entscheidet sich vorerst für eine Nutzerschulung: „Entweder ihr bearbeitet die Datei nacheinander, oder ihr nutzt getrennte Kopien.“ Nicht elegant, aber günstiger.

Ein interessanter Aspekt in diesem Szenario ist die Backup‑Strategie: Die MariaDB wird jede Nacht per mysqldump gesichert, das data‑Verzeichnis wird jede Stunde per rsync auf eine zweite Festplatte gespiegelt. Einmal pro Woche wird das Backup auf einen NAS im anderen Gebäude kopiert. Der Wiederherstellungstest nach drei Monaten läuft reibungslos – die Downtime beträgt 20 Minuten. Das Unternehmen ist zufrieden. Die Nextcloud‑Version wird vierteljährlich per occ upgrade aktualisiert. Nach einem Jahr wird die Festplatte gegen eine Datenträgergruppe im RAID‑10 ausgetauscht, um die Ausfallsicherheit zu erhöhen. Der Betrieb bleibt stabil. Das Beispiel zeigt: Nextcloud auf Ubuntu ist für viele Szenarien eine robuste und kostengünstige Lösung, wenn man bereit ist, sich mit der Konfiguration auseinanderzusetzen. Der häufigste Fehler wäre, zu glauben, dass alles „out of the box“ funktioniert.

Ausblick – Wohin entwickelt sich die Plattform?

Nextcloud hat in den letzten Jahren eine bemerkenswerte Entwicklung durchgemacht. Die Version 30 bringt eine überarbeitete Benutzeroberfläche, bessere Unterstützung für große Dateien (Chunked Upload in mehreren Streams), und eine verbesserte Integration von Nextcloud Talk in die Benutzeroberfläche. Die Entwicklung hin zu einer echten Kollaborationsplattform ist unübersehbar. Während früher die Dateisynchronisation im Vordergrund stand, geht es heute um vernetzte Arbeitsabläufe: Nextcloud Files, Nextcloud Talk, Nextcloud Office, Nextcloud Groupware – alles aus einer Hand. Die Herausforderung für Administratoren besteht darin, dieses Ökosystem stabil zu halten. Mit jeder neuen Version wachsen die Anforderungen an die Infrastruktur. Die Einführung von Nextcloud Hub (der Zusammenführung der verschiedenen Komponenten) erhöht den Druck, sowohl Hardware als auch Software aktuell zu halten. Ubuntu mit seinen regelmäßigen LTS‑Release ist hier ein verlässlicher Partner, aber auch die Nextcloud‑Paketquellen müssen im Auge behalten werden. In Zukunft wird das Thema Containerisierung und Orchestrierung (Kubernetes) sicherlich wichtiger werden. Nextcloud selbst arbeitet an einem offiziellen Helm‑Chart für Kubernetes. Für Unternehmen, die bereits auf Kubernetes setzen, ist das eine attraktive Option, um Nextcloud hochverfügbar und skalierbar zu betreiben. Der Aufwand für die Einrichtung ist nicht zu unterschätzen, aber die Betreiber profitieren von automatischen Rollouts und vereinfachtem Management.

Ein weiteres großes Thema ist die Datenhoheit und die DSGVO. Nextcloud positioniert sich stark als datenschutzkonforme Alternative zu US‑Cloud‑Diensten. Mit Funktionen wie der Ende‑zu‑Ende‑Verschlüsselung für Dateien (E2EE) und der Möglichkeit, Server in der eigenen Jurisdiktion zu betreiben, spricht Nextcloud genau die Unternehmen an, die Wert auf Datenschutz legen. Allerdings ist die E2EE noch nicht ausgereift – sie funktioniert nur für Dateien, die über die Nextcloud‑Weboberfläche oder den Sync‑Client hochgeladen werden, und es gibt Einschränkungen bei der Durchsuchbarkeit. Auch die Verschlüsselung auf Serverebene (Server‑Side‑Encryption) ist ein Thema, das viele Administratoren beschäftigt. Sie schützt vor physischem Datendiebstahl, aber nicht vor Angriffen auf den Server selbst. Die Verwaltung der Verschlüsselungsschlüssel kann komplex sein – und bei einem Verlust der Schlüssel sind die Daten nicht wiederherstellbar. Nextcloud bietet gute Dokumentation, aber die Praxis zeigt, dass viele Administratoren die Verschlüsselung erst aktivieren, wenn es zu spät ist. Der Trend geht hier zu einfacheren Sicherheitsmodellen: Vertrauen in den Server, aber Absicherung durch Härtung des Betriebssystems und Netzwerksegmentierung.

Fazit – Ubuntu und Nextcloud: Ein starkes, aber kein einfaches Duo

Nextcloud auf Ubuntu ist eine der beliebtesten Kombinationen für selbstgehostete Cloud‑Dienste – und das zu Recht. Die Kombination aus einem stabilen, gut unterstützten Betriebssystem und einer mächtigen, Open‑Source‑Kollaborationsplattform bietet Unternehmen eine echte Alternative zu proprietären Anbietern. Doch der Weg zur produktiven Instanz ist mit mehr Hürden gepflastert, als die Marketingversprechen der Nextcloud‑Seite vermuten lassen. Die Installation ist schnell erledigt, aber der Betrieb erfordert ein tiefes Verständnis für Web‑ und Datenbanktechnologien. Wer sich darauf einlässt, wird mit einer flexiblen, erweiterbaren und datenschutzkonformen Plattform belohnt, die sich an die eigenen Bedürfnisse anpassen lässt. Der Schlüssel zum Erfolg liegt in der sorgfältigen Planung: Die richtige Ubuntu‑Version wählen, die Datenbank und das Dateisystem auf die Last auslegen, Caching nicht vergessen, regelmäßige Backups und Updates durchführen. Und dann ist da noch der Faktor Mensch – Nextcloud bietet viele Konfigurationsmöglichkeiten, aber nicht jeder Administrator hat die Zeit, sich in jede Einstellung einzuarbeiten. Mein Rat: Fangen Sie klein an, testen Sie im Labor, und gehen Sie erst dann in die Produktion, wenn Sie die Grundlagen verstanden haben. Nextcloud ist kein Produkt, das man „nebenbei“ betreibt – es ist eine Investition in die digitale Souveränität. Und die kann sich lohnen.