Die unsichtbare Datei: Volltextsuche in Nextcloud mit Elasticsearch

Es beginnt mit einem kleinen Rätsel, das vermutlich jeder kennt, der ein Nextcloud-System einigermaßen ernsthaft betreibt. Man sucht ein Dokument, weiß, dass es im Cloud-Verzeichnis liegt, hat sogar eine ungefähre Ahnung, in welchem Projektordner es gelandet ist – und wird doch nicht fündig. Der Dateiname ist nichtssagend, die Titelinformation in den Metadaten fehlt, und das PDF ist das Produkt eines Scanners. Die Dateisuche von Nextcloud vergleicht dann nur die Metadaten, was nicht weiterhilft. Der gesuchte Begriff steht gut sichtbar auf Seite drei, ist aber für die Datenbank unsichtbar. Ein Ärgernis, das manche dazu verleitet, doch wieder Dateien auf dem lokalen Rechner zu duplizieren, um sie über die Suchfunktion des Betriebssystems zu finden. So viel zum Thema zentrale Ablage.

Nehmen wir ein konkretes Szenario aus dem Arbeitsalltag eines mittelständischen Unternehmens. Die Support-Abteilung hat über die Jahre Tausende von Angeboten, internen Protokollen und Vertragspdf-Dateien in Nextcloud gesammelt. Ein Mitarbeiter erinnert sich, dass es irgendwann eine Eskalationsvereinbarung gab, in der Wartungsfenster für die Server der Zentrale festgehalten waren. Natürlich weiß niemand mehr den Dateinamen. Ein paar Suchversuche mit dem eingebauten Dateifilter liefern nichts. Die Vertragspdf liegt irgendwo, verschüttet unter fünf Ebenen Ordnernavigation. In einer solchen Situation zeigt sich der Unterschied zwischen bloßer Ablage und echter Wissensorganisation. Die Nextcloud Full Text Search – im Fachjargon nicht zu verwechseln mit der simplen Tabellensuche in MySQL oder PostgreSQL – löst genau dieses Problem.

Die Erweiterung legt einen regelrechten Inhaltsindex über alle verknüpften Datenquellen. Und im Zentrum dieses Indexes steht mit Elasticsearch ein Suchserver, der eigens dafür gebaut wurde, auch riesige Textmengen in Sekundenbruchteilen zu durchsuchen. Ein Begriff, der in einer Datei steckt, wird so auffindbar, als wäre er ein Tag, der wie ein Etikett an der Datei klebt. Klingt simpel, ist aber in der Praxis ein kleines ingenieurstechnisches Wunderwerk. Gerade der deutsche Markt tut sich mit solchen Systemen manchmal schwer, weil eine Volltextsuche ja angeblich „aufwendig“ sei. In Wahrheit ist sie nur ein weiteres Datenverwaltungstier, das gut gefüttert werden will. Doch der Reihe nach.

Was die Volltextsuche in Nextcloud wirklich ist

Nextcloud kennt eine einfache Suche, die sich auf Dateinamen, Ordner, Tags und einige Metadaten bezieht. Sie arbeitet mit den Bordmitteln der Datenbank und ist für kleine Installationen durchaus brauchbar. Bei großen Datenbeständen werden die Abfragen langsamer, und vor allem bleiben die Inhalte unsichtbar. Genau hier setzt die Volltextsuche an. Sie durchsucht nicht nur die Namen, sondern den Text der Dateien selbst. Dazu wird aus jedem Dokument der Text extrahiert, zerteilt, in einem Index abgelegt und über eine Suchmaschinen-API durchsuchbar gemacht.

Der offizielle Name „Full text search“ steht dabei für ein Modulsystem. Das ist einerseits elegant, andererseits für Einsteiger verwirrend. Es gibt nicht eine App, die man installiert und fertig. Es gibt ein Grundgerüst, ein Backend und die eigentlichen Datenquellen. Das Grundgerüst heißt schlicht „Full text search“ und stellt die abstrakte Schnittstelle bereit. Darum herum gruppieren sich weitere Apps: Der Treiber für Elasticsearch trägt den Namen „Full text search – Elasticsearch“, und für die Dateisuche ist die Erweiterung „Full text search – Files“ zuständig. Wer also in der App-Verwaltung von Nextcloud drei ähnliche Einträge sieht, ist nicht falsch abgebogen.

Diese modulare Architektur hat einen handfesten Vorteil: Sie erlaubt es, den Suchserver auszutauschen, ohne jede Datenquelle neu zu konfigurieren. Elasticsearch ist derzeit die verbreitetste Wahl, aber keineswegs die einzige. Apache Solr funktioniert ebenfalls, und OpenSearch taugt in bestimmten Konstellationen als Alternative. Die Anbindung der Dateien bleibt davon unberührt, weil der Datei-Provider sich nicht um das Backend kümmert, sondern ausschließlich um die Extraktion und Aufbereitung der Inhalte.

Elasticsearch: Ein Sachregister mit Superkräften

