Nextcloud Volltextsuche und Tesseract OCR im Praxiseinsatz

Die verlorenen Inhalte von Nextcloud wiederfinden – Full Text Search und Tesseract OCR im Praxiseinsatz

Es gibt Momente, in denen man eine Cloud denkt, die Suche benutzt und dann dasitzt: Dateiname nicht gemerkt, Ordnerstruktur längst durcheinandergewürfelt, und der Kollege, der das Dokument abgelegt hat, ist im Urlaub. Bei Nextcloud ist das ein bekanntes Szenario. Der hauseigene Volltextindex war lange Zeit ein Stiefkind. Zwar fand die Suche in Dateinamen, Tags und Kommentaren erstaunlich gut durch den Datenbestand. Aber das, wofür man die Cloud eigentlich betreibt – gescannte Rechnungen, eingebettete Texte in PDFs, handschriftlich ergänzte Notizen – blieb unsichtbar.

Genau hier setzt das Fulltext-Search-Ökosystem an. Die Kombination aus dem gleichnamigen App-Framework, einem davon unabhängigen Index-Server und dem OCR-Werkzeug Tesseract verspricht, was viele ein „richtiges durchsuchen“ nennen. Das klingt erstmal nach ordentlich Bastelei. Und ja, es ist nicht einfach eine Nextcloud-App, die man installiert und fertig. Aber wenn man sich einmal durch die anfänglichen Konfigurationshürden gearbeitet hat, bekommt man eine Suche, die man nicht mehr missen möchte. Dieser Artikel zeigt, wie die Bausteine zusammenspielen, wo die Stolpersteine liegen und was tatsächlich aus dem Versprechen „Durchsuche meine Dateien nach Inhalt“ wird.

Das Fundament: Das Fulltext-Search-Framework

Nextcloud Fulltext Search ist eigentlich keine einzelne Anwendung, sondern ein Rahmen. Technisch betrachtet eine API-Hülle, die verschiedene Suchmaschinen anspricht. Wer das installiert, bekommt zunächst nur ein Gerüst – Standard-Suchmasken, Indexverwaltung und die Kommunikation mit der eigentlichen Suche. Die dahinterliegende Arbeit verrichten unterschiedliche Komponenten, die man sich als Schubladen vorstellen kann: Der Backend-Adapter schickt die Dokumente an ein Indexsystem wie Elasticsearch oder OpenSearch. Eine separate Provider-App liest die Dateien aus den Nextcloud-Ordnern und bereitet sie auf. Dazu kommen Zusatzdienste wie die OCR-Integration, die nichts anderes tut, als eine Bilddatei durch Tesseract zu jagen und den extrahierten Text zurückzugeben.

Diese Aufteilung hat einen strategischen Hintergrund. Nextcloud wollte die Benutzer nicht an einen bestimmten Suchserver binden. Wer in der Firma bereits Elasticsearch betreibt, kann das ohne große Umstellung anbinden. Wer es sich schlicht einrichten möchte, nimmt den Docker-Container. Aber es gibt eine Kehrseite: Fünf Apps, zwei Dienste und mindestens ein Cronjob – das ist keine „Installieren und Vergessen-Lösung“. Die Nextcloud-Entwickler haben das im Laufe der Jahre zwar vereinfacht, etwa mit dem Hinweis auf das offizielle Elasticsearch-Dockerimage. Ein Konfigurationsaufwand bleibt dennoch, und wer die Dynamik der Versionen verpasst, steht schnell vor seltsamen Fehlern.

Wie der Index zustande kommt

Der Begriff Fulltext Search beschreibt im Kern einen Vorgang, der aus einer Datei einen Datensatz macht: Pfad, Dateiname, Metadaten, ein paar Standardfelder – und eben der gesamte Textinhalt. Der Index-Server zerlegt diese Daten in durchsuchbare Token. Das passiert nicht zeitgleich mit dem Hochladen, sondern in einer Art Warteschlange. Nextcloud nutzt dafür den internen Cron-Mechanismus. Die Frequenz ist entscheidend für die Aktualität. Läuft der Cron nur einmal pro Stunde, sind neue Dateien unter Umständen lange nicht auffindbar. Ein kurzer Test mit der Kommandozeile hilft, sich mit der Funktionsweise vertraut zu machen.

