External Storage in Nextcloud: Die Kunst, mit alten Dateischätzen zu leben

Wer Nextcloud einführt, hat meist ein klares Ziel: Schluss mit den verstreuten Laufwerken, unsicheren File-Sharing-Diensten und dem Datensilo im Keller. Doch die Wirklichkeit bleibt selten so aufgeräumt. Da liegt ein Jahrzehnt alter Windows-Server im Schrank, irgendwo in der Zentrale hängt ein NAS mit zig Terabyte Projektakten, und in einer anderen Abteilung arbeitet man schon länger mit Amazon S3, weil die Entwickler keine Lust mehr auf Heimnetzlaufwerke hatten. Genau in diesem Moment beginnt die eigentliche Arbeit – und genau dafür gibt es die External-Storage-Funktion von Nextcloud.

Die Idee dahinter ist verführerisch simpel: Nextcloud kann andere Speicherorte wie SMB-Freigaben, FTP-Server, WebDAV-Quellen oder S3-kompatible Buckets als eigenen Ordner in die Cloud integrieren. Der Administrator bindet diese Quellen ein, und die Dateien erscheinen für die Benutzer wie ganz normale Inhalte unter einem Mountpoint im Verzeichnisbaum. Man kann sie öffnen, bearbeiten, freigeben und über Clients synchronisieren. Und genau hier liegt der Haken: Die Funktion ist machtvoll, aber sie will mit Verständnis eingesetzt werden. Wer nur ein Häkchen setzt und darauf hofft, dass schon alles gutgehen wird, merkt spätestens dann, wie komplex Dateisysteme, Protokolle und Berechtigungskonzepte sein können, wenn die ersten Dateien nicht mehr synchronisieren.

Dieser Artikel nimmt die Einrichtung, die verschiedenen Backends und die Tücken unter die Lupe. Nicht alle Empfehlungen werden jedem Setup gerecht, aber ein paar Grundregeln lassen sich auf fast jede Umgebung übertragen. Denn eines ist sicher: External Storage in Nextcloud ist weit mehr als eine administrative Spielerei.

Ein Schrank im Schrank: Die Idee hinter den Mountpoints

Um zu verstehen, was Nextcloud hier tut, hilft ein Bild. Stellen Sie sich einen Umkleideschrank vor, in dem jeder Benutzer sein eigenes Fach hat. Von außen sieht man nur die Türen, und trotzdem lassen sich darin auch Ablagen anderer Räume integrieren, wenn man einen Schlauch vom Nachbarschrank herüberführt. Technisch gesprochen enthält das Nextcloud-Datenverzeichnis normalerweise alle Dateien des Web-Interfaces. Ein externer Speicher wird jedoch nicht verschoben oder kopiert, sondern von PHP zur Laufzeit an einer bestimmten Stelle eingehängt.

Dabei zeigt sich, warum Nextcloud als Plattform so geschätzt wird: Weil die App das Einhängen als Abstraktionsebene über viele Protokolle kann. Wer einmal versucht hat, SMB-Freigaben, Microsofts Azure Blob Storage und einen klassischen FTP-Server in einem einzigen System zu verwalten, der weiß diesen Komfort zu schätzen. Der Preis dafür ist, dass die Eigenschaften des jeweiligen Backends niemals vollständig hinter Nextcloud versteckt werden können. Ein FTP-Server hat andere Dateinamen-Beschränkungen als ein lokales Linux-Dateisystem, und ein S3-Bucket reagiert auf Ordnerlisten anders als ein Windows-Dateisystem. Nextcloud gleicht diese Unterschiede nicht magisch aus, sondern versucht sie zu umschiffen.

Ein interessanter Aspekt ist in diesem Zusammenhang die Trennung zwischen primärem Speicher und externem Speicher. Jede Nextcloud-Instanz kennt einen Standard-Datenordner, in dem Benutzerdateien abgelegt werden. Externe Speicher ergänzen diese Struktur, ersetzen sie aber nicht. Das klingt zunächst banal, hat jedoch Konsequenzen: Die interne Dateisuche, die Vorschau-Erzeugung und die Verschlüsselung behandeln externe Mounts anders und manchmal mit schlechteren Ergebnissen. Nicht zuletzt deshalb sollte man sich vor der Einrichtung genau überlegen, was die jeweiligen Daten eigentlich erleben werden.