Elasticsearch ist ein eigenständiger Dienst, der nicht in Nextcloud eingebettet ist, sondern als Prozess danebenläuft. Er basiert auf der Lucene-Bibliothek, die seit Jahren das Fundament vieler Suchmaschinen bildet. Lucene ist eine Java-Bibliothek, die Textdokumente in einen so genannten invertierten Index aufnimmt. Dieser Index funktioniert im Prinzip wie das Sachregister am Ende eines Fachbuchs: Zu jedem Begriff wird festgehalten, in welchen Dokumenten er vorkommt und an welcher Stelle. Ein Suchbegriff wird dadurch nicht durch sequenzielles Lesen aller Dateien gefunden, sondern durch einen direkten Blick in das Register. Das ist ungeheuer schnell, selbst bei Millionen von Dokumenten.

Elasticsearch verpackt diese Funktionsweise in eine HTTP-Schnittstelle, über die Nextcloud Dokumente hinzufügen, abfragen und löschen kann. Man könnte sagen: Elasticsearch ist der Motor, Nextcloud das Lenkrad. Und wie jeder Motor will er gepflegt sein. Die Java Virtual Machine, auf der Elasticsearch läuft, braucht ausreichend Speicher, die Daten sollten auf schnellen Platten liegen, und der Prozess sollte nicht einfach nebenbei auf einem Webserver mitlaufen, der ohnehin schon an seine Grenzen stößt. Wer sich diese Mühe spart, bekommt schnell das Gefühl, das System sei „langsam“ – obwohl eigentlich nur der Betrieb des Suchservers vernachlässigt wurde.

Interessant ist auch die lizenzrechtliche Schiene. Elasticsearch wurde eine Zeit lang von Elastic unter einer freien Lizenz vertrieben, später aber auf eine eigenen Lizenz umgestellt, die für viele Unternehmen nicht mehr als „Open Source“ durchgeht. Darum gibt es den Fork OpenSearch, der von der Community gepflegt wird. Auf der Ebene der API sind sich die beiden Systeme weitgehend ähnlich. Dennoch sollte man nicht unbedacht umsteigen. Die Dokumentation von Nextcloud bezieht sich auf Elasticsearch, und die Kompatibilität mit OpenSearch ist nicht garantiert. In einer Testumgebung kann man das ausprobieren, für einen unternehmenskritischen Betrieb ist es eher ein Wagnis.

Einrichtung: Die ersten Schritte zum Index

Die Installation beginnt mit dem Elasticsearch-Server. Wer einen gut gepflegten Linux-Server betreibt, findet Elasticsearch in den offiziellen Paketquellen oder kann es über Docker als Container starten. Die Docker-Variante ist für Testumgebungen ideal, weil man den Dienst mit einem Befehl hochzieht. Für den produktiven Betrieb empfehlen sich ein eigener Systemnutzer, ein sauberes Verzeichnis und das bekannte Startkommando über systemd. Die Kommunikation läuft standardmäßig über den Port 9200. Auf diesen Port muss der Nextcloud-Server zugreifen können – und nur der Nextcloud-Server.

Im zweiten Schritt installiert man in Nextcloud die passenden Apps. Zur Grundausstattung gehören das FTS-Framework, der Elasticsearch-Treiber und die Files-Erweiterung. Danach öffnet sich im Administrationsbereich eine neue Sektion, in der sich die Verbindung zum Suchserver konfigurieren lässt. Alternativ kann man die Einstellung direkt in die Datei config.php schreiben. Ein Beispiel für eine einfache Konfiguration:

'fulltextsearch' => [
    'elasticsearch' => [
        'host' => 'localhost',
        'port' => 9200,
        'index' => 'nextcloud',
    ],
],

Dabei werden Host und Port des Elasticsearch-Dienstes angegeben, dazu der Name des Indexes, unter dem Nextcloud seine Daten ablegt. Wenn Elasticsearch einen API-Schlüssel oder ein Passwort verlangt, lassen sich auch diese Werte in der Konfiguration ergänzen. Bevor man weitermacht, sollte man prüfen, ob der Dienst erreichbar ist. Ein simpler Zugriff auf die URL des Elasticsearch-Servers von der Konsole des Nextcloud-Rechners aus gibt schnell Auskunft.

Danach stößt man die Indizierung an. Üblicherweise geschieht das über den Kommandozeilenbefehl occ fulltextsearch:index. Das ist insofern bequem, als die Verwaltung der Suchindizes auf diese Weise in automatisierte Skripte eingebaut werden kann. Mit einem frischen Index geht es dann ans Eingemachte: der erste große Durchlauf durch die Dateibestände. Der Befehl beendet sich nicht von selbst, wenn unmengen von Dateien warten. Er arbeitet die Warteschlange ab und kehrt erst zurück, wenn der Bestand abgearbeitet ist. Für den ersten Durchlauf sollte man also ausreichend Zeit einplanen.