Wer die Gelegenheit hat, einmal direkt in die Indexstruktur zu schauen, wird feststellen, dass die normale Suche der Cloud nur eine Hülle ist. Die Suchmaske in der Menüleiste fragt beim Tippen nicht die Datenbank ab, sondern das Index-Backend – sofern man das Fulltext-Search-Framework eingerichtet hat. Das hat einen entscheidenden Vorteil: Die Suche funktioniert auch über Dateigrenzen hinweg. Eine Suche nach einem Kundennamen findet sowohl den Text im PDF als auch die passende Notiz in einer Markdown-Datei und den Erwähnungsort in einem Kalendereintrag, sofern man die jeweiligen Provider installiert hat. Das ist der Unterschied zu der üblichen, eher hilflosen Suche, die nur den Dateinamen abklopft.

Der Files-Provider: Das Herzstück für Dateien

Die eigentliche Indexierung der Dateien übernimmt eine separate App, die sich „Full Text Search – Files“ nennt. Sie ist die älteste und ausgereifteste der Provider. Sie registriert sich beim Framework und liefert die Dokumente an den Index. Dabei geht sie recht gründlich vor: Neben dem Inhalt werden auch der Dateipfad, der Dateiname, Änderungsdatum und ein paar weitere Eigenschaften indexiert. Das erleichtert das Wiederfinden erheblich.

Bemerkenswert ist die Art, wie Nextcloud dabei vorgeht. Die App sammelt zunächst alle Dateien, die sich in den Benutzerordnern oder in geteilten Ordnern befinden. Sie erkennt anhand der Dateierweiterung, mit welchem Extraktor sie die Datei behandeln muss. Für PDFs, Textdateien und gängige Office-Formate gibt es eingebaute Extraktoren. Für Bilder und gescannte Dokumente ist der OCR-Adapter zuständig. Genau diese Unterscheidung ist es, die im Alltag über Erfolg oder Misserfolg entscheidet. Eine einzige unsauber eingescannte PDF-Datei ohne Textebene, etwa von einem älteren Multifunktionsgerät, bleibt ohne OCR dennoch ein blinder Fleck.

Es wäre unrealistisch zu erwarten, dass die Indexierung schneller abläuft als ein gewöhnlicher Datei-Manager. Der Prozess kostet Ressourcen. Besonders die Verschlagwortung von Dateien, die in vielen geteilten Ordnern liegen, frisst Serverleistung. Ein Fehler, den viele Administratoren machen: Sie aktivieren den Index für alle Benutzer gleichzeitig und wundern sich über einen massiven Lastanstieg. Die Nextcloud-Dokumentation empfiehlt deshalb, die Indexierung schrittweise durchzuführen. Mit dem Kommandozeilen-Befehl occ fulltextsearch:index kann man gezielt einzelne Ordner oder Benutzer indexieren und die Last kontrollieren. Die Erfahrung zeigt, dass dieser Weg planbarer ist als das blinde Loslaufen des Cronjobs.

Ein wichtiger Hinweis für alle, die mit Gruppen und verschachtelten Freigaben arbeiten: Die Rechteverwaltung von Nextcloud gilt auch im Index. Was also in der Suche auftaucht, hängt davon ab, ob der suchende Benutzer die Datei sehen darf. Die Suche ist also nicht besser informiert als der Nutzer selbst – das ist eine sicherheitsrelevante Eigenschaft, die nicht selbstverständlich ist. Bei der Einrichtung des Projekts standen die Verantwortlichen wiederholt vor der Herausforderung, Suchindex und Datenschutz unter einen Hut zu bringen. Gelungen ist das durch eine strikte Trennung von Indexierung und Zugriffsschutz. Der durchsuchbare Datensatz wird als „vorgefilterte“ Ansicht abgelegt und bei jeder Abfrage neu auf die Berechtigungen hin abgeglichen.