Diese Speichertypen lassen sich andocken

Nextcloud bringt von Haus aus eine beachtliche Liste an Backends mit. Die meisten sind seit Jahren stabil und werden in Unternehmen erstaunlich häufig genutzt. Der Laufwerkstyp „Local“ etwa ist im Prinzip nur ein Verzeichnis auf dem Server, das außerhalb des offiziellen Data-Verzeichnisses liegt. Viele Administratoren nutzen ihn, um eine zweite Festplatte oder ein lokal per NFS eingehängtes NAS zu integrieren. Die Performance ist in diesem Fall exzellent, weil kein Netzwerkprotokoll zusätzlich zwischengeschaltet wird. Aber Achtung: „Local“ ist in der Nextcloud-Konfiguration nur dann verfügbar, wenn das Verzeichnis für den Webserver-Benutzer les- und schreibbar ist. Wer vergisst, die passenden Rechte zu vergeben, wundert sich später über unsichtbare Dateien oder nervige Fehlermeldungen.

Weit verbreitet ist die Anbindung von SMB beziehungsweise CIFS, also Windows-Freigaben und Samba-Servern. In Büroumgebungen mit Windows-Servern hängen daran oft Jahrzehnte gewachsene Ablagestrukturen. Nextcloud kann diese Freigaben direkt einbinden, wahlweise mit einem zentralen Dienstkonto oder mit persönlichen Anmeldedaten der Benutzer. Der Mountpoint verhält sich dann aus Nutzersicht fast wie ein Netzlaufwerk, ist aber zusätzlich durchsuchbar und mit Cloud-Features versehen. Obendrauf kommt die Integration von FTP- oder SFTP-Servern, die vor allem bei älteren Hosting-Umgebungen anzutreffen ist, und die WebDAV-Anbindung, die sich perfekt für andere Nextcloud- oder ownCloud-Instanzen eignet.

Für die moderne Welt sind S3-kompatible Objektspeicher wie MinIO, Ceph, Wasabi oder AWS S3 selbst der interessanteste Fall. Hier geht es aber nicht um einen netten Zusatz, sondern um eine völlig andere Art der Datenhaltung: Objektspeicher enthält flache Buckets ohne klassische Ordnerhierarchie, eignet sich aber hervorragend für riesige Datenmengen. Nextcloud kann solche Buckets nicht nur als externen Speicher-Ordner nutzen, sondern auch selbst als primäres Ziel für den Hauptspeicher konfigurieren. Der Unterschied ist wichtig. Wer einen S3-Bucket als externen Mount einrichtet, ruft über das PHP-Backend Objekte ab und legt sie nicht im lokalen Datenbestand ab. Wer Nextcloud primär auf S3 betreibt, verschiebt dagegen das gesamte Datenverzeichnis in den Objektspeicher – inklusive der Metadaten-Verwaltung, die dabei ein wenig unter die Räder kommen kann.

Doch auch die weniger exotischen Protokolle kommen nicht zu kurz. Da wäre zum Beispiel Dropbox: Wird in einem Unternehmen noch mit einem Altkonto gearbeitet, kann Nextcloud die Ordnerinhalte über eine separate Schnittstelle anbinden. Ähnliches gilt für Google Drive. Diese Connectors hängen jedoch an OAuth-Flows und sind nicht selten davon abhängig, dass der jeweilige Anbieter seine API über viele Jahre stabil hält. Ein erfahrener Admin sieht hier eine gewisse Fragilität, die es bei SMB oder S3 nicht gibt. Denn bei den direkten Protokollen bleibt die Kontrolle über die Zugangsdaten in der eigenen Infrastruktur.

Einrichtung: Wenige Klicks, aber eine Menge Details

Die Konfiguration selbst ist in den letzten Nextcloud-Versionen gut in die Systemeinstellungen gewandert. Man meldet sich als Administrator an, öffnet den Punkt „Externer Speicher“ und wählt zunächst die Art des Backends aus, beispielsweise „SMB/CIFS“. Danach erscheint ein Formular, das nach dem Ort fragt, unter dem der Speicher später erscheinen soll. Üblich ist ein Name wie „Sales“, „Archiv“ oder „Freigabe-Backup“. Im nächsten Schritt werden die Transportdetails hinterlegt: Serveradresse, gegebenenfalls Port, Share-Name und die Authentifizierungsmethode. Bei SMB lassen sich Domänen angeben, was gerade in Active-Directory-Umgebungen wichtig ist. Und schließlich muss festgelegt werden, ob alle Benutzer oder nur bestimmte Gruppen diesen Mount sehen dürfen.