Wichtig ist an dieser Stelle die Cron-Konfiguration von Nextcloud. Die Volltextsuche aktualisiert sich nicht in Echtzeit. Neue Dateien und Änderungen werden über Ereignisse gesammelt und an die Index-Warteschlange übergeben. Wenn auf dem System nur der Webcron läuft, der bei jedem Seitenaufruf ausgeführt wird, bleiben solche Ereignisse unter Umständen liegen. Ein System-Cron, der minütlich oder noch häufiger die Nextcloud-Cron-Datei aufruft, ist die deutlich bessere Wahl. Das gilt übrigens nicht nur für die Volltextsuche, sondern für die gesamte Systemwartung von Nextcloud.

Dateien und ihre Inhalte: Die Kunst der Extraktion

Die bloße Anbindung an Elasticsearch ist nur die halbe Miete. Die eigentliche Arbeit steckt in der Textextraktion. Eine Datei ist nicht einfach eine Aneinanderreihung von Buchstaben, die man in einen Index schaufeln kann. Ein PDF ist eine Sammlung von Objekten, Schriften, Grafiken und unsichtbaren Strukturen. Ein Office-Dokument enthält Text, Formatierungen und Kommentare, die im Binärformat stecken. Und ein Bild hat überhaupt keinen Text, sondern nur Pixel.

Für solche Fälle hält die Nextcloud-FTS-Lösung mehrere Extraktoren bereit. Der eine heißt pdftotext und holt aus PDFs den Text heraus, wenn er als solcher gespeichert ist. Für Office-Formate gibt es ähnliche Werkzeuge, die die eXtensible Markup Language in den Office-Dateien durchsuchen. Viele dieser Werkzeuge laufen als eigenständige Programme auf dem Server und werden von der Nextcloud-App bei Bedarf aufgerufen. Ist eines nicht installiert, überspringt der Indexer die betroffenen Dateien oder verarbeitet nur die Metadaten. Ein Blick in die Logs offenbart dann schnell, was fehlt.

Handelt es sich um gescannte Dokumente, wird die Mühle aufwendiger: Hier ist eine Texterkennung nötig, die Buchstaben aus Bildpixeln rekonstruiert. Das Programm der Wahl ist Tesseract, das ebenfalls in den Prozess eingebunden werden kann. Ist Tesseract installiert, versucht der Indexer, auch Bilddaten und gescannte Dokumente zu erschließen. Dass die Erkennungsqualität mit der Auflösung des Scans schwankt, versteht sich von selbst. Aus einer zerfleckten Schwarzweißkopie mit handschriftlichen Notizen wird auch die beste OCR keine perfekte Textquelle machen. Aber schon die Erkennung von 80 Prozent der Zeichen reicht aus, um ein Dokument später wiederzufinden.

Ein wichtiger Punkt für Admins: Die Textextraktion ist kein Hexenwerk, aber eine Frage des Rechenaufwands. Das OCR von Tausenden Seiten braucht seine Zeit und lässt die CPU gehörig schwitzen. Wer den Server kaum ausgelastet hat, kann den Prozess einfach per Cron laufen lassen. Wer dagegen eine Installation betreibt, die rund um die Uhr im Einsatz ist, sollte vielleicht nur die notwendigsten Formate zulassen. Die Einstellungsmöglichkeiten dafür verstecken sich etwas in der Tiefe der App-Konfiguration – sie sind aber vorhanden.

Dabei zeigt sich, wie wichtig die Wahl des richtigen Indexformats ist. Die Größe des Elasticsearch-Indexes wächst nicht linear mit der Dateigröße. Eine 20-Megabyte-PDF mit Scan-Bildern kann nach der Textextraktion nur ein paar Kilobyte reinen Text enthalten. Ein winziges Textdokument mit hundert Seiten dagegen kann den Index erheblich aufblähen. Wer den Speicherbedarf des Suchservers unter Kontrolle halten möchte, sollte sich nicht allein auf die Dateigröße, sondern auf die Textmenge konzentrieren. Diese Texte lassen sich in Elasticsearch gut komprimieren, aber die Indizierung erzeugt ein eigenes Datenaufkommen, das in die Kapazitätsplanung einfließen muss.

Berechtigungen: Die unsichtbare Grenze der Suche

Ein heikles Thema bei jeder Suchmaschine ist die Rechteprüfung. Ein Suchindex enthält schließlich Inhalte, die nicht für alle Benutzer bestimmt sind. Wenn ein Mitarbeiter nach „Gehaltsliste“ sucht, darf er nur Dokumente angezeigt bekommen, für die er auch tatsächlich eine Freigabe besitzt. Nextcloud löst diese Aufgabe über ein zweistufiges Verfahren. Zuerst fragt die Such-App die Datenquellen ab, welche Dateien für den aktuellen Benutzer prinzipiell sichtbar sind. Diese Liste von Kennungen wird an Elasticsearch übergeben, das die eigentliche Volltextsuche nur in diesem eingeschränkten Bereich durchführt. Das ist ein dezentraler Filter, der die Leistungsfähigkeit der Suchmaschine nicht beeinträchtigt.