Tesseract OCR: Vom Scan zum Text

Wer sich mit dem Thema Volltextsuche beschäftigt, fragt sich spätestens nach ein paar Testläufen, wie das mit gescannten Dokumenten funktioniert. Ein gescanntes PDF ist für einen Computer schließlich zunächst ein Bild. Es gibt keine Textschicht, keine Buchstaben, nur Pixel. Nextcloud benötigt deshalb eine zusätzliche Fähigkeit: die optische Zeichenerkennung, kurz OCR. Hier kommt Tesseract ins Spiel – ein seit Jahrzehnten entwickeltes Open-Source-Werkzeug, das ursprünglich aus den HP-Labors stammt und heute von Google gepflegt wird. Es gilt als eines der ausgereiftesten OCR-Systeme mit Unterstützung für dutzende Sprachen.

Die Integration in Nextcloud läuft über eine eigene App, im Normalfall mit dem Namen „Full Text Search – OCR“. Diese App ist in Wahrheit ein Aufrufer für das Tesseract-Binary. Sie reicht eine Bilddatei oder ein gescanntes PDF an den OCR-Dienst weiter. Tesseract gibt anschließend den erkannten Text zurück, der dann in den Index eingespielt wird. Klingt simpel, hat aber Tücken. Tesseract ist kein Alleskönner. Die Qualität der Erkennung hängt stark von der Auflösung des Bildes ab, von der Sauberkeit der Vorlage und natürlich von der Spracheinstellung. Ein blasser, zweitausend Pixel breiter Scan einer Kassenbonreihe wird nicht zuverlässig gelesen. Ein sauberer A4-Scan mit 300 dpi dagegen liefert brauchbare Ergebnisse.

Ein interessanter Aspekt ist, dass Tesseract auch als Werkzeug für handschriftliche Notizen herhalten kann – mit sehr unterschiedlichem Ergebnis. Die Erkennung handschriftlicher Texte ist ein eigenes Thema, das Tesseract in seiner Standardform kaum abdeckt. Hier scheitert dann auch die sonst gutmütige Integration von Nextcloud. Es lohnt sich, die eigenen Erwartungen realistisch zu halten. Wer seinen Cloud-Bestand überwiegend aus sauberen Druckerzeugnissen hat, wird kaum enttäuscht. Wer aber mit krakeligen Notizen rechnet, sollte sich besser nach spezialisierten Zusatzdiensten umsehen.

Die OCR-App fragt bei jedem Indexierungsvorgang das installierte Tesseract-Binary per Skript ab. Das hat Auswirkungen auf die Performance. Jede Bilddatei, jede gescannte PDF-Seite muss sequenziell verarbeitet werden. Das ist nicht mit einem GPU-beschleunigten neuronalen Netz vergleichbar, das in Sekundenbruchteilen Text aus Fotos holt. Für viele Anwendungen reicht die Geschwindigkeit aus. Bei einem größeren Ordner mit mehreren hundert gescannten Seiten kann die Indexierung allerdings den ganzen Nachmittag beanspruchen. Ein pragmatischer Ansatz ist es, die OCR-Indexierung nur für bestimmte Ordner zu aktivieren und den Rest von der Verarbeitung auszuschließen. Das spart nicht nur Zeit, sondern auch Nerven.

Die Praxis: Installation und Konfiguration

Um zu verstehen, ob dieser Aufwand sich lohnt, muss man es einmal selbst aufsetzen. Die Konfiguration startet mit dem Server. Auf einem Ubuntu- oder Debian-System installiert man zunächst Tesseract selbst. Das geschieht über den Paketmanager, wobei die Sprachpakete gesondert installiert werden müssen. Für den deutschsprachigen Raum ist neben der Standardsprache Englisch auch tesseract-ocr-deu nötig. Je nach Distribution sind die Paketversionen unterschiedlich alt. Meist steht hier nicht die neueste Tesseract-Version zur Verfügung, sondern eine etwas zurückliegende. Das ist nicht tragisch, wirkt sich aber gelegentlich auf die Erkennungsqualität aus. Wer die aktuellste Version benötigt, muss auf die offiziellen Binärpakete von Google zurückgreifen, was die Komplexität erheblich erhöht.

