Nextcloud Files External: Die Welt jenseits des primären Speichers
Nextcloud ist für viele Organisationen das Rückgrat der eigenen Dateiablage. Die Software kann allerdings mehr, als nur Daten auf einem Server vorzuhalten. Neben dem primären Speicher gibt es das Konzept der externen Speicher, kurz Files External. Dabei wird ein weiterer Speicherort – ob NAS, SMB-Freigabe, S3-Bucket oder entferntes SFTP-Laufwerk – fest in die Nextcloud-Infrastruktur integriert. Klingt verlockend, ist in der Praxis aber nicht immer ein Kinderspiel. Dieser Artikel nimmt die Technik unter die Lupe, zeigt, wo sie glänzt und wo sie Ecken und Kanten hat.
Denn eines ist klar: Wer Nextcloud als zentrale Dateiplattform einführt, stößt früher oder später auf die Frage, wie sich die bereits vorhandenen Speichersysteme sinnvoll einbinden lassen. Es ist kein Zufall, dass viele Installationen mit einer Mischung aus lokalen Datenverzeichnissen, Object Storage und klassischen Fileservern arbeiten. Nextcloud stellt sich dabei als die Schicht dar, die diese unterschiedlichen Welten verbindet. Doch die Anbindung ist kein Selbstläufer. Sie erfordert ein solides Verständnis der zugrunde liegenden Protokolle und ihrer Eigenheiten.
Vom lokalen Datenkeller zum verteilten Dateimanager
Die ursprüngliche Idee von ownCloud und später Nextcloud war simpel: Die eigenen Dateien gehören auf einen Server, auf den man von überall zugreifen kann. Inzwischen ist die Software ein ausgewachsenes Ökosystem, das Collaboration, Videokonferenzen und Groupware umfasst. Doch die Basis bleibt die Dateiablage – und genau dort hat sich in den letzten Jahren ein stiller Wandel vollzogen. Es gibt kaum noch Installationen, die ausschließlich auf die lokale Festplatte eines einzelnen Servers schreiben. Stattdessen werden Speichersysteme unterschiedlichster Bauart angebunden: Netzwerkfreigaben, Objektspeicher, NAS-Geräte oder entfernte Server. Was sich nach einer simplen Admin-Offenheit anhört, ist in Wahrheit eine architektonische Notwendigkeit. Datenmengen wachsen, Backup-Konzepte verändern sich, und nicht zuletzt sind hybride Cloud-Modelle für viele Unternehmen zum Standard geworden.
Genau hier setzt das External-Storage-Modul an. Es erlaubt, beliebige Speicherorte als Ordner in die Nextcloud-Oberfläche einzublenden. Für die Nutzerinnen und Nutzer erscheinen diese externen Anbindungen wie ganz normale Verzeichnisse. Sie können Dateien hoch- und herunterladen, freigeben oder in Chats erwähnen. Dahinter steckt allerdings ein beachtlicher technischer Aufwand, der oft unterschätzt wird. Denn jedes Mal, wenn jemand auf eine solche Datei zugreift, muss die Nextcloud-Instanz den Inhalt vom externen System abrufen und an den Client ausliefern. Das kann zu Verzögerungen führen, gerade wenn die Anbindung über langsame Protokolle wie WebDAV erfolgt.
Man darf nicht vergessen, dass Nextcloud als PHP-Anwendung läuft. Jeder Dateizugriff wird über den App-Server vermittelt, nicht über direkte Betriebssystemaufrufe. Das ist ein Vorteil, weil es für eine hohe Portabilität sorgt. Es ist aber auch ein Flaschenhals, weil die Performance stärker von der Server-Konfiguration abhängt als bei einer natives C-Implementierung. Für externe Speicher bedeutet das: Wer die Latenz zwischen Nextcloud und dem Speicherort klein halten will, muss auf eine gute Netzwerkanbindung achten – und auf ausreichend dimensionierte PHP-Prozesse.
Was genau ist ein externer Speicher?
Um mit dem Begriff aufzuräumen: Externe Speicher sind keine ausgelagerten Backup-Platten oder per USB angeschlossene Festplatten. Es geht vielmehr um Speichersysteme, die der Nextcloud-Server über ein Netzwerkprotokoll anspricht. Die Anbindung erfolgt über sogenannte Storage-Backends, die das System mitbringt oder die sich per App nachrüsten lassen. Jedes Backend kapselt ein bestimmtes Protokoll – von klassischem FTP bis zu modernem S3-Object Storage.
Der Administrator legt fest, welcher Speicher wo eingehängt wird. Dabei lassen sich verschiedene Parameter angeben: die Adresse des Speichers, der Zielpfad, Zugangsdaten und – entscheidend – die Frage, für welche Benutzergruppen dieser Speicher sichtbar sein soll. Auf diese Weise kann man Abteilungsfreigaben auf einem zentralen Fileserver mit den Möglichkeiten der Nextcloud verbinden, ohne die Daten physisch verschieben zu müssen. Ein interessanter Aspekt ist, dass der externe Speicher nicht nur lesend genutzt werden kann. Je nach Protokoll und Rechteverteilung sind auch Schreibzugriffe möglich, was das System zu einem echten Bindeglied unterschiedlicher Datenwelten macht.
Die Kehrseite dieser Flexibilität: Die Verantwortung für die Daten bleibt beim Administrator des externen Systems. Wenn das NAS ausfällt oder der S3-Bucket nicht erreichbar ist, dann hilft auch die beste Nextcloud-Infrastruktur nicht weiter. Nextcloud kann den Zustand des Speichers zwar überwachen, aber nicht in die Wartung des entfernten Systems eingreifen. Dieses Misverhältnis von Sichtbarkeit und Kontrolle sollte jedem bewusst sein, der externe Speicher produktiv einsetzen möchte.
Die unterstützten Speichertypen
Nextcloud unterscheidet zwischen mehreren Backends. Der Funktionsumfang hat sich über die Jahre ausdifferenziert, wobei nicht alle Backends denselben Reifegrad erreicht haben. Die wichtigsten Vertreter seien hier kurz vorgestellt.
Der lokale Dateisystem-Ordner ist die einfachste Form. Er verweist auf einen Pfad auf dem Nextcloud-Server selbst. Praktisch ist das vor allem dann, wenn mehrere unabhängige Dateisysteme oder Partitionen existieren. Allerdings ist das streng genommen kein externer Speicher, sondern nur ein zweites lokales Verzeichnis. Der eigentliche Reiz liegt in den Netzwerkprotokollen.
SFTP ist eine robuste Variante, um entfernte Linux-Server anzubinden. Die Verschlüsselung ist standardmäßig aktiv, und die Authentifizierung lässt sich sowohl über Passwort als auch über SSH-Key realisieren. Letzteres ist besonders praktisch, weil mit einem Key keine zeitlich begrenzten Passwörter in der Nextcloud-Datenbank zwischengespeichert werden müssen. SFTP funktioniert gut für kleinere bis mittlere Installationen und bietet eine solide Performance, solange die Latenz zum Zielsystem im Rahmen bleibt. Ein Nachteil: Die Verwaltung von SSH-Keys über viele Server hinweg kann schnell unübersichtlich werden, gerade wenn man für jeden Benutzer eigene Schlüssel verwenden will.
Ein Klassiker ist SMB/CIFS, das native Protokoll von Windows-Freigaben. Viele Unternehmen betreiben nach wie vor zentrale Fileserver mit Windows Server oder ein NAS, das SMB spricht. Die Anbindung ist grundsätzlich möglich, aber mit einigen Tücken verbunden. Windows-ACLs und SMB-Berechtigungen sind nicht dasselbe wie die Rechtevergabe innerhalb von Nextcloud. Ein Benutzer, der in Nextcloud eine Datei sieht, kann sie nicht zwangsläufig öffnen, wenn der zugrunde liegende SMB-Benutzer keine Leseberechtigung hat. Und umgekehrt: SMB kennt keine Nextcloud-Freigabe-Logik. Die Fehlersuche bei Berechtigungsproblemen kann sich daher als zäher Prozess entpuppen. Wer SMB anbindet, sollte auch die Optionen für Zeitzonen und case-sensitive Verzeichnisse sorgfältig prüfen.
WebDAV ist ein weiteres häufig anzutreffendes Protokoll. Da Nextcloud selbst WebDAV spricht, lassen sich auf diese Weise zwei Nextcloud-Instanzen miteinander verbinden – oder auch andere Groupware-Systeme, die WebDAV bereitstellen. Die Einrichtung ist unkompliziert, aber die Übertragungsgeschwindigkeit hängt stark von der Serverkonfiguration der Gegenseite ab. WebDAV ist insofern ein guter Kompromiss, wenn man keine nativen APIs zur Verfügung hat. Man sollte aber bedenken, dass WebDAV für sehr große Dateien nicht unbedingt die beste Wahl ist, weil die Übertragung häufig stärker fragmentiert wird als bei S3 oder SFTP.
Der Bereich des Object Storage ist in den letzten Jahren erheblich in den Vordergrund gerückt. S3-kompatible Speicher wie MinIO, AWS S3 oder die Angebote diverser Cloud-Provider sind heute der De-facto-Standard für unstrukturierte Daten. Nextcloud kann S3 sowohl als primären Speicher verwenden als auch als externen Speicher einbinden. Letzteres ist interessant, wenn man einen bestehenden S3-Bucket über die Benutzeroberfläche zugänglich machen möchte, ohne die gesamte Nextcloud auf diesen Bucket umzustellen. Ähnliches gilt für OpenStack Swift, das vor allem in wissenschaftlichen und universitären Umgebungen verbreitet ist. Beide Backends erfordern allerdings ein Grundverständnis von Buckets, Access-Keys und Regions-Endpunkten. Wer sich mit diesen Begriffen nicht anfreunden kann, wird an der Konfiguration scheitern.
Für Anhänger der alten Schule gibt es auch weiterhin FTP beziehungsweise FTPS. Diese Protokolle haben jedoch ein Image-Problem: FTP ist unverschlüsselt, FTPS kann zwar verschlüsselt werden, ist aber in der Praxis wenig verbreitet. Die Übertragung von FTP ist nicht gerade für Effizienz bekannt, und Firewalls bereiten regelmäßig Probleme, weil für den Datenkanal zusätzliche Ports geöffnet werden müssen. In einer modernen Infrastruktur dürfte FTP heute nur noch eine untergeordnete Rolle spielen. Die Nextcloud-Entwickler haben es aus gutem Grund in die Kategorie der weniger empfehlenswerten Optionen eingeordnet.
Darüber hinaus lässt sich die Liste der Backends über die öffentliche API erweitern. Diese Schnittstellen entsprechen dem objektorientierten Storage-Ansatz von Nextcloud, bei dem ein Backend eine einheitliche Dateisystem-Implementierung nach außen trägt. Es gibt auch Drittentwickler, die Backends für spezielle Anwendungen anbieten. Fündig wird man aber vor allem in den offiziellen Nextcloud-App-Repositories.
Konfiguration in der Praxis
Die Konfiguration externer Speicher erfolgt in der Nextcloud-Administrationsoberfläche unter dem Menüpunkt „Externe Speicher“. Eine komfortable Tabelle listet die vorhandenen Anbindungen und erlaubt das Anlegen neuer Einträge. Dabei sind die Felder je nach Backend unterschiedlich. Für S3 braucht man beispielsweise Access Key, Secret Key, Bucket-Name und Endpoint. Bei SMB sind Host, Share und optional ein Domänen-Login gefragt.
Die Einstellung „Verfügbar für“ entscheidet, ob der Speicher für alle Benutzer, ausgewählte Gruppen oder nur für Administratoren sichtbar ist. Diese Zuordnung ist der zentrale Hebel, um unterschiedliche Storage-Bereiche an unterschiedliche Zielgruppen zu verteilen. So lässt sich eine versteckte Datenablage für die Buchhaltung realisieren, während die Entwicklungsabteilung ihren eigenen S3-Bucket als Ordner in Nextcloud sieht. Die Berechtigungen lassen sich später jederzeit ändern, doch sollte man sich im Klaren sein, dass einmal vergebene Freigaben auf bereits geteilte Dateien nicht unbedingt automatisch angepasst werden.
Wer lieber mit der Kommandozeile arbeitet, nutzt das occ-Kommando von Nextcloud. Es gibt unter anderem `occ files_external:create` und `occ files_external:list`. Mit `occ files_external:option` lassen sich einzelne Parameter nachträglich ändern. Die Kommandozeilenkonfiguration ist vor allem für automatisierte Provisionierung nützlich, etwa im Rahmen von Ansible-Playbooks oder Docker-Setups. Bei großen Installationen sollte man ohnehin auf Skripte setzen, denn je mehr externe Speicher eine Instanz hat, desto unübersichtlicher wird die grafische Verwaltung. Ein durchdachtes Scripting erleichtert auch die Reproduzierbarkeit der Umgebung in Notfall-Szenarien.
Ein Detail, das Administratoren häufig übersehen: Die Zugangsdaten für externe Speicher werden in der Nextcloud-Datenbank gespeichert. Das hat sicherheitstechnische Implikationen. Wenn jemand Zugriff auf die Datenbank erhält, sind unter Umständen auch die Anmeldeinformationen für das NAS oder den S3-Speicher kompromittiert. Nextcloud speichert sie zwar nicht im Klartext, aber die Entschlüsselung ist nicht sonderlich widerstandsfähig, sobald ein Angreifer die Nextcloud-Konfiguration und den Datenbankdump besitzt. Ein separater Zugangsschlüssel-Kasten wäre wünschenswert, ist aber bislang nicht Teil des Produkts.
Ein weiterer Punkt betrifft die Standard-Mount-Optionen. Je nach Backend kann man Timeout, Polling-Intervalle oder die Behandlung von Dateisystem-Fehlern einstellen. Diese Optionen lassen sich in der GUI oft über eine erweiterte Ansicht erreichen, in der man auch Prioritäten setzen kann. Die Priorität kommt immer dann zum Tragen, wenn derselbe Ordner durch mehrere Speicherquellen überlagert wird. Das ist eher ein Randthema, aber es zeigt, wie viele Stellschrauben die Entwickler vorgesehen haben.
Ein Blick unter die Haube: Dateikatalog und Storage-Wrapper
Die Architektur von Nextcloud ist für Außenstehende manchmal verwirrend, weil sie den Begriff „Dateisystem“ gleich mehrfach verwendet. Einerseits gibt es das tatsächliche Dateisystem des Servers, andererseits ein abstraktes Dateisystem in der Anwendung. Dieses abstrakte Dateisystem wird von einem Dateikatalog (Cache) gestützt, der alle Dateien und Ordner verzeichnet, die Nextcloud kennt. Bei externen Speichern werden die Dateien nicht physisch in das Nextcloud-Datenverzeichnis übernommen, sondern nur in den Katalog aufgenommen. Diese zweite Ebene zu verstehen, ist der Schlüssel zu fast allen Phänomenen, die bei External Storage auftreten.
Jeder externe Speicher wird als Mount-Punkt in der Datenbank eingetragen. Der Mount-Punkt ist ein gewöhnlicher Ordner, nur eben mit einer speziellen Storage-Klasse. Beim Zugriff auf diese Ordner arbeitet Nextcloud mit Storage-Wrappern, das sind verschachtelte Schichten, die zusätzliche Logik hinzufügen. Dazu gehören unter anderem ein Quota-Wrapper, der die Speicherplatzbeschränkung prüft, ein Permissions-Wrapper, der Lese- und Schreibrechte überwacht, und der eigentliche Storage-Backend-Wrapper, der die Verbindung zum externen System herstellt. Diese Wrapper sind ein elegantes Konzept, weil sie sich für alle Speichertypen gleichermaßen anwenden lassen.
Der Preis dieses Konzepts ist eine zusätzliche Komplexität. Wenn ein externer Speicher nicht wie erwartet funktioniert, liegt die Ursache nicht selten in einem Wrapper, der eine Berechtigung verweigert oder eine Quota falsch interpretiert. Ein typisches Beispiel ist der Quota-Wrapper bei SMB-Freigaben. Die Quota kann sich auf die gesamte Freigabe beziehen oder auf einen bestimmten Unterordner – je nachdem, wie der Administrator am SMB-Server die Grenzen gesetzt hat. Nextcloud kann diese Grenzen nicht zuverlässig ermitteln und verlässt sich auf die Angaben, die bei der Einrichtung gemacht wurden. Stimmen diese Angaben nicht, kann es zu unerwarteten Abweichungen kommen.
Ein weiteres Detail ist die Behandlung von Dateiänderungen. Nextcloud scannt die Dateisysteme regelmäßig, um neue Dateien zu erkennen und den Katalog zu aktualisieren. Bei lokalen Speichern funktioniert das über die Betriebssystemfunktionen. Bei externen Speichern muss der Scan über das jeweilige Protokoll laufen, was deutlich mehr Zeit in Anspruch nimmt, insbesondere wenn Tausende von Dateien vorhanden sind. Wer den Katalog nicht regelmäßig mit den realen Datenbeständen abgleicht, wird schnell mit veralteten Metadaten konfrontiert. Insofern ist eine geplante Schnittstelle zur Synchronisation von S3-Buckets und anderen externen Speichern kein Luxus, sondern eine betriebliche Notwendigkeit.
Wenn Latenzen zur Geduldsprobe werden
Die Performance externer Speicher ist das Thema, das Administratoren am häufigsten auf die Palme bringt. Es beginnt mit der Latenz: Wenn der Nextcloud-Server in Frankfurt steht und die S3-Buckets in einem Rechenzentrum in Irland, dann braucht jeder einzelne Datei-Request einen Roundtrip über diese Distanz. Das kann sich insbesondere bei vielen kleinen Dateien bemerkbar machen. Eine Verzeichnisliste mit 500 Einträgen lässt sich nicht in einem Rutsch laden, sondern muss über die Protokolle abgerufen werden. Die Folge ist eine spürbare Trägheit in der Benutzeroberfläche.
Der zweite Faktor ist der Durchsatz. Eine S3-Anbindung kann theoretisch sehr hohe Übertragungsraten ermöglichen, sofern der Endpoint richtig konfiguriert ist und die Netzwerkbandbreite ausreicht. In der Praxis scheitert es oft an falschen Multi-Part-Konfigurationen oder an zu kleinen Socket-Buffern. Ähnliches gilt für SMB: Das Protokoll hat in seinen modernen Versionen 3.0 und 3.1 zwar erhebliche Performance-Verbesserungen erfahren, aber die Nextcloud-Implementierung nutzt diese nicht immer in vollem Umfang. Ein NAS mit aktiviertem SMB2/3 kann deutlich schneller angebunden werden als ein altes SMB1-Laufwerk, aber die Unterschiede sind längst nicht in jeder Konfiguration spürbar.
Ein dritter Punkt ist die Auslastung der PHP-Prozesse. Während ein Upload von einem lokalen Speicher direkt in das Dateisystem geschrieben werden kann, müssen bei externen Speichern die Daten über den Nextcloud-Server laufen. Das bedeutet, dass die CPU des Servers an der Übertragung beteiligt ist, auch wenn sie eigentlich nur vermittelt. Unter Last können lange Uploads den PHP-FPM-Pool an die Grenze bringen. Hier hilft es, die Anzahl der gleichzeitig laufenden PHP-Prozesse zu erhöhen oder die Serverarchitektur mit einer speziellen Upload-Route zu optimieren. Beides ist nicht trivial und erfordert ein gewisses Know-how.
Die wichtigste Erkenntnis in der Praxis ist aber eine andere: Die Netzwerkqualität zwischen Nextcloud-Server und externem Speicher ist der entscheidende Engpass. Eine eigene Verbindung mit geringer Paketlaufzeit und hoher Bandbreite ist die Grundlage für zufriedenstellende Antwortzeiten. Wer diese Verbindung nicht kontrollieren kann, sollte keine Wunder erwarten. Eine externe Anbindung an einen Fileserver im Firmennetz ist eben etwas anderes als ein lokales SSD-RAID im Server-Schrank. Das muss den Endanwendern auch kommuniziert werden, sonst wird jeder kleine Ruckler zum Gegenstand von Beschwerden.
Sicherheit: Ein heikles Terrain
Sicherheit ist ein weites Feld, und bei External Storage lauern gleich mehrere Fallstricke. Der offensichtlichste ist der Umgang mit Zugangsdaten. Bei SMB oder WebDAV wird ein Benutzerkonto benötigt, das auf dem externen System existiert. Wenn Nextcloud die Logins aller Benutzer an das eine SMB-System weiterreichen soll, steht man vor einem Grundproblem. Man kann entweder ein generisches Servicekonto verwenden, das für alle Nextcloud-Nutzer dieselbe Berechtigung hat, oder man richtet für jede Nutzerin und jeden Nutzer ein eigenes Konto auf der Gegenseite ein. Letzteres ist zwar sauberer, aber der administrative Aufwand ist enorm. Viele Installationen entscheiden sich daher für das Servicekonto, was im Klartext bedeutet: mehr Rechte als nötig und ein potenzielles Einfallstor, falls die Zugangsdaten abfließen.
Empfehlenswert ist, für externe Speicher separate Accounts mit minimalen Berechtigungen anzulegen. Bei SFTP bietet sich die Authentifizierung mit SSH-Keys an, die pro Benutzer oder pro Dienstkonto vergeben werden. Die Keys werden in der Nextcloud-Konfiguration abgelegt und sollten passwortgeschützt sein. Doch auch hier gilt: Die hohe Kunst besteht darin, das Gleichgewicht zwischen Benutzerfreundlichkeit und Sicherheit zu wahren. Wer den externen Speicher als Consumer-Dropbox für alle Mitarbeiter nutzt, kann nicht gleichzeitig ein ausgefeiltes Berechtigungskonzept erwarten.
Als besonders kritisch erweist sich die fehlende Unterstützung für die Nextcloud-eigene Verschlüsselung. Viele Administratoren glauben, dass eine über External Storage angebundene SMB-Freigabe automatisch verschlüsselt wird, nur weil die Nextcloud-Instanz HTTPS verwendet. Das ist ein Missverständnis, das zu unangenehmen Überraschungen führen kann. Die Dateien liegen in den meisten Fällen in klarer Form auf dem Zielsystem. Eine Ausnahme bilden Verschlüsselungsfunktionen auf Ebene des Betriebssystems, etwa LUKS bei Linux-Volumes oder BitLocker bei Windows-Festplatten. Mit Nextcloud selbst hat das allerdings nichts zu tun.
Schließlich sollte man die Zugriffsrechte der Nextcloud-Benutzer auf externe Speicher nicht unterschätzen. Der Speicher wird als Ordner in der Dateiliste angezeigt. Wenn der externe Speicher für mehrere Gruppen freigegeben ist, können auch alle diese Gruppen den Ordner sehen – unabhängig davon, ob sie auf dem externen System überhaupt Leseberechtigung besitzen. Nextcloud blendet die Dateien zwar ein, aber beim Zugriff kommt es dann zu Fehlermeldungen. Diese Diskrepanz zwischen Darstellung und Realität kann administrative Anfragen geradezu provozieren. Um das zu vermeiden, sollte man die Berechtigungen in Nextcloud und am externen Speicher möglichst synchron halten.
Ein Bedrohungsszenario, das in Diskussionen oft zu kurz kommt, ist die Datenmanipulation auf dem Übertragungsweg. Zwar nutzen die meisten Backends TLS beziehungsweise SSH als Verschlüsselung, doch die Konfiguration entscheidet über die Sicherheit. Ein S3-Endpoint, der nur über HTTP erreichbar ist, überträgt Access-Keys und Daten im Klartext. Inzwischen bieten fast alle Provider verschlüsselte Endpoints an, aber die Verantwortung für die korrekte Einstellung liegt beim Administrator. Es ist erstaunlich, wie viele Nextcloud-Installationen nach wie vor mit unverschlüsselten WebDAV- oder SMB-Verbindungen arbeiten.
Wann sich externe Speicher lohnen – und wann nicht
Die zentrale Frage ist: Braucht man die Anbindung externer Speicher überhaupt? Die Antwort hängt stark vom eigenen Umfeld ab. Es gibt durchaus Szenarien, in denen sich die Mühe lohnt.
Ein klassisches Beispiel ist das Bestreben, eine bestehende SMB-Freigabe mit der kollaborativen Oberfläche von Nextcloud zu verbinden, ohne die Daten zu migrieren. Ein Projektteam, das bisher auf einem Windows-Fileserver arbeitet, bekommt plötzlich moderne Funktionen wie Kommentare, Versionierung und Freigabelinks – ohne den bewährten Fileserver abzuschalten. Das senkt die Einstiegshürde für die Akzeptanz von Nextcloud erheblich und vermeidet eine teure Datenmigration. Es ist gewissermaßen das digitale Äquivalent dazu, ein altes Aktenschränke-System durch ein dokumentenmanagement-Werkzeug zu ergänzen, ohne die papiernen Archive zu verbrennen.
Ein anderes Szenario bietet sich im Wissenschaftsumfeld an: S3-Buckets werden zum zentralen Speicher für Messdaten, die über Nextcloud mit anderen Forschern geteilt werden sollen. Auch hier ist die Kombination von S3 und Nextcloud sinnvoll, weil der Bucket nicht in das Nextcloud-Datenverzeichnis kopiert werden muss. Die Daten bleiben dort, wo sie erzeugt wurden, und Nextcloud sorgt für den geordneten Zugriff. Das bietet sich auch für Bilder und Videos an, die in großen Mengen anfallen und für die ein klassisches Dateisystem kaum noch geeignet ist.
Doch die Liste ließe sich verlängern. Wichtig ist, sich über die Risiken im Klaren zu sein. Externe Speicher vergrößern die Angriffsfläche, erschweren Backups und können die Performance spürbar drosseln. Wenn eine Anwendung sehr viele kleine Dateien verarbeitet, stößt die External-Storage-Anbindung schnell an ihre Grenzen. Jede Datei muss einzeln abgerufen werden, die Latenz multipliziert sich. Wer hohe Durchsatzraten benötigt, sollte besser beim Primärspeicher bleiben oder die Architektur so wählen, dass die Datenbank-Nähe erhalten bleibt.
Ein weiteres Gegenargument ist die erhöhte Komplexität bei der Datensicherung. Sichert Nextcloud nur den eigenen Datenordner, sind externe Speicher nicht mitgesichert. Ein einheitliches Backup über mehrere Speicherorte hinweg ist mit Bordmitteln kaum zu organisieren. Man muss also zusätzlich die externen Systeme in die Backup-Routine aufnehmen, was im Ernstfall zu einem Flickenteppich aus verschiedenen Backup-Lösungen führen kann. Nicht zuletzt steigt auch der Wartungsaufwand, weil die Abhängigkeit von unternehmensinternen Fileservern oder Cloud-Providern erhalten bleibt. Nextcloud wird damit zum Frontend für eine komplexe Speicherlandschaft, deren Single Point of Failure an vielen Stellen liegen kann.
Aus dieser Abwägung lässt sich eine Faustregel ableiten: Externe Speicher sind dann eine gute Wahl, wenn die Daten bereits an einem bestimmten Ort liegen und dort verbleiben müssen – aus Compliance-Gründen, wegen einer hohen Datenmenge oder weil die Migration zu aufwendig wäre. Wenn man dagegen eine neue Nextcloud-Installation auf der grünen Wiese plant, sollte man besser gemeinsam mit der Datenablage eine durchdachte Storage-Architektur wählen, die auf Primary Storage und gegebenenfalls auf dem Nextcloud-eigenen Object-Store aufsetzt. Externe Speicher als Dauerlösung für ein zentrales Filesystem zu verwenden, ist nicht das, was die Entwickler vor Augen haben.
Häufige Stolpersteine in der Praxis
Hat man sich für externe Speicher entschieden, braucht es etwas Erfahrung, um die Stolpersteine zu umgehen. Es beginnt bei der Planung: Man sollte nicht einen einzelnen Speicher, sondern möglichst mehrere in einer Testumgebung ausprobieren, bevor man das produktive System aufschraubt. Dabei hilft eine simple Checkliste: Ist das Zielsystem erreichbar? Sind die Ports freigegeben? Stimmen die Anmeldedaten? Lassen sich Dateien hoch- und herunterladen? Diese Fragen klingen banal, rächen sich aber regelmäßig, wenn sie nicht gründlich beantwortet werden.
Ein typischer Fehler ist die Verwendung von relativen Pfaden bei der Angabe des Zielordners. Wer etwa bei einer SMB-Freigabe als Wurzelverzeichnis nur den Share-Namen angibt, aber nicht den tatsächlich gewünschten Unterordner, bekommt unter Umständen eine Liste aller Verzeichnisse der Freigabe angezeigt. Das kann gewollt sein, ist aber oft nicht die Absicht. Ähnlich verhält es sich mit S3-Buckets: Nextcloud setzt nicht automatisch voraus, dass der Bucket existiert. Wird ein falscher Bucket-Name angegeben, erscheint eine kryptische Fehlermeldung, die den wahren Grund verschleiert.
Ein weiterer Stolperstein ist die Groß- und Kleinschreibung, abhängig vom zugrunde liegenden Dateisystem. S3 ist grundsätzlich case-sensitiv, während SMB-Freigaben auf Windows-Servern traditionell case-insensitiv arbeiten. Das kann dazu führen, dass eine Datei, die auf dem S3-Speicher unter „Bericht“ abgelegt wurde, über Nextcloud nicht gefunden wird, wenn jemand nach „bericht“ sucht. Die Nextcloud-Suche ist allerdings nicht an das Dateisystem gebunden, sondern an den Metadaten-Katalog. Daher kann es zu Diskrepanzen zwischen Suche und tatsächlicher Datei kommen. Solche Phänomene sind schwer zu debuggen, weil sie auf den ersten Blick nicht mit dem externen Speicher zusammenhängen.
Für die Diagnose steht in Nextcloud das occ-Kommando bereit. Der Befehl `occ files_external:verify` prüft, ob ein externer Speicher erreichbar ist und ob die Zugangsdaten gültig sind. Das Ergebnis zeigt Statusmeldungen, die einen schnellen Hinweis auf Fehlerquellen geben. Leider bleiben die Meldungen manchmal vage – „FTP Login failed“ hilft nicht viel, wenn man nicht weiß, ob der Benutzername oder das Passwort falsch ist. In einem solchen Fall hilft es, den Protokollpegel der Nextcloud-Logs zu erhöhen. Während eines Diagnose-Zeitraums sollte man alle Hintergrundprozesse beobachten, die auf den externen Speicher zugreifen.
Ein weiteres nützliches Werkzeug ist `occ files:scan –path`. Damit lässt sich ein einzelner Ordner neu einlesen, wenn der Verdacht besteht, dass der Dateikatalog nicht mehr dem tatsächlichen Inhalt des Speichers entspricht. Der Scan kann bei großen Bäumen einige Zeit dauern und sollte möglichst außerhalb der Lastspitzen ausgeführt werden. Bei S3-kompatiblen Speichern ist die Abweichung zwischen dem Katalog und dem Bucket-Inhalt ein bekanntes Problem, insbesondere wenn mehrere Anwendungen auf denselben Bucket zugreifen. Ein regelmäßiger Scan kann Wunder wirken, ist aber keine dauerhafte Lösung; das Problem sollte in der Prozesslogik der zugreifenden Anwendungen gelöst werden.
Nicht zuletzt sollte man das Monitoring nicht vernachlässigen. Nextcloud ist kein Speicher-Vollzeitmonitor. Externe Speicher, die mit einem S3-Bucket verbunden sind, lassen sich gut über Cloud-Metriken überwachen, die der Provider mitliefert. Bei SMB-Freigaben müssen Administratoren darauf vertrauen, dass der Fileserver ordnungsgemäß läuft. Ein unabhängiges Monitoring über externe Tools oder den integrierten Health-Check von Nextcloud ist daher ratsam. Eigene Dashboards in Grafana können helfen, aber das ist kein Thema, das man bei Einsteigern voraussetzen sollte.
Wer externe Speicher in Nextcloud produktiv betreibt, sollte außerdem den Speicherplatz im Auge behalten. Die Quota-Verwaltung von Nextcloud funktioniert bei externen Speichern nicht immer so streng wie beim primären Speicher. Ein Benutzer kann unter Umständen mehr Daten in einem externen Speicher ablegen, als sein Quota erlaubt, weil die Prüfung auf dem jeweiligen Dateisystem des Backends beruht. Das führt zu seltsamen Diskrepanzen: In der Nextcloud-Benutzeransicht wird vielleicht ein Wert angezeigt, der aber nicht mit dem tatsächlichen Verbrauch übereinstimmt. Solche Situationen lassen sich am besten durch ein regelmäßiges Report-Skript erkennen, das die Nutzungsdaten aus der Speicherverwaltung mit den Größenangaben des externen Systems abgleicht.
Zukunft: External Storage unter neuen Vorzeichen
Die Nextcloud-Entwickler haben das Thema externe Speicher nie als statisches Relikt aus der ownCloud-Zeit liegen lassen. Mit jedem Release wird die Liste der Backends gepflegt, das Berechtigungssystem verbessert und die Bedienung der Verwaltungsoberfläche modernisiert. In den letzten Versionen spielte vor allem die Integration von S3-kompatiblem Object Storage eine wachsende Rolle. Nicht zuletzt, weil die Nachfrage aus der Industrie nach skalierbarer Speicheranbindung steigt. Nextcloud trägt damit dem Umstand Rechnung, dass Open-Source-Teams ihre Daten zunehmend in der Cloud – bei Hyperscalern oder regionalen S3-Anbietern – ablegen wollen.
Ein interessanter Trend ist die zunehmende Nutzung von S3 als externem Speicher in Kombination mit einer lokalen Metadaten-Verwaltung. Die Vorstellung, dass ein Automations-Skript Daten in einen S3-Bucket schreibt, während Nutzerinnen und Nutzer über Nextcloud in denselben Bucket schauen, ist für viele Unternehmen attraktiv geworden. Die technischen Voraussetzungen sind inzwischen so ausgereift, dass die Integration ohne viel Zusatzaufwand gelingt. Obendrein lassen sich S3-Buckets in den meisten Fällen an eine Lifecycle-Regelung anbinden, die alte Objekte automatisch auf günstigere Speicherklassen verschiebt. Nextcloud bietet hierfür zwar keine Steuerung an, aber die Kombination lässt sich über die Möglichkeiten des Speicheranbieters abbilden.
Eine gewisse Skepsis ist angebracht, was die Rückwärtskompatibilität der Backends angeht. Wer heute eine SMB-Anbindung einrichtet, darf nicht davon ausgehen, dass sie in der übernächsten Nextcloud-Version noch genauso funktioniert wie gedacht. Die Entwickler sind bemüht, Änderungen mitzugehen, aber die zugrunde liegenden Protokolle und externen Bibliotheken haben ihre eigenen Releases und Eigenheiten. Langfristig gesehen könnte sich die Anbindung von Fileservern über SMB/CIFS deutlich zurückentwickeln, sobald sich alternative Protokolle wie NFS oder S3 als Standard in Rechenzentren etabliert haben. Davon unabhängig bleibt External Storage ein wichtiges Modul, das Nextcloud von anderen Self-Hosted-Lösungen abhebt. Kaum eine andere Software erlaubt es, so heterogene Speicherformen unter einer gemeinsamen, kollaborativen Oberfläche zu vereinen.
Fazit
Nextcloud Files External ist ein mächtiges Werkzeug mit doppeltem Gesicht. Einerseits eröffnet es Wege, Datenbestände aus bestehenden Systemen in eine moderne, kollaborative Plattform zu integrieren, ohne aufwändige Migrationen und ohne das Gefühl, die Kontrolle über die Daten zu verlieren. Andererseits ist die Liste der Einschränkungen lang: fehlende serverseitige Verschlüsselung, Eigenheiten bei Sperren, potenzielle Performance-Probleme und ein deutlich höherer Konfigurations- und Wartungsaufwand. Wer die Anbindung externer Speicher betreibt, sollte wissen, warum er es tut. Die Entscheidung sollte auf einer fachlichen Abwägung beruhen, nicht auf einem bloßen Experimentierkasten-Geist.
Für die Praxis empfiehlt sich ein konservativer Ansatz: Externe Speicher dort einsetzen, wo es wirklich erforderlich ist, sie frühzeitig überwachen und regelmäßig auf ihre Rechtfertigung hin prüfen. Und wenn die nächste große Storage-Architektur ansteht, sollte man die Möglichkeiten moderner Objektspeicher von Anfang an konstruktiv einbeziehen. Dann kann Nextcloud seiner Rolle als offene, flexible Plattform gerecht werden – nicht als perfektes Speichersystem, sondern als Schaltzentrale für eine digitale Infrastruktur, die eben mehrere Welten verbinden muss. Das ist vielleicht eine unbequeme Erkenntnis, aber ehrlich und letztlich auch ein Stück Beruhigung: Man kann mit Nextcloud auch jenseits des eigenen Datenkellers arbeiten, vorausgesetzt, man weiß genau, wo die Grenzen verlaufen.