Der zweite Schritt ist eine Art Schlusskontrolle. Selbst wenn der Index eine ID zurückliefert, prüft Nextcloud noch einmal, ob die Datei inzwischen gelöscht, verschoben oder die Freigabe zurückgezogen wurde. Dieses Vorgehen verhindert, dass veraltete Indizes zu undichten Suchergebnissen führen. Man kann es mit dem Sicherheitspersonal vor einem Konzert vergleichen: Die Eintrittskarte berechtigt zum Eingang, aber am Saal wird noch einmal nachgesehen, ob der Name auf der Gästeliste stimmt.

Kritisch wird es bei der Ende-zu-Ende-Verschlüsselung. Wenn Nextcloud-Dateien so verschlüsselt abgelegt sind, dass selbst der Server nur eine leere Hülle sieht, kann auch die Volltextsuche den Inhalt nicht erkennen. Das ist ein systemimmanenter Widerspruch. Sicherheitsbewusste Unternehmen müssen also entscheiden, ob sie die Bequemlichkeit der Suche oder die strikte Geheimhaltung bevorzugen. Hier hat die Verschlüsselung logischerweise Vorrang; ein Administrator, der an dieser Stelle nach einer Hintertür sucht, hat die Architektur nicht verstanden.

Auch bei öffentlichen Freigaben bleibt die Kontrolle erhalten. Ein Nutzer, der eine Datei über einen öffentlichen Link mit Außenstehenden teilt, erweitert damit nicht den Suchindex der anderen internen Nutzer. Die Sichtbarkeit im Suchergebnis richtet sich nach der Kontostruktur in Nextcloud, nicht nach dem öffentlichen Link. Das ist ein Detail, das manchen überrascht, aber für den Datenschutz unerlässlich ist.

Der erste Durchlauf: Geduld ist gefragt

Die schönste Indizierung nützt nichts, wenn sie nicht startet. Gerade bei umfangreichen Nextcloud-Systemen ist die Erstindizierung ein langwieriges Manöver. Es gibt zwar einen Kommandozeilenbefehl, aber keine nennenswerte Fortschrittsanzeige. Das liegt daran, dass die Größe des Bestands nur geschätzt werden kann. Als Faustregel gilt: Streckenweise rattert der Server mit einigen hundert Dateien pro Minute durch, dann bleibt er an einem riesigen, komplizierten PDF hängen und scheint für viele Minuten stillzustehen. Wer sich in dieser Phase nicht geduldet, macht den Fehler, den Prozess abzubrechen und neu zu starten. Dann beginnt alles von vorn – inklusive der Suche nach Fehlern, die gar keine sind.

Ein kluger Administrator richtet für die Erstindizierung ein stabiles Terminal mit tmux ein oder bindet den Vorgang in eine eigene Log-Datei ein. So bleibt der Prozess kontrollierbar. Danach laufen inkrementelle Updates über den Nextcloud-Cronjob: Jede Änderung einer Datei erzeugt ein Ereignis, das der FTS-Queue zugeführt wird. Im Idealfall ist die Suche damit immer nur wenige Augenblicke hinter dem Stand der Ablage.

Was aber passiert, wenn der Hintergrundprozess nicht läuft? Dann bleibt die Suche still. Nicht kaputt, aber nutzlos. Das ist eine häufige Fehlerquelle bei Installationen, die noch den Webcron als cron.php nutzen, der nur bei Seitenaufrufen im Browser feuert. Für die Volltextsuche ist ein echter System-Cron notwendig, der regelmäßig und unabhängig vom Besucherverkehr arbeitet. Diesen Punkt sollte man zuerst abhaken, wenn Ergebnisse auseinanderdriften.

Betrieb, Wartung und die Kunst des Monitorings

Elasticsearch ist nicht dafür bekannt, von allein stabil zu laufen, wenn man es ignoriert. Die ersten Anlaufschwierigkeiten beginnen oft mit der Speicherverteilung: Die Java Virtual Machine, auf der Elasticsearch läuft, reserviert sich einen Heap-Speicher, der in der Standardkonfiguration nicht für riesige Indizes ausgelegt ist. Wer also deutsche Textdokumente im großen Stil indizieren will, sollte die Heap-Größe anpassen. Als Faustregel gilt: nicht zu viel, nicht zu wenig – die Hälfte des physischen Arbeitsspeichers, aber nicht mehr als 32 Gigabyte, wenn man dem Ratschlag erfahrener Betreiber folgen möchte. Zu viel Heap führt nämlich zu langen Garbage-Collection-Pausen, die die Suche immer wieder ins Stocken bringen.

Zudem sollte man die Gesundheit des Clusters im Blick behalten. Ein kurzer Befehl wie curl -XGET 'http://localhost:9200/_cluster/health' liefert Statuswerte: Grün ist gut, Gelb ein Warnsignal, Rot ein Albtraum. Man muss kein Monitoring-Profi sein, um diese Abfrage in ein Skript einzubauen. In kleineren Setups kann aber auch der gelegentliche Blick in die Nextcloud-Admin-Seite genügen, auf der die FTS-App ihren Zustand anzeigt. Die dort eingeblendeten Zahlen sagen allerdings nicht alles; sie beziehen sich auf die Anzahl der indizierten Dokumente und nicht auf die Performance des Suchservers.