Danach kommt die Elasticsearch-Integration ins Spiel. Nextcloud benötigt einen funktionierenden Index-Server. Viele Administratoren wählen hierfür den Weg über Docker. Ein einfacher Container mit Elasticsearch in der passenden Version, eine Festplattenpartition für die Indexdaten – das reicht für den Anfang. Die Einrichtung ist kein Hexenwerk, aber sie erfordert ein wenig Docker-Wissen und ein Gefühl für Netzwerkports. Ein typischer Fehler ist es, die Elasticsearch-Version falsch zu wählen. Das Nextcloud-Ökosystem war anfangs stark an Elasticsearch in der Version 6 und 7 orientiert. Mit OpenSearch, dem mittlerweile getrennten Fork von Elasticsearch, und der Elasticsearch-Standardversion gibt es immer wieder Kompatibilitätsprobleme. Die Grundregel: Die im App Store angegebene kompatible Version verwenden, nicht einfach die neueste herunterladen.

Nun installiert man die Nextcloud-Plugins. Das sind mindestens vier Stück: das Framework „Full Text Search“, den Elasticsearch-Adapter, den Files-Provider und die OCR-App. Die Installation geschieht bequem über den App-Store innerhalb von Nextcloud. Danach stehen die Konfigurationsschalter bereit. Dazu gehört die Angabe der Elasticsearch-Adresse, die Wahl des Suchindizes und die Entscheidung, ob der Benutzer die Indizierung in den eigenen Einstellungen steuern darf. Die Freiheit, per Benutzer abwählen zu können, hat einen guten Grund: Nicht jeder möchte, dass seine sensiblen Unterlagen im Rahmen eines Probezeitraums sofort indexiert werden. In der Praxis erleichtert die zentrale Verwaltung den Betrieb ungemein. Die eigene Konfiguration im Administratorbereich ist fast selbsterklärend, sofern man die Netzerkverbindungssettings richtig setzt.

Es folgt der Moment der Wahrheit: die Ersteinrichtung. Wer kein begrenztes Testgelände nutzt, sondern einen bestehenden Account mit tausenden Dateien besitzt, sollte den Index nicht vom Cron erledigen lassen. Ein bewährtes Vorgehen ist der Aufruf des Kommandozeilenbefehls mit der Option --reset und dem Namen eines Testordners. So indiziert man zunächst eine kleine Anzahl von Dateien und prüft die Ergebnisse. Ein praktischer Hinweis: Die Suche zeigt normalerweise nachgeschärfte Ergebnisse an, die direkt aus dem Index kommen und sich von der Standard-Suche unterscheiden. Es ist dann auch sichtbar, wenn Treffer in Dateiinhalten auftauchen.

Wer keine Elasticsearch-Infrastruktur aufbauen möchte, hat immerhin die Option, den mitgelieferten „Standalone“-Modus zu nutzen. Dabei arbeitet Nextcloud mit einer internen Suche, die allerdings weniger performant ist und sich eher für kleinere Installationen eignet. Der deutliche Leistungsunterschied zeigt sich bei einer größeren Dateimenge. Wer 50.000 Dokumente oder mehr durchsucht, merkt schnell, dass die externe Suche der internen deutlich überlegen ist. Es gibt einen Grund, warum das Fulltext-Search-Projekt im Unternehmenskontext fast ausschließlich mit einer echten Suchmaschine betrieben wird.

Schwächen und Tücken im Betrieb

Was beim Arbeiten mit Fulltext Search schnell auffällt: Die Suche ist ein mächtiges Werkzeug, aber sie verzeiht keine halbherzige Installation. Sobald Tesseract nicht korrekt eingebunden ist oder der Cronjob zu selten läuft, zeigt sich die Suche von ihrer frustrierenden Seite. Dateien bleiben verschwunden, obwohl sie längst in der Cloud liegen. Oder die Suchergebnisse veralten. Ein Beispiel aus der Praxis: Ein Nutzer legt heute eine neue Version seines Vertragsentwurfs ab, sucht morgen nach einem Begriff, der nur im neuen Dokument vorkommt – und wird fündig, aber aus der alten Version. Das führt zu peinlichen Situationen, besonders in Teams.

