Nextcloud und der externe Speicher: Die Anbindung bestehender Systeme souverän meistern
Eine Beziehung, die man planen muss
Daten wachsen nicht linear. Sie wachsen sprunghaft, unregelmäßig, und meistens dorthin, wo gerade Platz ist. In vielen Organisationen sieht die Realität deshalb so aus: Ein vorhandenes NAS, ein älterer Fileserver auf Windows-Basis, ein SAN, das nie Cloud-Unterstützung erhalten wird, dazu ein paar Archive auf externen Laufwerken. Wenn dann die Entscheidung fällt, ein Werkzeug für kollaboratives Arbeiten einzuführen, fällt die Wahl nicht selten auf Nextcloud. Die Software ist Open Source, gut ausgereift und in unzähligen Unternehmen im Einsatz. Doch anstatt die vorhandenen Speichersysteme einfach zu ersetzen, was selten wirtschaftlich wäre, wird eine Integration benötigt. Und hier setzt das Konzept des „externen Speichers“ in Nextcloud an.
Der Begriff führt ein wenig in die Irre, das sollte man gleich zu Beginn erwähnen. „Extern“ meint nicht USB-Festplatten oder entfernbare Speicherkarten am Server, obwohl das technisch auch möglich wäre. Gemeint ist alles, was sich außerhalb des standardmäßigen Datenverzeichnisses der Nextcloud-Installation befindet, aber trotzdem in die Plattform eingebunden werden soll. Objektspeicher wie OpenStack Swift oder S3-Buckets von Amazon, scalable Anbieter wie Hetzner oder das selbst gehostete MinIO gehören genauso dazu wie klassische Netzwerkdateisysteme, FTP-Server oder auch einfache lokale Verzeichnisse, die nicht im Standardpfad der Installation liegen. „Extern“ ist also weniger im physikalischen Sinne zu verstehen, sondern eher im Sinne von „extern verwaltet“ oder „anderswo aufgestellt“.
Die Motivation für eine solche Anbindung leuchtet schnell ein. Kein Administrator wirft gern Speicherplatz weg, der über Jahre gewachsen ist und auf dem noch tausende Dateien lagern. Und niemand möchte eine komplette Datenmigration durchführen, nur weil ein neues Werkzeug eingeführt wird. Nextcloud trägt diesem Umstand von Haus aus Rechnung. Es gibt eine integrierte Schnittstelle, die es erlaubt, eine Vielzahl von Speicherbackends anzuschließen und in den eigenen Verzeichnisbaum zu integrieren. In der Theorie klingt das verlockend, in der Praxis zeigen sich allerdings einige Hürden, die man kennen sollte, bevor man den Schalter umlegt.
Die Kunst der Anbindung: Was Nextcloud an Protokollen versteht
Was Nextcloud an externen Speicherprotokollen unterstützt, kann sich durchaus sehen lassen. Es gibt kaum ein anderes Cloud-Paket in dieser Liga, das eine ähnliche Bandbreite anbietet. Die Liste beginnt mit den eher klassischen Netzwerkprotokollen und reicht bis zu modernen Objektspeicherschnittstellen.
Da ist zunächst der Zugriff auf lokale Verzeichnisse und Geräte, etwa eine zusätzliche Festplatte im Server oder ein Verzeichnis auf einer iSCSI-LUN. Das klingt unspektakulär, ist aber ein interessanter Anwendungsfall: Auf diese Weise lässt sich zum Beispiel ein zentrales Ablageverzeichnis eines Unternehmens direkt in Nextcloud einbinden, ohne Daten zu kopieren. Da das Ganze über das normale Dateisystem des Betriebssystems läuft, sind auch die Zugriffsrechte des Servers dahinter zu beachten – Nextcloud gibt nur das weiter, was der Linux-User kann, unter dem die PHP-Prozesse laufen.
Weiter geht es mit SMB und CIFS, den Protokollen aus der Windows-Welt. Für viele Unternehmen ist das vermutlich der wichtigste Fall: da steht ein alter Windows-Server oder ein Synology-NAS, die Belegschaft nutzt das seit Jahren als Laufwerk. Nun soll Nextcloud das gleiche Datenpaket anbieten, ohne dass die alten Laufwerksbuchstaben verschwinden müssen. SMB-Verbindungen in Nextcloud einzurichten ist grundsätzlich kein Hexenwerk, aber es gibt Feinheiten: Die SMB-Version muss kompatibel sein, alte Server mit SMB1 sollte man ohnehin aus Sicherheitsgründen ausmustern, und die Zugangsdaten für den Montagepunkt wollen gepflegt sein. Nextcloud beherrscht gängige SMB-Versionen und kann auch auf verschlüsselte Verbindungen. Letzteres ist aber häufig eine Sache, die auf der Zielseite konfiguriert werden muss.
Parallel dazu existiert NFS, das Unix-Protokoll auf Netzwerkebene. Das wird gern unterschätzt. Dabei ist NFS in heterogenen Umgebungen oft die beste Wahl, weil es ohne Passwortverwaltung auskommt und sehr stabil läuft. Allerdings kann Nextcloud hier nicht direkt auf NFS-Zugriffe zugreifen, sondern braucht einen Client-Mount im Betriebssystem. Das ist ein wichtiger Punkt: Das NFS-System wird nicht in der Weboberfläche der Nextcloud eingestellt, sondern muss zuerst als klassisches Verzeichnis auf dem Server gemountet werden. Erst danach kann man es in Nextcloud als „lokalen“ Ordner einbinden. Das ist ein Umweg, den viele zunächst nicht auf dem Schirm haben. Es funktioniert aber gut und ist weit verbreitet.
Dann wären da FTP und SFTP. FTP ist aus Sicherheitsgründen nur bedingt zu empfehlen, es sei denn, es geht um eine reine Lesestrecke für Daten, die ohnehin öffentlich zugänglich wären. SFTP ist da schon vernünftiger, weil es die Verschlüsselung mitliefert. Beide Protokolle sind in Nextcloud direkt als externe Speichertypen anwählbar. In der Praxis seltener anzutreffen, aber interessant: Nextcloud kann sich auch mit WebDAV-Servern verbinden, also zum Beispiel mit einem anderen Nextcloud-Server oder mit einem WebDAV-fähigen Groupware-System. Damit lassen sich zwei Nextcloud-Instanzen koppeln, was in größeren Organisationen mit eigenen Abteilungsinstanzen durchaus vorkommt.
Am anderen Ende des Spektrums liegen die Objektspeicher. Nextcloud unterstützt S3-kompatible Systeme, aber auch ältere und neuere Varianten von OpenStack Object Storage. In der Praxis dominieren heutzutage S3-Schnittstellen, weil sie zum Quasi-Standard geworden sind, nicht zuletzt durch die Public-Cloud-Anbieter und die vielen kompatiblen Systeme. MinIO ist da zu nennen, Alibaba, die skalierbaren Angebote von DigitalOcean, Scaleway, Exoscale – die Liste ist lang. Bei S3 ist zu beachten, dass Nextcloud die Daten nicht im klassischen Sinne als verschachtelten Ordner ablegt, sondern in einem Bucket unter einem internen Namensschema. Das heißt, wer auf das Material von außen über S3-Tools zugreifen will, sieht eine Struktur, die mit der Nextcloud-Ordnerstruktur zunächst wenig zu tun hat. Es ist eine etwas arbeitsame Konstruktion, aber für diejenigen, die mit Objektspeichern arbeiten, kein echtes Hindernis. Wichtiger ist in diesem Zusammenhang, dass S3 von Nextcloud als Primärspeicher konfiguriert werden kann – also als Hauptablage, nicht nur als externer Anhang. Das ist eine andere Baustelle als das klassische externe Speicher-Modul.
Die Einrichtung in der Praxis: Vom Admin-Interface bis zur Kommandozeile
Die gängigste Art, externen Speicher in Nextcloud einzubinden, führt über das Administrations-Interface. Dazu muss das entsprechende Modul – die „Externer Speicher“-App – installiert und aktiviert sein. In den meisten Distributionen ist es optional, bei einigen Systemen wird es bereits vorinstalliert ausgeliefert. Man findet es in der App-Verwaltung unter dem Namen „External storages support“. Nach der Aktivierung erscheint im Admin-Bereich der Punkt „Externer Speicher“ bzw. je nach Sprachversion „Externe Speichermedien“.
Interessant ist, dass Nextcloud hier eine Unterscheidung erlaubt: Man kann Speichertypen konfigurieren, die global für alle Benutzer gelten, oder solche, die nur für bestimmte Benutzergruppen verfügbar sind. Auch eine alleinige Nutzung durch einzelne Benutzer ist vorgesehen. Damit lässt sich das System sehr flexibel gestalten. Eine typische Konfiguration wäre beispielsweise: Die Abteilung „Buchhaltung“ bekommt einen SMB-Mount auf den alten Windows-Server, während die Entwicklungsabteilung einen S3-Bucket angebunden bekommt. Es gibt also nicht den einen externen Speicher, sondern viele verschiedene, die je nach Kontext ihre Berechtigungen besitzen.
Beim Anlegen eines Mount-Punktes gibt man einen Namen an, der später in der Dateiliste der Benutzer erscheint. Dann wählt man den Typ, etwa SMB, und gibt die Verbindungsdaten ein. Für SMB oder SFTP werden Host, Port, Benutzername und Passwort beziehungsweise der Ordnerpfad angegeben. Für S3 werden ein Access Key, ein Secret Key sowie der Bucket-Name und Endpunkt benötigt. Die Anbindung eines lokalen Verzeichnisses erfordert nur die Angabe des absoluten Pfades auf dem Server. In der Regel testet Nextcloud die Verbindung sofort. Ein kleines Icon zeigt an, ob der Zugriff erfolgreich war oder ob die Konfiguration korrigiert werden muss.
Für Administratoren, die lieber in der Konfigurationsdatei arbeiten oder automatisierte Setup-Verfahren verwenden, ist der Blick in die Datei „config.php“ beziehungsweise in spezielle External-Storage-Config-Dateien empfehlenswert. Nextcloud erlaubt es, Mount-Punkte über die Datei „data/external/…“ oder über die systemweite Konfiguration abzulegen. In großen Umgebungen mit vielen hundert Nutzern und zahlreichen Storage-Backends ist die YAML- beziehungsweise PHP-generierte Konfiguration manchmal einfacher zu pflegen als die Klick-Arbeit im Webinterface. Eine saubere Dokumentation ist dabei unerlässlich, denn was per GUI konfiguriert wird, ist nicht immer aus der Kommandozeile heraus nachvollziehbar.
Ein Detail am Rande: Nicht jede Konfiguration ist im ersten Anlauf fehlerfrei. Das liegt nicht unbedingt an Nextcloud, sondern an der Vielzahl der Zielsysteme. Ein SMB-Server, der keine Lust auf Verhandlungen über das Protokoll hat, eine Firewall die den NFS-Port blockiert, oder ein S3-Endpunkt, der nur über IPv6 erreichbar ist – der Fehlerteufel steckt im Detail. Ein Blick in die Logdateien der Nextcloud-Instanz ist dann Pflicht. Und manchmal hilft es, den externen Speicher über das Kommandozeilenprogramm „occ“ zu debuggen, auch wenn dieser Weg weniger ausgetreten ist.
Wer darf was? – Rechte, Rollen und die Sache mit den Anmeldedaten
Die Frage der Berechtigungen ist bei externem Speicher meistens komplexer, als man im ersten Moment vermuten würde. Zwei Ebenen treffen aufeinander: die Zugriffskontrolle der Nextcloud-Benutzer und die Zugriffskontrolle des Zielsystems. Ein Beispiel zur Verdeutlichung: Es gibt einen SMB-Share auf einem alten Windows-Fileserver. Dort ist der Benutzer „Müller“ eingerichtet, der nur Leserechte auf den Ordner „Öffentlich“ hat. In Nextcloud wird derselbe Benutzername zugeordnet – dann passt es. Doch was passiert, wenn ein Nextcloud-Benutzer „Schmidt“ denselben Mount-Punkt sehen soll, aber auf dem Windows-Server gar nicht existiert? Genau hier liegt die Crux der externen Speicher-Medien in Nextcloud.
Für solche Fälle gibt es das Konzept der „Anmeldedaten des Benutzers“ und der „gespeicherten Anmeldedaten“. Wenn man als Administrator eine globale Anbindung einrichtet, kann man festlegen, ob die Benutzer ihre eigenen Zugangsdaten für das Zielsystem angeben müssen oder ob zentral hinterlegte Credentials verwendet werden. Bei einem SMB-Server mit Windows-Authentifizierung ist die Variante „login credentials“ oft die eleganteste Lösung, weil jeder Benutzer genau die Rechte bekommt, die ohnehin in der Active Directory hinterlegt sind. Dafür muss Nextcloud in der Lage sein, die Benutzer mit ihren Passwörtern an den SMB-Server weiterzureichen, was bei LDAP-Anbindung in der Regel funktioniert.
Die Alternative, nämlich zentral hinterlegte Anmeldedaten, ist einfacher zu verwalten, hat aber einen Haken: Alle Benutzer teilen sich denselben Zugang. Die Rechte kann man dann nur noch auf Nextcloud-Ebene einschränken, nicht mehr auf der des Dateisystems. Dateien, die über einen solchen Mount-Punkt geschrieben werden, tragen die Identität des gemeinsamen Dienstkontos. Das macht die Sache später auf dem Zielsystem unübersichtlich – insbesondere bei der Frage, wer welche Datei zuletzt geändert hat. Für reine Verteil-Dateiserver ist das akzeptabel, für aktive Teamarbeit nur eine Krücke.
Ein weiterer wichtiger Aspekt sind die Berechtigungen innerhalb der Nextcloud. Der Administrator kann für jeden Mount-Punkt überprüfen, ob er im Verzeichnisbaum der Benutzer sichtbar sein darf, ob er schreibbar oder schreibgeschützt ist und ob Verschlüsselung verwendet wird. Diese Optionen sind nicht zu verwechseln mit den reinen Dateisystemrechten des Zielsystems – sie ergänzen sich lediglich.
Sicherheit: Die doppelte Baustelle
Wenn es um externe Speicher geht, machen sich viele Anwender zu wenige Gedanken über die Sicherheit. Dabei gibt es mindestens zwei Baustellen. Die erste betrifft die Transportverschlüsselung. Bei S3-Verbindungen ist HTTPS normalerweise Standard, bei SMB muss gegebenenfalls SMB über TLS konfiguriert werden, und bei FTP sollte man sich sowieso fragen, warum man das 2025 noch ohne Verschlüsselung macht. NFS sollte nur über gesicherte Netze laufen oder mit Kerberos abgesichert werden. Nextcloud selbst kann diese Verschlüsselung nicht erzwingen, wenn die Gegenseite sie nicht beherrscht. Das ist ein Punkt, den man auch in der Dokumentation des jeweiligen Speichersystems nachlesen muss.
Die zweite Baustelle ist die auf dem Server liegende Verschlüsselung. Nextcloud kann Daten auf dem Speichermedium verschlüsseln. Bei einer normalen Installation geschieht das standardmäßig nicht. Aktuelle Varianten von Nextcloud bieten jedoch eine serverseitige Verschlüsselung an, die auch für externe Speicher verwendet werden kann. Das klingt verlockend, führt aber zu einer Eigenheit: Die Dateien werden dann verschlüsselt auf dem Zielsystem abgelegt, und die Schlüssel werden in der Nextcloud-Instanz verwaltet. Wenn Sie das in einem S3-Bucket bei einem Public-Cloud-Anbieter speichern, ist der Anbieter nicht in der Lage, den Inhalt zu lesen – ein gutes Gefühl in Bezug auf Datenschutz, allerdings auch mit einer Verpflichtung verbunden: Wer die Keys verliert, verliert den Zugriff auf die Daten.
Im Zusammenhang mit externem Speicher ist auch das Thema der verschlüsselten Übertragung an die Benutzer zu nennen. Nextcloud übernimmt die Daten vom externen Speicher und serviert sie über HTTPS am Browser. Das ist Standard – aber nur, wenn die Webseite ordentlich mit TLS konfiguriert ist. Klingt banal, ist es nicht, denn in der Praxis findet man immer wieder Installationen, die nur über HTTP erreichbar sind. Dass dies auch die externen Mount-Punkte betrifft, wird gerne übersehen.
Eine eher unangenehme Geschichte ist auch der Umgang mit Löschungen. Wenn ein Benutzer in Nextcloud eine Datei entfernt, die auf einem externen SMB-Server liegt, verschwindet sie in der Regel auch dort – es sei denn, man hat eine Versionierungs- oder Mülleimerfunktion, die das abfängt. Bei manchen externen Speichern wie NFS oder SMB ist die Löschung unumkehrbar, wenn die Gegenseite keine Snapshots erstellt. Dabei zeigt sich immer wieder, wie wichtig es ist, die Löschkonzepte nicht nur für den Nextcloud-Hauptspeicher zu dokumentieren, sondern auch für die angebundenen externen Systeme. Im Ernstfall kann ein Versehen dazu führen, dass ganze Ordnerstrukturen unwiederbringlich verloren gehen. Backups der externen Bestände müssen also unabhängig von Nextcloud existieren.
Performance – Der Flaschenhals ist die Leitung
Ein externer Speicher in Nextcloud ist im besten Fall genauso schnell wie der lokale Speicher der Plattform. Im schlechtesten Fall ist er die sprichwörtliche Datenautobahn im Berufsverkehr. Die Performance wird durch mehrere Faktoren bestimmt: die Latenz des Protokolls, die Bandbreite zwischen Nextcloud-Server und Zielsystem sowie die Zugriffsmechanismen auf dem Zielgerät.
Bei SMB etwa hat jede einzelne Dateioperation einen gewissen Overhead. Wenn Nextcloud für eine Ordneransicht hunderte Dateiattribute über SMB abfragen muss, spürt man das unmittelbar in der Web-Oberfläche. Die Entwickler versuchen zwar, das durch einen Kcache zu optimieren, also im Kernsystem einen Cache aufzubauen, aber bei einer hohen Anzahl von Dateien und vielen Benutzern bleibt die Latenz trotzdem ein Thema. Manchmal hilft es, die Mount-Punkte in der Nextcloud zu drosseln oder den externen Speicher nur für bestimmte Bereiche zu verwenden, zum Beispiel für lesende Archiv-Zugriffe.
S3-Systeme sind in der Regel schneller als klassische Filer-Protokolle, wenn es um Parallelzugriffe geht. Allerdings können S3-Einzelkopfdateien zu Verzögerungen bei sehr vielen kleinen Dateien führen. Nextcloud erzeugt pro Datei mehrere S3-Requests, das kann bei einer Ordnerübersicht mit tausend PNG-Bildern zu einem ernsthaften Problem werden. Ein guter S3-Endpunkt mit niedriger Latenz ist hier das A und O. Oft genügt es, den externen Speicher im selben Rechenzentrum zu platzieren wie die Nextcloud-Instanz.
Wichtig ist außerdem die Integration von Caching-Layern. Nextcloud kann einen Speicher-Cache verwenden, üblicherweise über Redis oder APCu. Das hilft bei der Ablage von Metadaten und Session-Daten, nicht unbedingt bei großen Dateien selbst. Für viele Dateien lohnt es sich trotzdem, den Cache zu aktivieren, weil viele Zugriffe auf denselben SMB/Share oder S3-Bucket dadurch erheblich beschleunigt werden.
Auch die Hardware des Servers spielt eine Rolle. Ein Nextcloud-Server mit eingebautem SATA-Speicher und begrenztem Arbeitsspeicher wird bei externen Mounts schnell zum Flaschenhals. Womit wir bei einer wichtigen Erkenntnis wären: Externer Speicher ist kein Ersatz für eine gute Serverausstattung, sondern eher eine Ergänzung. Ein schneller SPINN – sprich SSD-basierter Hauptspeicher für Nextcloud und große externe Systeme für weniger frequentierte Daten – das ist eine bewährte Konfiguration in der Praxis.
Anwendungsfälle – Mehr als nur ein Datenquartier
Der Blick auf die verschiedenen Einsatzmöglichkeiten von externem Speicher ist aufschlussreich, weil er das Werkzeug besser verstehen lässt als jede technische Doku.
Der erste und verbreitetste Anwendungsfall ist die Integration eines bestehenden Fileservers. Da ist eine Firma mit hundert Mitarbeitenden, die bisher auf einem zentralen Windows-Server ihre Ablage hatten. Die Geschäftsleitung möchte eine moderne Plattform für mobile Zusammenarbeit und De-Instrumente einführen. Nextcloud wird als Kollaborationsplattform eingerichtet, aber die Daten bleiben zunächst dort, wo sie sind – auf dem alten Server. Die Benutzer sehen neben ihren neuen Nextcloud-Dateien einen zusätzlichen Ordner, der auf den alten Fileserver zeigt. Das funktioniert überraschend gut und nimmt den Druck, eine komplette Migration sofort durchführen zu müssen.
Ein weiterer Anwendungsfall betrifft die Archivierung. Viele Unternehmen nutzen Nextcloud als aktiven Arbeitsbereich, haben aber eine Datenmenge, die keiner mehr wirklich braucht – die aber aus gesetzlichen oder firmenpolitischen Gründen vorgehalten werden muss. Diese Daten liegen beispielsweise auf einer externen S3-Plattform oder einem NFS-Mount und werden über Nextcloud weiterhin lesbar gehalten. Die Benutzer können alte Projekte durchsuchen, ohne die neueren Arbeitsumgebungen mit diesen Altlasten zu belasten.
Sehr verbreitet ist auch die Nutzung von externem Speicher für Backups. Nextcloud kann Datenbestände nicht nur vom externen Speicher lesen, sondern auch in einen Externen schreiben, etwa als Ziel für die hauseigene Datensicherung. In Kombination mit der Verschlüsselung ist das eine interessante Möglichkeit, um die Datensicherung auf ein externes Storage zu verlagern. Allerdings sollte man berücksichtigen, dass eine Nextcloud-Umgebung mit externen Speicher-Mounts nicht automatisch ein Backup des externen Speichers einschließt. Das gängige Nextcloud-eigene Backup-Tool sichert nur die Daten, die im Nextcloud-Verzeichnis liegen – also in der Regel nicht die externen Systeme.
Ein interessanter Aspekt ist die Nutzung von S3-Speicher als Primärspeicher für Nextcloud, kombiniert mit einem zusätzlichen externen Speicher für andere Daten. Beispielsweise können die Benutzerdaten in einem S3-Bucket abgelegt werden, während systembedingte Daten wie Applikationsdaten auf einem lokalen schnellen Speicher liegen. Das ist eine Architektur, die in der Cloud und bei größeren Installationen immer beliebter wird. Allerdings ist hier der Übergang zwischen „externem Speicher“ im engeren Sinne und „primärem Speicher“ fließend. Nextcloud konfiguriert dabei den ganzen Datenbestand um, was man nicht mit einem einfachen Mount verwechseln darf.
Hinzu kommen die eher exotischen Fälle: Die Kopplung zweier Nextcloud-Instanzen über WebDAV, damit Abteilungen Daten austauschen können, ohne alles über ein E-Mail-Anhang zu schicken. Oder die Einbindung eines FTP-Servers von einem Großkunden, der seine Daten ausschließlich über FTP liefert. Das ist zwar nicht die feine Art, aber mit Nextcloud externem Speicher kann man diese Daten immerhin auf eine einheitliche Plattform heben und dann weiterverarbeiten. Diese Flexibilität ist ein nicht zu unterschätzender Vorteil gegenüber vielen kommerziellen Cloud-Diensten, die eine Integration solcher Legacy-Verfahren nicht anbieten.
Stolpersteine und Grenzen – Wie die Wirklichkeit die Theorie bricht
So sehr die externen Speicher in Nextcloud ein mächtiges Werkzeug sind – man muss sich der Grenzen bewusst sein. Ein erstes Problem ist die mangelnde Transparenz der Zugriffsrechte. Wenn ein Benutzer eine Datei auf dem externen Speicher ablegt, kann er nicht unmittelbar sehen, ob die Datei den Rechten der externen Plattform entspricht. Ein SMB-based Mount-Punkt schreibt beispielsweise mit den Rechten des Dienstkontos; die Benutzerrechte von Nextcloud steuern lediglich den Zugriff innerhalb der Plattform. So kann es passieren, dass eine Datei, die ein eingeschränkter Benutzer über Nextcloud hochgeladen hat, auf dem externen System mit den Berechtigungen des Dienstkontos abgelegt ist. Kommen dann noch die Standard-Einstellungen von Nextcloud für neue Dateien ins Spiel, kann es sein, dass die Datei später auch für Personen sichtbar wird, die sie nie hätten sehen dürfen. Der Administrator muss also eine sehr gründliche Konfiguration vornehmen, um diese Szenarien zu vermeiden.
Ein weiterer Stolperstein ist die Geschwindigkeit. Was auf dem Papier schnell zugesagt wird, entpuppt sich in der Praxis oft als langsame Angelegenheit, insbesondere beim SMB-Zugriff über komplizierte Netzwerkpfade. Auch der Zugriff auf S3-Buckets, die nicht in der unmittelbaren Nähe des Nextcloud-Servers liegen, kann so langsam werden, dass die Nutzer das Gefühl haben, die Plattform sei kaputt. Der Grund dafür sind die vielen seriellen Anfragen, die Nextcloud an den Objektspeicher sendet. Ein späterer Test mit „occ files:scan“ und einem großen Verzeichnisbaum zeigt schnell, wo der Schuh drückt.
Dazu kommt das Problem der Zuverlässigkeit. Der externe Speicher ist ein weiteres Glied in der Kette, das ausfallen kann. Ist der SMB-Server nicht erreichbar, zeigt Nextcloud den Ordner zwar an, aber der Zugriff darauf schlägt fehl. Ein Administrator kann solche Ausfälle im Log nachverfolgen, aber für die Benutzer sind diese Ausfälle schwer zu durchschauen. Sie sehen plötzlich einen Ordner, der einfach nicht mehr reagiert. Wenn sich dieser Zustand über Stunden hinzieht, ist das Vertrauen in die Plattform schnell beschädigt. Es empfiehlt sich, eine Überwachung der externen Mount-Punkte einzurichten, zum Beispiel über die Monitoring-Schnittstelle von Nextcloud oder über externe Tools, die die Erreichbarkeit der Zielsysteme prüfen.
Auch die Dateikompatibilität spielt eine Rolle. Das S3-Dateiformat, das Nextcloud intern anlegt, ist nicht identisch mit der Ordnerstruktur, die der Anwender in der Web-Oberfläche sieht. Wer also glaubt, er könnte den S3-Bucket einfach per S3-Client mit eigenen Tools durchsuchen und dort direkt Dateien verändern, wird eine böse Überraschung erleben. Die Dateien werden in Objekte aufgeteilt und mit einer weiteren Struktur abgelegt, die nur von Nextcloud selbst interpretiert werden kann. Direkte Eingriffe von außen müssen daher als sehr kritisch betrachtet werden.
Ein weiteres kleines, aber feines Problem liegt im Versionsmanagement. Nextcloud kennt für seine eigenen Dateien eine Versionskontrolle, die allerdings nur für den Eigenspeicher der Plattform funktioniert, nicht für externe Speicher. Ein Administrator, der also daran denkt, die Versionsfunktionen auch für die gealteten Daten auf externen Laufwerken zu nutzen, steht schnell auf der Bremse. Man muss sich entscheiden: Entweder man nutzt die Versionskontrolle von Nextcloud und kopiert die Daten in den Hauptspeicher, oder man verzichtet darauf und verlässt sich auf die Versions- und Backup-Fähigkeiten des externen Systems.
„Gelegentlich ist die externe Anbindung einfach nicht zu gebrauchen“, sagt mancher Kollege nach einem frustrierenden ersten Test mit einem alten NAS. Aber es liegt nicht immer an der Software, sondern oft an der unzureichenden Qualität des Zielsystems. Alte NAS-Geräte ohne ausreichende CPU-Power sind mit SMB-Zugriffen überfordert, und die Reaktionen im Filesystem sind entsprechend zäh. Ein solches Gerät taugt im besten Fall noch als Archivspeicher, kaum aber als aktiver Arbeitsbereich.
Best Practices – Aus Erfahrung wird man klug
Was lässt sich also raten, wenn man externen Speicher in Nextcloud produktiv einsetzen will? Zunächst einmal: Nicht alles extern anbinden, was nicht niet- und nagelfest ist. Die saubere Planung spart später viel Schmerz. Dazu gehört auch die Frage, welche Speicherarten überhaupt benötigt werden. Viele Anwender binden einen S3-Bucket nur deshalb ein, weil er modern klingt, obwohl ein klassischer SMB-Share vom alten Server die Anforderungen besser abdeckt. Man muss also vom Anwendungsfall ausgehen und nicht von der verfügbaren Technologie.
Weiterhin sollte man das Prinzip der geringsten Rechte konsequenz anwenden. Neben der Frage, welche Nextcloud-Nutzer einen Mount-Punkt sehen, ist die Frage der Schreibrechte auf dem externen System genauso wichtig. Für Archive bietet sich meist die read-only-Variante an. Für Kollaboration mit einem Dienstkonto sollte man prüfen, ob der externe Speicher wirklich das richtige Werkzeug ist oder ob die Synchronisation in den Nextcloud-Hauptspeicher nicht doch besser wäre. Die Devise lautet: Externer Speicher für den Kurzzugriff, Nextcloud-Hauptspeicher für die Arbeit.
Ein weiteres Element ist die Dokumentation. Wer einen externen Mount-Punkt einrichtet, sollte sich die Zeit nehmen, die genauen Parameter zu notieren – nicht nur im Head-Admin-Bereich, sondern auch in einer Textdatei, die zum unmittelbaren Projekt gehört. Dazu gehören Hostnamen, Bucket-Namen, Zugangsdaten, spezielle Protokolloptionen und die Einzelheiten der Verzeichnisfreigabe. Gerade bei einem Wechsel des Administrators ist dieses Wissen Gold wert. Nicht selten geraten solche Informationen über Jahre in Vergessenheit, bis der S3-Anbieter einen neuen Endpunkt bekommt und niemand mehr weiß, was in der Nextcloud-Konfiguration zu ändern ist.
Administratoren sollten außerdem ein enges Monitoring einrichten, wie bereits erwähnt. Eine gut konfigurierte Nextcloud kann Warnungen über nicht erreichbare externe Speicher ausgeben. In größeren Umgebungen bietet es sich an, die externen Mount-Punkte in die bestehende Überwachungslandschaft einzubinden – seien es Prometheus, Zabbix oder andere Systeme. Denn ein Storage-Ausfall ist kein Problem, solange er bemerkt wird. Wird er nicht bemerkt, haben die Benutzer den Frust und die IT-Abteilung die Erklärungsnot.
Wichtig ist auch die regelmäßige Überprüfung der Anmeldedaten. Die Zeiten, in denen Zugangsdaten alle paar Monate durch rotierende Passwortrichtlinien geändert werden, sind vielerorts angekommen. Wenn sich aber das Passwort des SMB-Dienstkontos ändert, ohne dass die Nextcloud-Konfiguration angepasst wird, bleibt die Anbindung still stehen. Es lohnt sich, für die externen Speicher in Nextcloud eigene technische Benutzer einzurichten, die keinem menschlichen Mitarbeiter direkt zugeordnet sind. Dann bleibt die Anbindung unabhängig von personellen Wechseln.
Und schließlich muss man einplanen, dass externe Speicher in Nextcloud auch ein Stück weit experimentell sein können. Es gibt Projekte, da funktioniert S3 auf Anhieb, und andere, bei denen man andauernd mit Berechtigungsproblemen kämpft. Das hängt oft von den Eigenheiten des jeweiligen Systems ab. Einige S3-Anbieter haben mit bestimmten Sicherheitseinstellungen zu kämpfen, andere verhalten sich nicht hundertprozentig korrekt bei der Umsetzung der Spezifikation. Der nächste Test mit einem anderen kompatiblen Anbieter hilft bei der Fehlersuche manchmal mehr als alle Dokumentation.
Der Platz im großen Ganzen
Nextcloud und externer Speicher sind kein Widerspruch, sondern ein gutes Gespann, wenn man die Regeln kennt. Das „externe Speicher“-Modul ist eines der flexiblen Werkzeuge, die Nextcloud von geschlossenen Cloud-Diensten unterscheiden. Es schafft die Brücke zu Bestandssystemen und verhindert, dass vorhandene Infrastruktur auf der Müllhalde der IT-Geschichte landet. Aber es ist auch eine Aufgabe, die Wartung und Konzept verlangt.
Wer sich auf dieses Modul einlässt, sollte nicht den Fehler machen, es als einmalige Konfigurationsaufgabe zu betrachten. Der externe Speicher verlangt nach einer Pflege-Routine, denn die zugrunde liegenden Systeme ändern sich: Der Fileserver wird ersetzt, der Objektspeicher bekommt einen neuen Endpunkt, oder es kommen neue Abteilungen hinzu, die Zugriff auf andere Archive brauchen. Insofern ein gutes Zeichen, dass Nextcloud dieses Gebiet ernst nimmt und kontinuierlich weiterentwickelt. Die Koppelung der Plattform an bestehende Speicherlandschaften ist kein Einfall von gestern, sondern ein zentraler Baustein in der digitalen Infrastruktur vieler Organisationen.
Bei allem Lob muss aber auch die Ernüchterung Platz haben. Der externe Speicher von Nextcloud ist kein Wundermittel und ersetzt keine Migration. Er ist eine Hilfe, aber keine Entschuldigung für fehlende Datenarchitektur. In Systemen, in denen die externe Anbindung unkontrolliert wächst, entstehen neue Silos – ausgerechnet jener Zustand, den eine Plattform wie Nextcloud eigentlich auflösen will. Wer also einen externen Speicher einrichtet, sollte sich stets die Frage stellen: Dient dieser Mount-Punkt der Vereinfachung der Struktur oder verkompliziert er sie? Im Zweifel ist eine saubere Ablage im Hauptspeicher und ein gut geplantes Backup die robustere Lösung als ein Mount auf eine alte Kiste im Keller.
Letztlich zeigt sich, dass Nextcloud mit dieser Funktion eine Lücke schließt, an der manche kommerzielle Konkurrenz scheitert. Die Möglichkeit, vorhandene Protokolle und Speichersysteme in ein modernes, sicheres Kollaborationsumfeld zu integrieren, ist mehr als ein Baustein in der Admin-Oberfläche. Sie eröffnet neue Wege, die eigene Infrastruktur zu denken – ohne die Vergangenheit zu ignorieren. Das ist ein Wert, der in der Praxis oft höher eingeschätzt wird als jeder Neukunst-Hype um den neuesten Objektspeicher. Und wenn die Anbindung sauber geplant, dokumentiert und überwacht ist, dann funktioniert diese Kombination aus Alt und Neu besser, als viele Skeptiker glauben.
Ob man dabei auf SMB, NFS, S3 oder WebDAV setzt, hängt von der eigenen Umgebung ab – nicht vom technischen Reiz des Neuen. Der geübte Administrator erkennt schnell, welcher Weg der richtige ist: Er wählt den, der die geringsten Reibungspunkte mit der bestehenden Struktur bedeutet. Und das ist, bei aller Liebe zur Technik, oft der unaufgeregteste Weg.