Ein weiterer Gesichtspunkt ist die Sicherheit. Eine Elasticsearch-Schnittstelle gehört nicht ungeschützt ins Internet. Der Dienst hat in der freien Variante keine eingebaute Authentifizierung. Man kann ihn hinter einem Reverse-Proxy verstecken, der eine Basic-Authentifizierung verlangt, oder man bindet ihn ausschließlich an ein internes Netzwerk. Die Kommunikation zwischen Nextcloud und Elasticsearch sollte auf jeden Fall über ein internes Netz laufen, das von außen nicht erreichbar ist. Es wäre fahrlässig, den Port 9200 in der Firewall freizugeben, nur weil die Software so freundlich auf Anfragen antwortet.

Fehlerbilder und der Weg zur Rettung

So schön die Volltextsuche ist, so tückisch kann sie sein, wenn die Erwartungen enttäuscht werden. Ein häufiges Bild: Eine Datei wurde vorhin hochgeladen, die Suche findet sie aber nicht. Meist liegt es daran, dass der Indexer noch gar nicht auf die Datei geschaut hat. Es dauert ein paar Minuten, bis der Cronjob die neuen Einträge abholt. Wer einen Webcron hat, kann noch länger warten. Hier hilft die manuelle Ausführung von occ fulltextsearch:index als Test.

Ein anderer Klassiker: Die Suche findet die Datei, aber Inhalte älterer Versionen tauchen auf. Nextcloud-Versionierung und Volltextsuche stehen manchmal im Konflikt. Der Index sammelt nicht nur den aktuellen Stand, sondern eben auch alte Inhalte, sofern sie nicht gelöscht werden. Das kann durchaus gewünscht sein, wenn man nach einem alten Vertragsstand sucht. Es kann aber auch zu Verwirrung führen, wenn man eine Datei geändert hat und die alte Passage immer noch als Treffer auftaucht. Im Zweifel sollte man nachsehen, ob die Versionierung von Nextcloud eingeschränkt ist.

Dann gibt es noch die unsichtbaren Fehler, die in den Logs von Nextcloud auftauchen: „failed to index file, document not found“. Solche Meldungen deuten darauf hin, dass der Abgleich zwischen Datenbank und Index aus dem Takt geraten ist. Häufig hilft es, die betroffene Datei zu verschieben und wieder zurückzubewegen, damit der Index neu aufgebaut wird. In hartnäckigen Fällen bleibt nur der Reset des Indexes und eine erneute Indizierung. Das ist wie ein Reset des Gehirns: nicht angenehm, aber zuweilen notwendig.

Ein Rat am Rande: Nicht jede Indexierungsstörung ist ein Fehler der App. Wenn Elasticsearch seine maximalen Felder überschreitet oder die Anzahl der Dokumente ein Limit erreicht, sind die Ursachen im Mapping zu suchen. Geübte Administratoren schauen dann nicht in Nextcloud, sondern in die Elasticsearch-Logs. Dort stehen die eigentlichen Wahrheiten – in oft kryptischen, aber lesbaren Englisch. Ein offenes Ohr für die Log-Dateien gehört daher zum Betriebsalltag.

Skalierung: Mehr als nur ein Index

Wenn die Cloud wächst, wächst auch der Index. Ein Nextcloud-System mit fünfzigtausend Dateien mag Elasticsearch mit ein paar Gigabyte füttern. Bei mehreren Millionen Dateien braucht es Planung. Dann sollten die Shards des Indexes über mehrere Datenknoten verteilt werden. Nextcloud kümmert sich nicht darum; das ist Aufgabe der Elasticsearch-Administration. Die gute Nachricht ist: Elasticsearch ist für den verteilten Betrieb gebaut worden. Es kann Index-Daten auf mehrere Maschinen aufteilen und Wiederholungen vorhalten, sodass bei Ausfall eines Knotens nicht gleich die gesamte Suche zusammenbricht.

Für den typischen Nextcloud-Betrieb ist diese Dimension allerdings unüblich. Die meisten Installationen kommen mit einem einzigen Knoten aus. Eine ehrliche Einschätzung der eigenen Datenmenge hilft, die richtige Größe zu finden. Wer noch in der Homelab-Phase steckt, kann Elasticsearch durchaus auf einem Raspberry Pi modifiziert betreiben; der Dienst läuft selbst mit kleinem Speicher, wenn der Index klein bleibt. Aber sobald mehrere Benutzer gleichzeitig suchen, wird man eine richtige Servermaschine brauchen. Die Suchlatenz ist ein heikles Gut; ein Server, der unter Last ächzt, lässt sich nicht durch einen schnelleren Algorithmus retten, sondern nur durch bessere Hardware oder die Auslagerung des Dienstes.