Dazu kommt die Trägheit der Indexierung. Der Prozess arbeitet asynchron, was im Prinzip auch gut ist, weil es die Cloud nicht ausbremst. Doch bei großen Beständen dauert es eben seine Zeit, bis der Index vollständig befüllt ist. Ein Schritt, den man nicht unterschätzen sollte: die Größe des Index. Elasticsearch ist dafür bekannt, ordentlich Festplattenplatz zu belegen. Der Index ist oft größer als die Summe der Dateien, aus denen er gespeist wird. Das liegt an den Verarbeitungsschritten und der internen Datenhaltung von Elasticsearch. Was für einen kleinen Testserver noch verschmerzbar ist, kann bei einer mittleren Installation auf einem Cloud-Anbieter ins Geld gehen, wenn der Speicher knapp kalkuliert ist.

Nicht zuletzt ist da die Frage der Sicherheit. Ein zentraler Index ist ein attraktives Angriffsziel. Wer Elasticsearch ungeschützt im Netzwerk betreibt, macht sein ganzes Unternehmen verwundbar. Die Nextcloud-Dokumentation weist auf die Risiken hin, aber viele überhören das erst dann, wenn der Index-Server bereits im Logging sichtbar ist. Es gibt mehrere unschöne Berichte aus der Praxis, in denen unsichere Elasticsearch-Cluster auf offenen Ports mit sensiblen Daten entdeckt wurden – in einem Fall sogar bei einem öffentlichen Dienst. Das ist keine Kritik an Nextcloud, sondern an der Betriebsvernachlässigung. Wer die Architektur übernimmt, übernimmt auch die Verantwortung für den Transportweg und die Zugriffsbeschränkung des Indexes.

Ein weiterer Stolperstein ist der Umgang mit Sonderzeichen und Suchanfragen. Elasticsearch arbeitet mit einer eigenen Suchsyntax. Wer in der Quick-Suche der Nextcloud-Oberfläche nach einem exakten Begriff sucht, bekommt möglicherweise andere Ergebnisse als bei der Suche im Elasticsearch selbst. Auch Umlaute und die unterschiedliche Behandlung von Groß- und Kleinschreibung können zu Abweichungen führen. Ein Großteil dieser Unschärfen lässt sich über die Analyzer-Einstellungen beheben, aber das erfordert ein Verständnis für die interne Funktionsweise von Elasticsearch. Für blutige Anfänger empfiehlt es sich, zunächst mit den Standardeinstellungen zu arbeiten und die Unterschiede zur gewohnten Suche bewusst in Kauf zu nehmen.

In der Projektentwicklung ist die Sache mit der Sprachunterstützung deutlich einfacher. Tesseract verfügt über eine große Auswahl an Sprachmodellen. Die Integration in Nextcloud ermöglicht es, die Standardsprache der OCR-Erkennung festzulegen. Mit der Installation deutscher und englischer Sprachpakete ist man in den meisten Fällen gut beraten. Bei einer international aufgestellten Firma benötigt man gelegentlich auch französische oder spanische Pakete. Das geht zwar problemlos, erhöht aber die CPU-Last bei der Indexierung, weil Tesseract für jede Datei alle Sprachen ausprobieren muss. Hier lohnt sich ein Blick in die Konfigurationsdatei, wo sich die Sprachenreihenfolge bestimmen lässt. Ein cleverer Trick ist es, die Standardsprache auf Englisch zu setzen und Deutsch als zweite Sprache hinzuzufügen – wobei das Ergebnis je nach Dateityp besser oder schlechter ist.

Alternativen und Erweiterungen im Ecosystem