Wer bereits einmal einen Mount über die Kommandozeile konfiguriert hat, der wird manche Begriffe aus Unix-Vergessenheit wiederfinden. Der Unterschied zur klassischen /etc/fstab liegt allerdings in der Datenhaltung von Nextcloud: Es wird nicht der Kernel, sondern eine Nextcloud-eigene Service-Schicht bemüht, die den externen Speicher mithilfe von PHP-Funktionen beziehungsweise externer Bibliotheken durchforstet. Auf manchen Distributionen benötigt das Zusatzpakete wie „php-smbclient“ oder „libsmbclient“. Fehlt die passende Extension, erscheinen einige Backend-Optionen erst gar nicht. Schon deshalb lohnt sich ein prüfender Blick in die Server-Logs, bevor man die Schuld auf Nextcloud schiebt.

Ein Punkt, den viele übersehen, ist die Unterscheidung zwischen globalen Freigaben und Benutzer-spezifischen Mounts. Nextcloud erlaubt es, einen externen Speicher nur für eine einzelne Person oder eine Gruppe einzurichten. Das ist dann sinnvoll, wenn die Inhalte nicht für die gesamte Firma bestimmt sind. Es bringt jedoch einen gewissen Verwaltungsaufwand mit sich, weil die Zugriffsmatrix schnell unübersichtlich wird. Ratsam ist, Konventionen für Mountpoint-Namen zu entwickeln und die Einrichtung nicht nach Lust und Laune vorzunehmen. Sonst findet sich nach einem Jahr ein „/private_Wind“-Ordner, dessen Zugriffsrechte niemand mehr nachvollziehen kann.

Ein interessantes Detail der Benutzeroberfläche ist die Schaltfläche zum Prüfen der Verbindung. Sie klingt harmlos, kann aber enorm helfen. Nextcloud versucht dabei, den gewählten Speicher mit den eingegebenen Zugangsdaten zu erreichen. Wenn diese Prüfung fehlschlägt, steht noch lange nicht fest, welche Ursache vorliegt: falsches Passwort, blockierter Port, defektes Zertifikat oder ein Server, der eine andere SMB-Version spricht als erwartet. Die Fehlermeldung ist in den meisten Fällen kurz und nützlich. Selten aber führt sie direkt zum Ziel. Wer hier gerne auf eigenes Wissen vertraut, sollte auf dem Server einen manuellen Test durchführen. Bei SMB genügt oft ein Blick mit smbclient, bei FTP kann die Befehlszeile per curl die Verbindung prüfen.

Rechte, Rollen und das Problem mit dem Quota

Sobald die Infrastruktur steht, beginnt die eigentliche Feinarbeit: die Rechtekonzeption. Nextcloud unterscheidet zwischen Lese- und Schreibzugriff, und das gilt auch für Externe Speicher. Der Administrator kann einen Mount auf „schreibgeschützt“ stellen, wenn er verhindern möchte, dass versehentlich Daten in einem Altbestand verändert werden. Das ist in vielen Migrationsszenarien der richtige Einstieg. Man macht das NAS sichtbar, bevor man es wirklich umzieht, lässt die Mitarbeiter ein paar Tage testen und schaltet die Schreibrechte erst frei, wenn alle die Konventionen kennen.

Was Systemadministratoren jedoch gern unterschätzen, ist die Quotenproblematik. Der externe Speicher zählt nicht automatisch zu dem Speicherkontingent, das dem Benutzer in Nextcloud zugewiesen ist. Eine Datei auf einem SMB-Mount kann in der Benutzeroberfläche also erscheinen, ohne den verfügbaren Platz des Benutzers zu reduzieren. Das ist manchmal gewollt, kann aber zu Missverständnissen führen: Benutzer sehen „Ihre Cloud“, aber die belegte Größe der externen Freigabe bleibt unsichtbar. Wenn es darauf ankommt, wer wie viele Terabyte verbraucht hat, ist ein externes Speicher-Backend plötzlich ein blinder Fleck im Reporting.