Gern übersehen wird auch der Einfluss der Langzeitarchivierung. Wenn Nextcloud mehrere Versionen einer Datei vorhält, indiziert die Volltextsuche grundsätzlich alle Fassungen, sofern der Dateianbieter das zulässt. Das kann den Index um ein Vielfaches erweitern. Man sollte prüfen, ob die Volltextsuche auf die aktuelle Dateiversion beschränkt werden kann. In manchen Konstellationen ist das nicht ohne weiteres möglich. Ein bewusster Umgang mit den Versionseinstellungen von Nextcloud schafft hier Abhilfe.

Externe Speicher und die netten Tücken

Nextcloud beschränkt sich nicht auf das lokale Datenverzeichnis. Viele Installationen binden S3-Buckets, FTP-Server oder SMB-Freigaben als externe Speicher ein. Auch diese Inhalte kann die Volltextsuche erfassen, sofern der Dateiprovider die Zugriffe unterstützt. In der Praxis zeigt sich jedoch, dass externe Speicher eine eigene Tücke mitbringen: Die Dateien liegt möglicherweise nicht auf dem gleichen Server, was die Textextraktion langsamer macht. Dazu kommt, dass manche S3-Buckets riesige Datenmengen enthalten und die Indizierung entsprechend lange dauert.

Ein interessanter Aspekt ist hier die Quellentransparenz. Elasticsearch kennt keine Unterschiede zwischen lokalen und entfernten Dateien. Für den Index zählt nur der Inhalt und der zugehörige Dateipfad. Das ist ein Vorteil, denn die Suche bleibt überall gleich. Aber für die Größe des Durchlaufs ist es ein Nachteil: Der Indexer muss die Daten über das Netzwerk ziehen, was den S3-Bucket-Abzug nach Nextcloud belastet. Wer also einen S3-Bucket mit archivierten E-Mails oder alten Backup-PDFs an Nextcloud anbindet, sollte den Indexer zunächst nur auf einen Teilbereich loslassen. Das ist in der App recht gut umgesetzt. Man kann per Ordner- und Dateityp-Filter festlegen, was unter die Lupe genommen wird.

Das Zusammenspiel mit externen Speichern zeigt auch, warum die App-Familie nicht nur aus einem einzigen Baustein besteht. Die Datei-Provider-Schicht ist dafür verantwortlich, alle Objekte unabhängig von ihrer Herkunft an die Suche zu übergeben. Dieser Ansatz trägt wesentlich zur Verbreitung von Nextcloud in Unternehmen bei, weil die Volltextsuche nicht vor den S3-Buckeln haltmacht.

Alternativen: Solr, OpenSearch und die hauseigene Konkurrenz

Elasticsearch ist nicht der einzige Unterbau, den die Nextcloud-Full-Text-Search-Plattform ansprechen kann. Die FTS-Architektur ist offen und erlaubt grundsätzlich mehrere Anbindungen. Die bekannteste zweite Plattform ist Apache Solr, die ebenfalls auf Lucene aufbaut, aber eine etwas ruhigere Entwicklungslinie fährt. In der Nextcloud-Welt war Solr über die frühere Nextant-Erweiterung eine gängige Wahl. Heute ist die offizielle Unterstützung eher ein Schatten ihrer selbst, aber nicht ganz verschwunden. Wer ohnehin Solr in der Infrastruktur betreibt, kann die beiden Systeme über die FTS-Schnittstelle koppeln und auf Elasticsearch verzichten.

In den letzten Jahren hat sich außerdem OpenSearch etabliert, ein Community-Fork von Elasticsearch, der nach den Lizenzstreitigkeiten bei Elastic entstanden ist. Aus technischer Sicht kann OpenSearch mit dem Elasticsearch-Connector zusammenarbeiten, weil die HTTP-Schnittstellen weitgehend identisch sind. Offiziell wird dieses Setup von Nextcloud nicht bestätigt, und wer die Kombination wagt, muss damit rechnen, bei Problemen allein gelassen zu werden. In einem Homelab- oder Wissenschaftsumfeld kann das trotzdem eine valide Option sein, insbesondere wenn man Elasticsearch-Lizenzmodelle umgehen möchte.

Und schließlich gibt es noch den simplen Weg: die Suchfunktion, die in der Nextcloud-Datenbank selbst verankert ist. Für kleine Installationen reicht sie oft aus. Sie durchsucht Metadaten und – sofern entsprechend eingestellt – auch ausgewählte Dateitypen. Doch wer einmal erlebt hat, wie eine Volltextsuche instantan aus zehntausenden Dokumenten das richtige Zitat hervorzaubert, wird sich mit einer simplen LIKE-Abfrage nicht mehr zufriedengeben. Hier liegt der eigentliche Unterschied zwischen Fischen mit der Hand und dem Einsatz eines professionellen Schleppnetzes. Man kann den Fisch auch einzeln fangen, aber es dauert.

Ein Blick auf die Suchqualität