Das Fulltext-Search-Framework ist nicht auf die Dateisuche beschränkt. Inzwischen existieren viele Provider, die den Suchindex nutzen. Beispielsweise ist es möglich, Kalender und Kontakte zu durchsuchen. Auch der E-Mail-Client, sofern in Nextcloud integriert, lässt sich über den Volltextindex erschließen. Das ist interessant für Anwender, die nicht nur Dateien, sondern auch ihre Kommunikationshistorie durchsuchen müssen. Auch die Suche in Chat-Nachrichten oder im Bereich „Externe Daten“ lässt sich über eigene Adapter realisieren. Das Framework erweist sich damit als offen für viele Erweiterungen, die über den eigentlichen Bereich „Suchmaschine“ hinausgehen.

Wer hingegen eine reine Dateisuchlösung sucht, findet ein paar Alternativen. Nextcloud selbst hat mit „Recognize“ eine Funktion eingebaut, die Bilder nach Motiven und Orten klassifiziert. Sie arbeitet nicht auf Textbasis, sondern ergänzt das Spektrum um eine visuelle Suche. Damit lassen sich Bilder wiederfinden, deren Inhalt sich nicht in Tesseract-OCR-Worte fassen lässt, etwa Fotos von bestimmten Landschaften oder Personen. In der Praxis nutzt man beide Werkzeuge parallel. Dabei zeigt sich, wie mächtig eine Suchzentrale in einer Cloud geworden ist. Was als einfache Dateisuche begann, ist mittlerweile eine Auskunftei über den gesamten Datenbestand der Organisation.

Das Elasticsearch-Backend kann im Übrigen nicht nur von Nextcloud genutzt werden. Ein zentraler Indexserver ist auch in anderen Kontexten nützlich, etwa für Log-Analysen oder die Suche in Webshop-Produkten. Unternehmen, die bereits Elasticsearch im Einsatz haben, können das Nextcloud-Fulltext-Framework in diese bestehende Infrastruktur integrieren. Das spart Ressourcen und vermeidet parallele Systeme. Der Aufwand dafür ist überschaubar: Man erstellt einen zusätzlichen Index und konfiguriert die Zugriffsdaten in Nextcloud. Die herausforderndste Aufgabe ist es, die verschiedenen Netzwerk-Komponenten sicher zu verbinden – etwa über ein eigenes Virtual LAN oder eine abgesicherte Firewall-Regel.

Ein interessanter Aspekt ist auch die Integration von unstrukturierten Daten. Das Fulltext-Search-Ökosystem kann nicht nur standardisierte Dokumente verarbeiten, sondern auch EML-Dateien, HTML-Dateien und sogar Rohdaten aus Datenbankexporten. Es braucht aber immer einen passenden Extraktor. Für gängige Formate liefert Nextcloud die Extraktoren mit; für exotische Formate ist der Administrator gefordert. In der Praxis stellt sich aber heraus, dass die meisten Nutzer nur eine Handvoll Formate verwenden: PDF, Text, DOCX, XLSX und vielleicht noch klassische E-Mail-Exporte. Für diese Kerntypen funktioniert das System zuverlässig.

Betriebserfahrung und Performance-Ueberlegungen

Wer die Umgebung sorgfältig eingerichtet hat, erlebt bei der Suche ein kleines Wunder. Die integrierte Suchleiste der Cloud nimmt eine Phrase auf, und die Ergebnisse erscheinen nach wenigen Millisekunden. Das Gefühl, das sich dabei einstellt, ist bei vielen Usern von anfänglicher Skepsis geprägt – bis sie feststellen, dass die Suchergebnisse sogar besser sind als die von manchen Google-Suchabfragen. Das ist dem Umstand geschuldet, dass der Index die Berechtigungen kennt und den Suchraum vorfiltert. Die Ergebnisse sind also nicht nur schnell, sondern auch sicher. Diesen Vorteil erreicht man mit anderen Suchlösungen nur schwer.