Ein weiterer Stolperstein sind die Gruppen- und Benutzerzuordnungen. Wer den Mount als Administrator anlegt und bei „Verfügbar für“ die Option „Alle Benutzer“ wählt, legt sich auf eine starre Struktur fest. Wenn später eine neue Abteilung in die Firma kommt, ist das kein großes Problem. Wenn aber der externe Speicher nur für drei Personen in der Buchhaltung gedacht ist, sollte man die Anforderung sauber über Gruppen lösen. Das gilt insbesondere, wenn mehrere externe Mounts existieren. Aus der Praxis kenne ich Konstellationen, in denen ein Mitarbeiter in fünf verschiedenen Gruppen steckt und am Ende vier verschiedene Netzlaufwerk-Mounts sieht, von denen er nur zwei wirklich braucht. Die Übersicht leidet, und mit ihr die Akzeptanz der Cloud-Lösung.

Sicherheit, Verschlüsselung und die Crux mit den Anmeldedaten

Nextcloud bietet ein App-Update, das auch externe Speicher mit der serverseitigen Verschlüsselung versieht. Bevor man diese Funktion jedoch aktiviert, sollte man sich sehr genau überlegen, welche Ziele man damit verfolgt. Denn die Verschlüsselung findet nicht im Speichersystem statt, sondern auf dem Nextcloud-Server selbst. Die Daten werden vor dem Schreiben auf den externen Mount verschlüsselt und beim Lesen wieder entschlüsselt. Das erhöht die CPU-Last und erschwert die direkte Verarbeitung der Originaldateien auf dem Zielsystem. Ein S3-Bucket, der von Nextcloud verschlüsselt wurde, kann nicht unabhängig von Nextcloud von einem anderen Dienst genutzt werden. Man schafft sich also eine Art Abhängigkeit, die man eigentlich vermeiden wollte.

Ein noch heiklerer Punkt sind die Anmeldedaten. Bei SMB und FTP kann der Administrator zentrale Zugangsdaten hinterlegen, die für alle Benutzer gelten. Nextcloud speichert diese Daten in der Datenbank. Das ist praktisch, bedeutet aber auch, dass der Zugang zu einem alten Windows-Server über ein Dienstkonto läuft, das vielleicht niemals ausläuft. Sicherheitsexperten sehen das kritisch, und das zu Recht. Besser ist in vielen Fällen die Authentifizierung über Benutzer-Logins: Der Nutzer gibt nicht nur sein Nextcloud-Passwort ein, sondern hinterlegt im externen Mount seine eigenen Zugangsdaten. Nextcloud kann diese Daten sogar für die aktuelle Sitzung speichern, sodass sie nicht dauerhaft auf dem Server liegen. Diese Methode funktioniert natürlich nur, wenn die externen Konten existieren und gepflegt werden.

Nicht zuletzt müssen Zertifikate und Verschlüsselungsprotokolle auf Aktualität geprüft werden. Ältere FTP-Server verwenden oft SSL-Versionen, die längst als unsicher gelten. Bei SMB ist die Unterstützung für das veraltete SMBv1 inzwischen deaktiviert, aber manche Heimgeräte sind noch immer der Ansicht, dass die Welt von 2003 nicht vorbei ist. Nextcloud verweigert mitunter die Verbindung, was zunächst wie ein Fehler von Nextcloud aussieht. Tatsächlich ist es eine Art Schutzfunktion – doch die Diagnose erfordert Erfahrung und manchmal ein tieferes Eintauchen in die Protokolldateien des Backend-Servers.

Wenn es ruckelt: Performance und Skalierung

Der häufigste Kritikpunkt an externen Speichern ist nicht die Sicherheit, sondern die spürbare Trägheit. Dabei wäre es unfair, Nextcloud dafür verantwortlich zu machen. Wer eine Datei von einem SMB-Fileserver lädt, muss den Weg erst über das Netzwerk zum Nextcloud-Server und dann noch einmal von dort zum Client nehmen. Diese doppelte Reise ist systemimmanent. Nextcloud verhält sich hier wie ein Vermittler, der jede Datei abholt und weitergibt. Wenn der Client direkt auf die SMB-Freigabe zugreifen würde, wäre er schneller unterwegs, hätte aber keine Cloud-Funktionen wie Volltextsuche, Dateikommentare oder öffentliche Freigabelinks. Genau diese Funktionen machen den Umweg für viele Anwendungsfälle wertvoll.