Die Volltextsuche wäre nur halb so nützlich, wenn sie nicht auch etwas über die Reihenfolge der Treffer wüsste. Elasticsearch arbeitet mit einem Relevanz-Score, der unter anderem berücksichtigt, wie oft ein Begriff im Dokument vorkommt, in welcher Feldposition er auftritt und wie selten er insgesamt im Index ist. Je spezifischer der Begriff, desto präziser das Ergebnis. Ein Wort wie „Software“ erzeugt bei einer großen Instanz viele Treffer; ein Begriff wie „Wartungsfenster-Eskalation“ dagegen nur wenige. Diese Gewichtung lässt sich im Suchabgleich von Nextcloud nutzen, allerdings nicht im Detail steuern. Wer eigene Bewertungsregeln anlegen möchte, ist wieder bei Elasticsearch gelandet und muss die Abfragen entsprechend anpassen.

Ein weiterer Punkt ist die linguistische Suche. Deutsche Sprache bereitet Suchmaschinen traditionell Kopfschmerzen wegen der vielen Endungen, Zusammensetzungen und unregelmäßigen Verben. Elasticsearch bietet Stemming-Algorithmen, die bei der Indizierung die Wörter auf ihren Wortstamm zurückführen. Aus „Häuser“ wird so „Haus“, aus „Suchen“ wird „Such“. Ohne diese Normalisierung bleiben viele Treffer unentdeckt, weil die Suchanfrage nicht exakt mit der gespeicherten Form übereinstimmt. Die Einrichtung eines passenden Analysators ist eine lohnende Feinarbeit – und an dieser Stelle zeigt sich, wie tief die Integration zwischen Nextcloud und Elasticsearch eigentlich gehen kann.

Datenschutz und Compliance: Fragen, die man sich stellen sollte

In deutschen Unternehmen ist das Thema Datenschutz kein Lippenbekenntnis. Die Volltextsuche greift tief in alle Inhalte ein, die in der Cloud liegen. Das darf man nicht verkennen. Der Suchindex speichert nicht nur Dokumententexte, sondern auch Benutzerkennungen, Gruppenberechtigungen und möglicherweise personenbezogene Informationen. Wer einen solchen Index betreibt, sollte im Rahmen der Datenschutz-Folgenabschätzung zumindest dokumentieren, was dort lagert und wie lange. Gerade bei selbst gehosteten Nextcloud-Instanzen ist die Kontrolle darüber noch am größten. Aber auch dort gehört es zum guten Ton, die Aufbewahrungsfristen des Indexes zu regeln: Gelöschte Dateien sollten nicht mehr über Elasticsearch gefunden werden können.

Elasticsearch bietet Schnittstellen, um Dokumente gezielt aus dem Index zu entfernen. Die Nextcloud-FTS-Synchronisation übernimmt diese Aufgabe automatisch, wenn eine Datei gelöscht oder in den Papierkorb verschoben wird. Allerdings funktioniert das nur, wenn die Lösch-Ereignisse sauber über die App laufen. Wenn jemand eine Datei direkt auf dem Dateisystem oder über einen externen Speicher entfernt, bleibt der Index unter Umständen stehen. Es gehört zur administrativen Sorgfalt, diesen Fall im Monitoring zu erkennen. Ein Index, der langsam anschwillt, obwohl der Datenbestand schrumpft, ist ein Alarmzeichen.

Kibana, Logs und was man sonst noch wissen sollte

Elasticsearch wird selten allein betrieben. Um ihn herum hat sich ein ganzer Kosmos aus Werkzeugen gebildet, allen voran Kibana, eine Weboberfläche zur Visualisierung und Analyse der Index-Daten. Für den reinen Betrieb der Nextcloud-Volltextsuche ist Kibana nicht erforderlich, aber nützlich. Man kann damit beobachten, wie viele Dokumente indiziert sind, wie groß der Durchsatz ist und wo es zu Fehlern kommt. Ein interessanter Nebenaspekt: Kibana zeigt auch, wonach die Benutzer suchen. Das mag aus Datenschutzgründen verpönt sein, kann aber wertvolle Hinweise auf die Akzeptanz der Suche liefern. Wenn niemand die Volltextsuche nutzt, liegt das nicht am Index, sondern an der Oberfläche oder an der fehlenden Schulung der Anwender.

Die Log-Dateien von Elasticsearch sind ausführlich, aber nicht immer selbsterklärend. Bei der Fehlersuche hilft es, die Logs von Nextcloud und Elasticsearch parallel zu lesen. Nextcloud schreibt in seiner Log-Datei oft den Grund für eine fehlgeschlagene Indexierung, und Elasticsearch ergänzt die technische Perspektive. Diese beiden Meldungen zusammenzuführen erfordert ein wenig Erfahrung, lässt sich aber leicht erlernen. Einmal begriffen, gehört die Fehlersuche zum täglichen Handwerk eines Administrators, der mit der FTS-Kombination arbeitet.

Nextcloud AIO: Der bequeme Einstieg

Für alle, die keine Lust auf stundenlanges Konfigurieren haben, gibt es die Nextcloud All-in-One-Installation. In diesem offiziellen Container-Setup sind Elasticsearch und die FTS-Apps bereits integriert. Man aktiviert die Volltextsuche in der administrativen Oberfläche, und der Index wird nach einer kurzen Wartezeit aufgebaut. Das ist ein enormer Fortschritt gegenüber den Zeiten, in denen man drei Apps einzeln installieren und zusätzlich einen Elasticsearch-Server aufsetzen musste.