Allerdings sollte man sich über die Serverlast im Klaren sein. Die kontinuierliche Indexierung über den Cronjob beansprucht CPU und Arbeitsspeicher. Insbesondere das Vorsortieren der Dateien in Elasticsearch erzeugt laufende Schreibzugriffe auf die Festplatte. Bei einer komplexen Installation mit vielen benutzerbezogenen Indizes ist die Gefahr groß, dass der Server an seine Grenzen stößt. Ich habe es selbst erlebt, wie ein mit fünfzig Benutzern betriebener Nextcloud-Server durch die Volltextindexierung so stark belastet wurde, dass die Reaktionszeiten der Web-GUI spürbar stiegen. Die Lösung bestand darin, die Indizierung in ein Zeitfenster außerhalb der Bürozeiten zu verlegen und parallel die Rechtezuordnung für Suchanfragen zu vereinfachen.

Wer Tesseract auf dem gleichen Rechner wie die Nextcloud laufen lässt, muss besonders aufpassen. Die Spracherkennung nutzt gerne mehrere CPU-Kerne und belegt überraschend viel Arbeitsspeicher. Ist Tesseract als Zusatzdienst auf dem gleichen Host aktiviert, konkurriert es ständig mit dem Webserver um Ressourcen. Die sauberste Architektur sieht vor, Tesseract auf einem eigenen Dienst zu betreiben. Dazu eignen sich zum Beispiel separate Docker-Container, die nur für die OCR-Verarbeitung zuständig sind. Der Komplexitätsgrad steigt damit wieder, aber die Erfahrung zeigt, dass sich diese Trennung auf stabilen Servern schnell auszahlt.

Bei der Erkennungsqualität von Tesseract sollte man nicht den Status quo sehen, sondern die Entwicklung. Das Werkzeug hat sich in den letzten Jahren stetig verbessert. Insbesondere mit der Unterstützung von mehreren Sprachen innerhalb eines Dokuments ist Tesseract inzwischen deutlich robuster. In der Praxis sieht man immer wieder deutsche Dokumente, in denen englische Firmenbezeichnungen vorkommen – ein Problem für ältere OCR-Engines. Tesseract meistert solche Mischverhältnisse inzwischen recht gut, solange die Standardsprache richtig gesetzt ist. Ein guter Test für die eigene Installation besteht darin, ein kurzes Dokument mit Umlauten und Sonderzeichen gescannt hochzuladen und nach einem markanten Begriff zu suchen. Der Index sollte diesen Begriff schnell finden – anderenfalls muss an den Analyzer-Einstellungen geschraubt werden.

Eine Überlegung, die Administratoren oft übersehen: Die Indexierung erfasst nur den aktuellen Zustand. Wenn eine Datei verändert wird, muss sie erneut indiziert werden. Das passiert automatisch beim nächsten Lauf des Cronjobs, aber eben nicht in Echtzeit. Bei einer stark frequentieren Cloud mit vielen Dateiänderungen kann es passieren, dass die Suche ständig veraltet ist. Abhilfe schafft hier eine Erhöhung der Cron-Frequenz. Idealerweise lässt man den Nextcloud Cron alle fünf Minuten laufen. Die Last ist verschmerzbar, sofern der Index-Server nicht auf demselben Rechner wie die Nextcloud läuft. Ein praktischer Kompromiss ist die Trennung in einen langsamen und einen schnellen Index.

Datenschutz und Aufbewahrung

Der Volltextindex ist auch ein Datenschutzthema. Wer gescannte Verträge, interne Rundschreiben oder persönliche Unterlagen in einer Nextcloud aufbewahrt, möchte nicht, dass ein Administrator des Unternehmens den Elasticsearch-Index einfach mitgrep nach bestimmten Begriffen durchsuchen kann. Nextcloud bewahrt hier die Souveränität der Benutzer: Der Index enthält die Texte, aber der Zugriff wird über die Nextcloud-eigene Rechtestruktur geregelt. Der Administrator des Servers hat dennoch die Möglichkeit, den Index zu durchsuchen, wenn er Zugriff auf die Elasticsearch-Konsole hat. Das ist eine architektonische Schwachstelle, die man kennen sollte. Verschlüsselungsmechanismen innerhalb von Elasticsearch selbst sind nicht die Regel.