Ein großes Thema ist die Performance bei Verzeichnissen mit vielen Dateien. Nextcloud muss Metadaten zu Dateien vorhalten, um Vorschauen zu erzeugen und in der Oberfläche sortieren zu können. Bei einem externen Speicher kann das Abrufen der Verzeichnisliste erhebliche Zeit in Anspruch nehmen, wenn das Backend keine performante Listenoperation unterstützt. Ein lokaler Ordner ist hier deutlich schneller als ein SFTP-Server oder eine WebDAV-Schnittstelle. Ein SMB-Server liegt oft im Mittelfeld, hängt aber von der Implementierung des Servers ab. Ein Windows Server mit guten Netzwerkbedingungen liefert erstaunlich brauchbare Ergebnisse; ein einfaches NAS aus dem Verbrauchermarkt kann dagegen zur Geduldsprobe werden. Bevor man also ein neues Backup-System anschafft, sollte man prüfen, ob der Storage von Nextcloud beziehungsweise seinen Clients überhaupt gut genug abgerufen werden kann.

Manche Probleme lassen sich umgehen, indem man zwischen Nextcloud und dem externen Backend nicht das breiteste, sondern das flachste Protokoll wählt. Bei SMB ist es beliebt, ein CIFS-Laufwerk mit dem Linux-Kernel zu mounten und dieses Verzeichnis dann als „Local“ in Nextcloud zu registrieren. Der Vorteil: Nextcloud muss nur auf das normale Dateisystem des Servers zugreifen, was die Anzahl der Protokollschichten reduziert. Der Nachteil: Man muss den Mount auf Betriebssystemebene verwalten und verliert die bequeme Benutzer-Session-Authentifizierung über Nextcloud. Trotzdem ist diese Variante gerade für große SMB-Freigaben eine Überlegung wert. Ich habe Installationen gesehen, in denen ein solcher Local Mount deutlich stabiler lief als alle SMB-Implementierungen in PHP-Schichten.

Etwas anderes ist der Betrieb auf S3 als externen Speicherbucket. Objektspeicher glänzen bei großen, unveränderlichen Datenmengen und parallelen Zugriffen. Für Anwendungen, die viele kleine Dateien ständig verändern, sind sie weniger geeignet. Nextcloud versucht, diese Eigenschaften zu verbergen, was zuweilen gelingt. In der Praxis merkt man die Unterschiede vor allem dann, wenn Ordner auf einem S3-Bucket durchsucht oder verschoben werden. Renames und Kopien erzeugen hier eventuell viele Einzelobjekte, was Zeit kostet. Ein richtig skalierender, großer Ordner mit zehntausenden Dateien wird deshalb auf jedem Backend irgendwann an Grenzen stoßen – egal, ob lokal oder extern.

Typische Stolperfallen und Lösungsansätze

Die mit Abstand häufigste Fehlermeldung bei SMB ist der Hinweis, dass der Zugriff nicht möglich sei. Bevor man die Fernwartung anruft, sollte man zunächst klären, ob der Server den Hostnamen von Nextcloud kennt. In kleinen Netzwerken genügt oft der NetBIOS-Name, in größeren Domänen muss der korrekte FQDN verwendet werden. Auch die SMB-Version spielt eine Rolle. Der Nextcloud-Server versucht, die höchste vom Client unterstützte Protokollversion zu verwenden. Wenn der Zielserver nur SMB1 kann, wird die Verbindung in aktuellen Nextcloud-Versionen zu Recht abgelehnt. Eine Modernisierung dieses Altgeräts ist dann unumgänglich.

Bei FTP- und SFTP-Anbindungen sind es häufig passive Modus-Einstellungen, die für Verbindungsabbrüche sorgen. Wer FTP hinter einer Firewall betreibt, muss sicherstellen, dass auch die Datenkanal-Ports durchgelassen werden. SFTP ist da etwas unkomplizierter, weil es nur einen Port benötigt. Dafür kommen Host-Key-Verifikationen ins Spiel: Ändert der Server seinen SSH-Schlüssel, schlägt die Verbindung fehl, bis der neue Schlüssel in der Datenbank von Nextcloud hinterlegt ist. Automatische Skripte, die einen solchen Schlüsselwechsel nicht berücksichtigen, können stundenlange Ausfälle verursachen.