Nextcloud AIO eignet sich vor allem für mittelständische Anwender und solche, die eine schlanke Lösung ohne viel Serverfahrung betreiben wollen. Die Kehrseite ist die mangelnde Flexibilität. Wer Elasticsearch außerhalb des Containers betreiben möchte, um es mit anderen Systemen zu teilen, stößt mit AIO schnell an Grenzen. Aber für den Normalfall ist der integrierte Weg eine sinnvolle Empfehlung. Er reduziert die Fehleranfälligkeit und macht die Volltextsuche für ein breiteres Publikum zugänglich – und das ist letztlich gut für die Verbreitung der Open-Source-Technologie.

Selbstverständlich bleibt die manuelle Installation die bessere Wahl, wenn es um maximale Kontrolle oder um den Betrieb in einer bereits vorhandenen Unternehmensinfrastruktur geht. Der integrierte Weg und der manuelle Weg stehen nicht in Konkurrenz, sondern sprechen unterschiedliche Zielgruppen an. Der eine will einfach eine funktionierende Suche, der andere will wissen, wie sie tickt. Beide kommen mit Nextcloud und Elasticsearch auf ihre Kosten.

Ausblick: Vom Suchen zum Finden – und was danach kommt

Die Volltextsuche in Nextcloud ist längst kein Experimentierfeld mehr. Sie funktioniert stabil und skaliert mit der Cloud-Instanz. Die Kombination aus Nextcloud, Full Text Search und Elasticsearch gehört heute zum Standard, wenn es um die leistungsfähige Suche in selbst gehosteten Cloud-Umgebungen geht. Dabei wird die Suche selbst immer selbstverständlicher. Wer sie einmal benutzt hat, fragt sich, wie man ohne sie arbeiten konnte. Es ist wie mit der Volltextsuche im E-Mail-Programm: Kaum jemand würde noch jede Nachricht einzeln öffnen, nur um herauszufinden, ob ein bestimmtes Wort vorkommt.

Gleichzeitig werden die Ansprüche größer. Die nächste Stufe ist die semantische Suche, die nicht nur nach Wörtern sucht, sondern nach Bedeutung. Nextcloud experimentiert bereits mit maschinellem Lernen und bietet Ansätze, um Bilder zu erkennen, Gesichter zu sortieren und PDF-Dokumente zu klassifizieren. Diese Entwicklungen werden die Volltextsuche nicht ablösen, sondern ergänzen. Ein System, das Dokumente automatisch nach Themen gruppiert und dann durchsucht, wäre ein erheblicher Produktivitätssprung. Die Grundlagen dafür liegen in der Datenhaltung – und damit auch in einem sauber gepflegten Index.

Bis es so weit ist, bleibt Elasticsearch der Motor, der die Suchmaschine antreibt. Nextcloud stellt das Cockpit. Und der Administrator? Der ist der Pilot, der gelegentlich den Tankstand prüfen, den Kurs korrigieren und die Instrumente im Auge behalten muss. Wer diese Rolle ernst nimmt, bekommt ein System, das nicht nur Daten speichert, sondern sie auch wieder hervorbringt – auf Knopfdruck, in Sekundenschnelle und an der richtigen Stelle.

Denn darum geht es am Ende: Die digitale Ablage ist kein Selbstzweck. Ein Dokumentensystem, das Informationen verschluckt, ohne sie wieder preiszugeben, ist nicht besser als ein Keller mit beschrifteten Umzugskartons, in denen niemand mehr nachsieht. Die Volltextsuche verwandelt diesen Keller in eine gut sortierte Bibliothek. Und Elasticsearch ist ihr Katalog.

Nicht zuletzt zeigt sich: Die Kombination aus Nextcloud, Full Text Search und Elasticsearch fügt sich nahtlos in die Philosophie der Open-Source-Infrastruktur ein. Man baut nicht auf eine geschlossene, teure Suchplattform, sondern auf modulare Bausteine, die sich nach eigenem Bedarf zusammensetzen lassen. Das ist manchmal unbequemer, als eine fertige Software zu kaufen, aber es ist ehrlicher. Wer die Bausteine kennt und pflegt, bleibt unabhängig – von Herstellern, von Lizenzen und von den Launen einzelner Softwarekonzerne.

Und vielleicht ist genau das der eigentliche Wert der Volltextsuche in Nextcloud: Sie zwingt dazu, sich mit der eigenen Datenhaltung auseinanderzusetzen. Sie belohnt die Mühe mit einem Werkzeug, das im wahrsten Sinne des Wortes fündig macht. Wer sie einrichtet, gewinnt nicht nur ein Suchfeld, sondern auch ein besseres Verständnis für das, was in der eigenen Cloud wirklich steckt. Und das ist weit mehr als ein Sicherheitsfeature oder ein Komfortgewinn: Es ist eine Form der digitalen Selbstbestimmung.