Ein ähnliches Thema ist die Aufbewahrung gelöschter Daten im Index. Wenn ein Benutzer eine Datei aus Nextcloud löscht, verschwindet sie aus dem Index – nach einem gewissen Zeitraum. Bis der Indexbereiniger läuft, kann eine gelöschte Datei unter Umständen noch über die Suche gefunden werden. Das widerspricht dem allgemeinen Grundsatz, nach dem ein Löschvorgang unverzüglich wirken soll. In der Praxis ist das selten ein kritischer Punkt, aber für sehr sensibel verwaltete Daten kann es relevant sein. Die Konfiguration des Indexbereinigers sollte deshalb sorgfältig erfolgen und in den Wartungsprozess der Cloud einbezogen werden.

Wer die Integration von Tesseract in Nextcloud nutzt, muss wissen, dass die OCR-Erkennung nicht nur den reinen Text über dem Bild legt, sondern die Ergebnisse dauerhaft speichert. Es ist also nicht so, dass die Analyse nur beim Durchsuchen stattfindet. Die extrahierten Textdaten werden im Suchindex abgelegt und als Teil des Dateiinhalts behandelt. Das ist notwendig, damit die Suche schnell funktioniert. Es ist aber auch ein Fakt, den man bei der Aufbewahrungsfrist des Index berücksichtigen muss. Wer sensible Daten nach einer bestimmten Zeit aus dem Bestand entfernen will, muss nicht nur die Originaldatei löschen, sondern auch den Index aktualisieren. Genau dafür gibt es den Befehl occ fulltextsearch:index --reset.

Fazit

Die Kombination aus Nextcloud Fulltext Search, dem Files-Provider und Tesseract OCR ist eine der mächtigsten Funktionen, die die Cloud zu bieten hat – wenn man sie richtig aufsetzt. Sie verwandelt eine Ablage in ein Archiv, das auf Wunsch sogar die in den digitalen Briefkästen abgelegten Dokumente durchsucht. Wer einmal erlebt hat, wie eine gescannte Apothekenrechnung auf das Stichwort „Ibuprofen“ hin gefunden wird, der wird nicht zurückwollen. Der Preis dafür ist jedoch nicht gering: Man benötigt eine saubere Installation mit einem dedizierten Index-Server, Tesseract als OCR-Dienst und einen einigermaßen perfekt konfigurierten Cronjob. Die Einarbeitungszeit beträgt je nach Kenntnisstand einige Stunden – und die Dokumentation des Projekts ist nicht immer so klar, wie man es sich wünschen würde.

Nextcloud positioniert sich mit dieser Funktion zunehmend als ernsthafte Alternative zu proprietären Lösungen wie Microsoft SharePoint oder Google Drive. Was dort oft als Premiumfunktion tief im Tarifdschungel versteckt ist, steht in Nextcloud als Open-Source-Werkzeug für motivierte Administratoren bereit. Der Reiz liegt im Modularen, im Selbstbau. Man muss nicht jeden Baustein übernehmen, sondern kann sich das System auf die eigenen Bedürfnisse zuschneiden. Das entspricht dem Geist der Open-Source-Community, die auf diesen Seiten schon immer wurde – und die deshalb auch gewillt ist, die anfängliche Konfigurationshürde zu nehmen.

Für erfahrene Sysadmins ist das vorgestellte Setup ein dankbares Projekt. Es verbindet bekannte Technologien wie Elasticsearch und Tesseract mit der vertrauten Klick-Anmutung von Nextcloud. Nicht zuletzt bietet die Kombination die Gelegenheit, sich mit der Nachbardisziplin der Suchmaschinenoptimierung vertraut zu machen – nur eben für den internalen Gebrauch. Die Analyse von Dokumentenbeständen nach bestimmten Begriffen wird dadurch zum Kinderspiel. Und die Bereitschaft, sich auf dieses Thema einzulassen, führt in vielen Fällen zu einer überraschenden Entdeckung: Die eigene Datenablage ist viel wertvoller, als man glaubt – sofern man sie durchsuchen kann.