Ein weiterer Ärgernis-Punkt sind Zeichensätze und Sonderzeichen. Wer SMB mit einem Server betreibt, der historische Dateinamen mit Windows-Kodierungen enthält, bekommt plötzlich kaputte Umlaute oder unsichtbare Zeichen. Nextcloud geht davon aus, dass Dateinamen in UTF-8 vorliegen. Manche Altsysteme verwenden aber Latin-1 oder andere Kodierungen, was zu scheinbar willkürlich unlesbaren Namen führt. Für die Migration ist das eine echte Hürde. Es gibt zwar Skripte und Konvertierungswerkzeuge, aber wer das Problem ignoriert, wird später beim Verschieben der Dateien in einen sauberen Datenbestand viel Zeit verlieren. Da ist es besser, das Alt-System zunächst nur schreibgeschützt anzubinden und die Daten in kleinen Brocken über die Weboberfläche zu bewegen.

Die gute Nachricht: In Nextcloud gibt es eine Reihe von Diagnose-Möglichkeiten, die Administratoren nutzen können. Das Kommandozeilenwerkzeug occ hilft nicht nur bei der Verwaltung von Dateiscans, sondern kann auch externe Mounts auflisten. Wer die ganze Umgebung lieber per Skript aufsetzt, findet in der Nextcloud-Dokumentation Hinweise, um Storage-Konfigurationen in Konfigurationsdateien oder über occ vorzuhalten. Ein weiterer Tipp: Aktivieren Sie das Debug-Logging auf dem Nextcloud-Server, wenn Sie einen Mount einrichten. So sehen Sie, welche HTTP-Anfrage an welche Stelle läuft. Allzu oft ist es am Ende ein simples Berechtigungsproblem auf dem Zielserver, das sich mit einem einzigen chmod oder einem neuen Benutzerkonto beheben lässt.

Grenzen und der richtige Einsatz

External Storage ist kein Allheilmittel. Wer die Funktion nutzt, um einen veralteten Fileserver dauerhaft in den Status einer „Cloud“ zu erheben, verpasst die Chance, die Datenstruktur zu verbessern. Nextcloud ist zwar in der Lage, mit jeder Menge Unordnung umzugehen, aber es belohnt saubere Strukturen. Wenn ein SMB-Server über Jahre hinweg nur Notizordner und gelöschte Unterverzeichnisse enthält, wird ein externer Mount die Fehler nicht automatisch beheben. Er macht die Daten nur zugänglich – und das ist immerhin ein Anfang.

Auch sollte man nicht jede Art von Daten über einen externen Speicher laufen lassen. Für kollaborative Echtzeit-Dokumente, die mehrere Personen gleichzeitig bearbeiten, ist ein lokal verwalteter Nextcloud-Speicher die robustere Wahl. Die Integration von OnlyOffice oder Collabora greift zwar auf Dateien zu, die Nextcloud kennt, aber bei sehr langsamen externen Backends leidet die Bearbeitung. Wer täglich Tabellenkalkulationen auf einem alten FTP-Server bearbeiten muss, hat nichts von einer wolkigen Anbindung gewonnen. In solchen Fällen ist es sinnvoller, nur einzelne Verzeichnisse zu spiegeln oder die betreffenden Dateien in den primären Nextcloud-Speicher zu migrieren.

Ein interessanter Aspekt ist zudem die Frage, ob man nicht auf die Funktion „Group Folder“ zurückgreifen soll, statt einen externen Mount einzurichten. Group Folders sind keine echten externen Speicher, aber sie bieten ähnliche Eigenschaften wie eine zentrale, gruppenbasierte Ablage. Sie lassen sich beispielsweise über das Benutzer-Interface praktisch verwalten, haben aber eine andere technische Basis. Für viele Teamordner mit ausschließlich neuen Daten ist dies der einfachere Weg. Externe Speicher eignen sich vor allem dann, wenn die Datenquelle außerhalb von Nextcloud liegt und die Besitzer der Daten diese Kontrolle nicht abgeben möchten.

Dabei zeigt sich eine eigentümliche Stärke von Nextcloud: Man kann Daten fremder Systeme einbinden, ohne den Anspruch zu erheben, sie physisch besitzen zu wollen. Das ist für viele Unternehmen eines der stärksten Argumente für die Open-Source-Cloud. Ein externes Archiv aus S3-Buckets, ein uraltes FTP-Verzeichnis von einem Außendienst-Mitarbeiter – Nextcloud wird zur einzigen Oberfläche, die all das sichtbar macht. Die Oberfläche täuscht allerdings eine Zusammenhängigkeit vor, die es unter der Haube nicht gibt. Wenn der externe Dienst ausfällt, steht der Ordner in Nextcloud an einem unsichtbaren Faden. Dort erwartet der Anwender natürlich eine normal funktionierende Datei. Fehlermeldungen, die irgendetwas von „Network is unreachable“ erwähnen, führen dann zu Verwirrung.

Der Blick nach vorn: Hybride Speicherwelten bleiben

Nextcloud arbeitet seit Jahren an der Optimierung von Storage-Lösungen. Die Einführung von S3 als primärem Speicher hat gezeigt, wie weit die Plattform gekommen ist. Wer viele historische Daten und ein stetiges Wachstum hat, kann inzwischen das Datenverzeichnis selbst auf einen Objektspeicher auslagern. Das ist jedoch ein anderes Konzept als External Storage: Hier verzichtet der Administrator darauf, einen eigenen Dateiserver beziehungsweise einen lokalen Datenbestand zu unterhalten. Stattdessen werden Dateien als Objekte in einem S3-Container abgelegt. Die Vorteile liegen in der Skalierbarkeit und in der hohen Ausfallsicherheit, die der Objektspeicher bieten kann.

Was früher einmal eine Spezialität von großen Cloud-Anbietern war, ist heute in vielen Rechenzentren Standard. Nicht zuletzt durch Open-Source-Software wie Ceph ist ein eigener S3-Cluster bezahlbar geworden. Nextcloud unterstützt diese Entwicklung bereits im Kern. Und dennoch wird es auch in Zukunft Situationen geben, in denen die einfachste Form der Anbindung ein klassischer Mountpoint bleibt. Etwa wenn eine Abteilung weiterhin ihren Windows-Dateiserver bedienen möchte, weil dort Spezialsoftware mit hart verdrahteten Laufwerksbuchstaben läuft. Solange diese Welt existiert, wird External Storage seine Daseinsberechtigung behalten.

Es ist sogar wahrscheinlich, dass hybride Modelle weiter zunehmen. Denn viele Firmen wollen nicht alles in eine einzige Nextcloud-Instanz zwingen. Sie haben Zweigstellen mit eigenen Servern, die nur bestimmte Ordner freigeben. Oder sie kooperieren mit anderen Unternehmen und müssen auf gemeinsame Laufwerke zugreifen, die von einer fremden Organisation gepflegt werden. Nextcloud kann solche Fernverbindungen über WebDAV, SMB oder SFTP herstellen – und es kann diese Fernverbindungen in Dateifreigaben und damit in die Collaboration einweben. Wer eine offene Haltung gegenüber Datenquellen hat, wird mit der Plattform nicht so schnell an Grenzen stoßen.

Praxis-Empfehlungen für einen entspannten Betrieb

Einige Dinge sollte man von Anfang an festlegen, um später weniger Bauchschmerzen zu haben. Zuerst gehört dazu eine saubere Dokumentation der Mountpoints. Klingt nach unnötiger Schreibarbeit, erspart aber im Support-Fall viele Rückfragen. Notieren Sie, welcher klassische Server auf welchem Mount liegt, wie die Anbindung abgesichert ist und ob ein Dienstkonto oder anonyme Zugriffe verwendet werden. Schreiben Sie auch auf, welche Person oder Gruppe für die Pflege des externen Speichers verantwortlich ist. Das ist vor allem dann wichtig, wenn der Mount zu Wartungszeiten abgeschaltet werden muss.

Dann sollten Sie den Zugriff überwachen. Nextcloud bietet hierfür eine Reihe von Logs und Metriken, die sich bei externen Speichern häufig als besonders wertvoll erweisen. Wenn zum Beispiel ein Sync-Client immer wieder Fehler meldet, können Sie anhand der Protokolle erkennen, ob der externe Server die Zugriffe überhaupt erlaubt. Dazu gehört auch die Frage, ob das Backend schnell genug auf die Abfragen reagiert. Ein langsames NAS kann den gesamten Server ausbremsen, wenn Nextcloud versucht, alle Dateien für alle Benutzer zu scannen. Eine Auslastung, die mit externen Speichern gleichzeitig wächst, ist kein Zufall. Sie ist eine direkte Folge der zusätzlichen Netzwerkzugriffe.

Deshalb ist es ratsam, die Anzahl der externen Mounts klein zu halten. Wer fünfzig verschiedene FTP-Konten abbilden will, braucht eine umfassende Server-Infrastruktur und ein strenges Monitoring. Manchmal ist es sinnvoller, diese FTP-Konten in einem kleinen Dienst zu bündeln und nur einen einzigen Mountpunkt für die gesamte Bündelung anzubieten. Das erhöht die Chance, dass Performance-Probleme schnell erkannt werden, bevor sie die ganze Nextcloud lahmlegen.

Schließlich sollte das Backup-Konzept angepasst werden. Ein externer Mount, der nur ein weiteres Laufwerk darstellt, muss nicht zusätzlich über Nextcloud gesichert werden, wenn die Datenquelle ohnehin über ein eigenes Backup verfügt. Wenn der Mount jedoch Teil einer Cloud-Freigabe wird, müssen Sie sicherstellen, dass nicht das gesamte Nextcloud-Backup auf einmal versucht, sämtliche externen Daten einzusaugen. Das kann zu Kapazitäts- und Performance-Ausreißern führen. Besser ist es, die Backups nach Speicherklassen zu trennen und externe Speicher direkt beim Quellsystem zu sichern. In Nextcloud-Backups werden dann nur die Konfigurations- und Metadaten gesichert, was auch die Wiederherstellung vereinfacht.

Die Frage nach dem „Warum“

Für eine seriöse redaktionelle Betrachtung gehört am Ende die nüchterne Bilanz dazu. External Storage in Nextcloud ist keine Funktion, die man mal eben so einrichtet, um sie dann nie wieder anzufassen. Sie stellt den Admin, die Benutzer und letztendlich die Server-Hardware vor kontinuierliche Anforderungen. Wer das weiß, kann die Vorteile trotzdem nutzen – und die sind nicht zu unterschätzen. Das gilt vor allem für Unternehmen, die nicht den Luxus haben, ihre gewachsenen Strukturen über Nacht zu kappen. Eine Nextcloud, die auf ein bestehendes Netzwerk aufsetzt, wirkt wie ein Bindeglied, das alte und neue Technik zusammenbringt.

Dabei zeigt sich, wie wichtig Offenheit im Datenmanagement geworden ist. Wer sich konsequent gegen externe Speicher entscheidet, wird mit Nextcloud trotzdem gut arbeiten können. Wer sie aber nutzt, sollte es mit Bedacht tun. Ein externer Mount kann ein Geschenk sein, wenn er alte Daten rettet und Zugangsbeschränkungen elegant löst. Er kann aber auch zum Fluch werden, wenn er zu viele Abhängigkeiten schafft und die Administratoren vor einem Flickenteppich von Protokollen stehen lässt.

Vielleicht ist genau das die wichtigste Erkenntnis: nextcloud External Storage ist kein Selbstläufer. Es braucht den Dialog zwischen Serveradmins, Storage-Verantwortlichen und Benutzern, um die richtigen Verzeichnisse an die richtige Stelle zu setzen. Erst wenn diese Abstimmung gelingt, entsteht aus technischer Möglichkeit eine produktive Realität. Und dann ist es durchaus befriedigend, wenn der Kollege aus der Buchhaltung am Morgen das Netzlaufwerk nutzt, ohne zu ahnen, dass im Hintergrund SMB, SFTP und ein S3-Bucket zum Einsatz kommen. Die Cloud bleibt die Fassade, aber die zugrunde liegende Infrastruktur kann so vielfältig sein wie die Geschichte eines Unternehmens.