Nextcloud Full Text Search und PDF: Was wirklich im Index landet – und was nicht

Es ist ein Ritual, das viele Administratoren kennen. Die Nextcloud läuft seit Jahren, die Ablage ist gewachsen, irgendwo liegen 38.000 Dateien, und dann kommt die Frage aus der Fachabteilung: „Sag mal, in welchem Dokument stand noch gleich die Passage zur Kündigungsfrist bei Rahmenverträgen?“ Die Antwort lautet in zu vielen Installationen: in gar keiner, jedenfalls nicht über die Suche. Denn die Standardsuche von Nextcloud durchsucht Dateinamen, Ordnerpfade und in begrenztem Umfang Metadaten. Den Inhalt einer PDF-Datei interessiert sie nicht. Wer dort sucht, findet HB_Vertrag_final_v3_korr.pdf – aber nicht die Zeile auf Seite 14, in der die sechswöchige Frist steht.

Genau an dieser Stelle kommt die Full-Text-Search-Erweiterung ins Spiel, im deutschsprachigen Raum meist als Nextcloud Volltextsuche bezeichnet. Sie baut einen echten Suchindex über Dateiinhalte auf, inklusive PDF-Dokumenten. Klingt nach einer App installieren, Häkchen setzen, fertig. Ist es nicht. Zwischen „App aktiviert“ und „die Suche findet tatsächlich das Richtige“ liegen ein paar Entscheidungen, ein Suchbackend, eine Extraktionskette und die unangenehme Frage, ob die PDFs überhaupt maschinenlesbaren Text enthalten.

Warum ausgerechnet PDFs zum Problemfall werden

Ein PDF ist kein Textdokument, sondern ein Container. Darin stecken Objekte, Streams, Schriften, Vektorgrafiken, manchmal eingebettete Bilder – und manchmal eben auch Text. Entscheidend ist, wie die Datei entstanden ist. Ein PDF, das aus Word oder LibreOffice exportiert wurde, bringt in aller Regel einen sogenannten Textlayer mit. Die Buchstaben sind als Zeichenketten mit Position auf der Seite abgelegt, und eine Extraktionssoftware kann sie herausziehen. Das funktioniert meist erstaunlich gut, gelegentlich mit kleinen Artefakten bei Ligaturen oder Spaltensatz, aber im Kern brauchbar.

Ein PDF aus einem Flachbettscanner ist etwas völlig anderes. Da liegen JPEG- oder CCITT-komprimierte Bilder auf den Seiten, der Text existiert nur als Pixelmuster. Für die Suche ist so eine Datei ein schwarzes Loch. Man kann hineinschauen, aber nicht hineingreifen. Erst die optische Zeichenerkennung, kurz OCR, macht daraus wieder Text. Und damit ist klar: Wer Nextcloud Full Text Search produktiv nutzen will, muss sich mit zwei unterschiedlichen Verarbeitungswegen beschäftigen – der Extraktion vorhandener Textschichten und der nachträglichen Erkennung bei Scans.

Ein interessanter Aspekt dabei: Nur ein Teil der PDF-Probleme hat überhaupt mit OCR zu tun. In der Praxis scheitert die Suche deutlich häufiger an fehlenden Extraktionswerkzeugen, an zu großen Dateien oder an einem Index, der nie vollständig aufgebaut wurde. Der Scan ist das medienwirksame Problem, die halbfertige Indexierung ist das alltägliche.

Die Architektur: Drei Apps, die zusammenspielen müssen

Die Full-Text-Search-Landschaft in Nextcloud ist modular aufgebaut, und das erklärt, warum die Einrichtung mehr Schritte hat als bei einer normalen App. Im Kern gibt es drei Rollen. Da ist zunächst die eigentliche App fulltextsearch, die als Vermittler arbeitet: Sie verwaltet, welche Datenquellen es gibt, welches Suchbackend verwendet wird und wie Änderungen in die Warteschlange kommen.

Dann braucht es mindestens einen Provider, also eine Datenquelle. Für Dateien ist das die App files_fulltextsearch. Sie liefert die Inhalte aus der Nextcloud-Files-Schicht, also nicht nur die Dateien auf dem lokalen Datenverzeichnis, sondern auch alles, was über externen Speicher eingebunden ist – SMB-Freigaben, S3-Buckets, WebDAV-Mounts. Und schließlich braucht es ein Backend, in Nextclouds Sprachgebrauch eine Platform. Das ist in der Praxis fast immer Elasticsearch, umgesetzt über die App fulltextsearch_elasticsearch. Dazu gesellen sich Extractors, also Extraktoren, die aus den Rohdateien Text machen.

Wichtig zu wissen: Diese App-Kombination hat über die Jahre mehrere Umbauten erlebt. Ältere Anleitungen im Netz beschreiben Kommandos, Konfigurationsschlüssel und Backend-Versionen, die es in dieser Form nicht mehr gibt. Wer heute recherchiert, stößt auf drei Generationen von Dokumentation gleichzeitig – und wundert sich, warum die Hälfte davon nicht greift. Das ist eine der häufigsten Fallen überhaupt, noch vor allen technischen Details.

Was der Provider tatsächlich indexiert

Der Datei-Provider legt nicht einfach nur den Text ab. Er erzeugt Dokumente mit Metadaten: Dateiname, Pfad, MIME-Typ, Änderungsdatum, Dateigröße, Eigentümer. Dazu kommt der extrahierte Inhalt, sofern einer extrahiert werden konnte. Diese Trennung ist in der Praxis wichtig, weil sie erklärt, warum die Suche manchmal Dateien über den Dateinamen findet, deren Inhalt nie indexiert wurde. Das ist kein Fehler, sondern das erwartete Verhalten – es sieht nur aus wie ein Teilerfolg.

Ebenfalls relevant: Der Index speichert keine Kopie der Datei, aber sehr wohl den Klartextinhalt. Wer ein PDF mit einem Personalausweis scannt, findet den Namen später als Suchbegriff wieder. Dazu an späterer Stelle mehr, denn das ist datenschutzrechtlich kein Nebenaspekt, sondern der Kern der Sache.

Elasticsearch: der Motor, der Ressourcen frisst

Elasticsearch ist kein schlanker Dienst, sondern eine Java-Anwendung mit eigenem JVM-Heap, Clusterverwaltung und einem Speicherbedarf, den man nicht wegdiskutieren kann. Für eine kleine Installation mit ein paar Hundert Nutzern mag das noch angehen. Wer jedoch eine Ablage mit mehreren hunderttausend Dokumenten indexieren will, sollte den Suchdienst nicht auf demselben Blech betreiben wie die Nextcloud selbst – sonst konkurrieren PHP-FPM, Datenbank und der Ingest-Prozess um dieselben Kerne, und das merkt man zuerst an der Oberfläche.

Ein minimales Setup mit Docker sieht etwa so aus:

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.22
    environment:
      - discovery.type=single-node
      - ES_JAVA_OPTS=-Xms4g -Xmx4g
      - bootstrap.memory_lock=true
      - xpack.security.enabled=true
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - esdata:/usr/share/elasticsearch/data
    ports:
      - "127.0.0.1:9200:9200"
volumes:
  esdata:

Drei Dinge daran sind bemerkenswert. Erstens die Bindung an 127.0.0.1. Ein Elasticsearch, der offen im Netz steht, ist keine Suchmaschine, sondern eine Datenpanne mit Verzögerung. Zweitens der Heap. Zwei Gigabyte sind das absolute Minimum, vier sind für mittlere Installationen realistisch, und darüber sollte man den Heap nicht beliebig wachsen lassen – Elasticsearch nutzt zusätzlich den Dateisystem-Cache, und ein zu großer Heap nimmt dem Betriebssystem genau den weg. Drittens bootstrap.memory_lock: ohne diese Einstellung wandern Teile des Heaps in den Swap, und eine Suche, die in den Swap läuft, ist keine Suche mehr, sondern eine Wartezeit.

Auf dem Host muss außerdem vm.max_map_count angehoben werden, üblicherweise auf 262144. Fehlt das, startet der Dienst mit einer Fehlermeldung, die nicht gerade selbsterklärend ist. Und: Elasticsearch verweigert den Start als root, was man einmal ausprobiert haben muss, um es nie wieder zu vergessen.

Die Versionsfrage verdient einen eigenen Absatz. Elasticsearch 8 hat eine Reihe von Änderungen mitgebracht, unter anderem einen Kompatibilitätsmodus für ältere Clients. Ältere Ausgaben der Nextcloud-Suchapps sprechen noch mit der 7er-API und laufen deshalb ins Leere, wenn der Server auf 8.x aktualisiert wurde. Wer heute neu aufsetzt, sollte die Kompatibilitätsmatrix der App prüfen, statt einfach die neueste Version zu ziehen. OpenSearch, der freie Fork, versteht sich in vielen Fällen mit den bestehenden Clients – offiziell unterstützt ist er aber nicht, und die Versionsprüfung der App kann hier im Weg stehen. Wer diesen Weg gehen will, sollte mit Testaufwand rechnen, nicht mit einer Plug-and-Play-Lösung.

Die Einrichtung in der Praxis

Ist Elasticsearch erreichbar und die vier Apps – fulltextsearch, files_fulltextsearch, fulltextsearch_elasticsearch, files_fulltextsearch_tesseract – sind aktiviert, geht es an die Konfiguration. Ein Teil davon lässt sich in der Administrationsoberfläche erledigen, ein Teil gehört auf die Kommandozeile. Wer den Index zum ersten Mal aufbaut und dabei hunderttausend Dateien anfasst, sollte das ohnehin nicht im Browser anstoßen, sondern in einer screen– oder tmux-Sitzung.

occ fulltextsearch:check
occ fulltextsearch:configure '{"elasticsearch.host": "127.0.0.1", "elasticsearch.port": 9200}'
occ fulltextsearch:index

Die genauen Schlüsselnamen variieren je nach Version und sollten in der Adminoberfläche der App gegengeprüft werden – dort werden die wirksamen Werte angezeigt. occ fulltextsearch:check ist der erste Anlaufpunkt, wenn etwas nicht funktioniert: Der Befehl zeigt, ob eine Platform registriert ist, ob der Provider läuft und ob die Verbindung zum Backend steht.

Der Erstlauf ist der Moment der Wahrheit. Bei größeren Installationen dauert er Stunden, mitunter Tage. Das liegt nicht am Suchindex selbst, sondern an der Extraktion. Jede PDF-Datei muss geöffnet, gelesen und geparst werden. Liegen die Dateien auf einer eingebundenen SMB-Freigabe, wird dabei jedes einzelne Dokument über das Netz gezogen. Wer eine solche Einbindung mit zehntausend PDFs hat, sollte vorher prüfen, ob das Backbone das mitmacht – und ob die Indexierung sinnvollerweise nachts läuft.

Für den laufenden Betrieb registriert die App Hintergrundjobs, die bei Änderungen den Index aktualisieren. Diese Jobs laufen über den regulären Nextcloud-Cron. Wichtig ist hier der Cron-Modus: Im Betrieb mit dem AJAX-Cron, bei dem Nextcloud die Jobs über einen Browseraufruf abarbeitet, werden lange Indexierungsaufträge gerne mittendrin abgebrochen. Wer die Volltextsuche ernsthaft betreiben will, kommt um einen echten systemweiten Cronjob nicht herum.

Und noch ein Punkt, der in Anleitungen gerne untergeht: Die benutzerdefinierte Konfiguration der Analyzer. Für deutschsprachige Inhalte ist ein Stemming sinnvoll, sonst findet die Suche nach „Verträge“ nicht die Dokumente mit dem Wort „Vertrag“. Dafür gibt es Analyzer-Einstellungen pro Sprache. Wer sie ändert, muss anschließend neu indexieren – ein verändertes Analyzer-Setup auf einem bestehenden Index ist keine Konfigurationsänderung, sondern ein Neuaufbau. Der Befehl occ fulltextsearch:reset wirft den Index weg; danach beginnt der Erstlauf von vorne. Das will man einmal planen, nicht zweimal.

PDF-Indexierung im Detail

Kommen wir zum Kern. Für PDFs mit Textlayer braucht es eine Extraktionskomponente, die den Inhaltsstrom des Dokuments ausliest. Je nach Version der Apps kommen dafür unterschiedliche Werkzeuge zum Einsatz – häufig externe Kommandozeilenprogramme wie pdftotext aus dem Paket poppler-utils, teils auch PHP-Bibliotheken, die das direkt erledigen. Fehlt das jeweilige Werkzeug auf dem Server, wird die Datei zwar indexiert, aber ohne Inhalt. Das äußere Erscheinungsbild dieses Fehlers ist heimtückisch: Die Suche liefert Ergebnisse, nur eben nie Treffer aus dem PDF-Text. Man sucht dann den Fehler in der Suche und nicht in der Extraktion.

Ein erster Test ist deshalb immer derselbe: eine PDF mit eindeutigem, nur dort vorkommendem Begriff anlegen, indexieren lassen und suchen. Findet die Suche die Datei über den Dateinamen, aber nicht über den Begriff im Text, ist die Extraktion das Problem. Findet sie gar nichts, stimmt etwas Grundsätzlicheres nicht – dann zuerst occ fulltextsearch:check.

Die zweite Kategorie von Einschränkungen betrifft die Größe. Sehr große PDFs – Jahresberichte mit 800 Seiten, gescannte Baupläne, Broschüren mit hoher Bildauflösung – sind für die Extraktion teuer. Viele Setups begrenzen daher, bis zu welcher Dateigröße Inhalte überhaupt extrahiert werden. Das ist vernünftig, denn eine einzelne Datei mit 400 Megabyte kann die Extraktionskette minutenlang beschäftigen, und der Nutzen steht in keinem Verhältnis. Die Grenze ist ein Kompromiss und sollte bewusst gesetzt werden, nicht per Default belassen.

Drittens: Passwortgeschützte PDFs. Ohne Kennwort kommt kein Extraktor an den Inhalt. Solche Dateien landen als Metadatensatz im Index und bleiben inhaltlich unsichtbar. Für die Praxis heißt das: Wer vertrauliche Verträge als verschlüsselte PDFs ablegt, muss sich entscheiden, ob der Inhalt durchsuchbar sein soll. Beides gleichzeitig geht nicht.

OCR: Scans durchsuchbar machen

Für reine Bild-PDFs hilft nur Texterkennung. Die passende Erweiterung heißt files_fulltextsearch_tesseract und setzt auf Tesseract, die wohl etablierteste freie OCR-Engine. Damit sie arbeitet, müssen auf dem Server zwei Dinge vorhanden sein: die Tesseract-Binärdatei mit den passenden Sprachpaketen – für deutschsprachige Installationen gehört das Paket tesseract-ocr-deu dazu – und ein Werkzeug, um PDF-Seiten in Bilder zu rastern, weil Tesseract selbst keine PDFs liest. Das erledigt in der Praxis ImageMagick mit Ghostscript oder ein Werkzeug aus den poppler-utils.

Die Konfiguration erfolgt in den administrativen Einstellungen der App. Dort wird festgelegt, in welchen Sprachen erkannt werden soll, ob auch Bilder indexiert werden und bis zu welcher Größe die Erkennung laufen darf. Die Sprachwahl ist ein echter Hebel: Wer versehentlich alle verfügbaren Sprachen aktiviert, multipliziert die Laufzeit der Erkennung, ohne bessere Ergebnisse zu bekommen. Zwei bis drei Sprachen sind für die meisten Umgebungen ausreichend.

Ein Wort zur Qualität. Tesseract liefert bei sauberen, geraden Scans mit 300 dpi erstaunlich gute Resultate. Bei schiefen Telefonfotos, schlechten Kontrasten oder handschriftlichen Randnotizen endet die Freundschaft schnell. Die Suche findet dann Wörter, die im Dokument gar nicht stehen, oder sie findet sie eben nicht. Ein ehrlicher Umgang mit den Erwartungen gehört hier dazu: OCR macht Scans durchsuchbar, nicht perfekt lesbar.

Den Workflow einmal sauber aufsetzen

Es gibt einen zweiten, oft unterschätzten Weg. Statt die OCR im Suchindex zu erledigen, kann man die PDF-Datei selbst durchsuchbar machen – mit ocrmypdf auf der Kommandozeile oder über einen Automatisierungslauf. Die Datei erhält dann einen Textlayer, und zwar dauerhaft. Das hat zwei Vorteile: Die Erkennung läuft einmal und nicht bei jedem Reindex, und das Dokument wird auch außerhalb von Nextcloud durchsuchbar, etwa im PDF-Betrachter. Der Preis dafür ist, dass die Datei verändert wird – bei revisionsrelevanten Unterlagen ein K.-o.-Kriterium.

Für beides gibt es Anhänger. Wer Nextcloud mit Workflow-Skripten oder einer externen Automatisierung betreibt, kann eingehende Scans in einem automatisierten Ablauf durch ocrmypdf schicken und erst danach in die Cloud legen. Das ist mehr Aufwand im Vorfeld und weniger Ärger im Betrieb – nicht zuletzt, weil die OCR-Last dann kontrolliert anfällt und nicht den Suchindex blockiert.

Performance, und die Frage nach der Geduld

Ein Volltextindex ist kein Abbild des Dateisystems, sondern eine eigene Datenstruktur mit eigenen Regeln. Als Faustregel gilt: Der Elasticsearch-Index wächst auf ungefähr ein Viertel bis ein Drittel der Textmenge, die tatsächlich extrahiert wurde. Ein reiner Textlayer aus einem 200-Seiten-Handbuch erzeugt also nur wenige Hundert Kilobyte. Kommen OCR-Ergebnisse, große Tabellen und viele Anhänge dazu, geht der Bedarf schnell in die Höhe. Wer auf einer 2-TB-Ablage sitzt, sollte für den Index mit einem Speicherbedarf rechnen, der nicht im zweistelligen Gigabytebereich endet.

Interessant ist der Blick auf den Ingest, also das Einfügen in den Index. Elasticsearch arbeitet mit Shards, und Shards lassen sich nicht ohne Weiteres nachträglich vergrößern. Eine zu klein gewählte Shard-Anzahl bremst später, eine zu groß gewählte erzeugt Overhead. Für eine mittlere Installation ist eine überschaubare Zahl von Shards sinnvoll – wer sich unsicher ist, wählt weniger, nicht mehr. Und für den Index selbst gilt Ähnliches wie für die Warteschlange: Elasticsearch mag es, wenn Daten in Bündeln ankommen. Ein Index, der kontinuierlich mit einzelnen Tröpfchen gefüttert wird, ist langsamer als einer, der in Chargen gefüllt wird.

Wer mehr als ein Nextcloud-System mit Suchindex betreibt – etwa eine Test- und eine Produktionsinstanz – kann in Elasticsearch einen Index pro Instanz anlegen und mit Aliasen arbeiten. Das ist nicht Pflicht, aber es erleichtert den Umbau erheblich. Bei einer Migration lässt sich ein neuer Index aufbauen und anschließend der Alias umbiegen, statt den produktiven Index zu löschen und auf einen tagelangen Neuaufbau zu warten.

Sicherheit und Datenschutz: Der Index als Schattenkopie

Das ist der Teil, der in Einführungsprojekten gerne zu spät kommt. Ein Volltextindex enthält Klartext. Wenn in der Ablage gescannte Personalausweise, Gehaltsabrechnungen, Arztberichte oder Mandantenakten liegen, dann liegen die relevanten Passagen daraus auch in Elasticsearch – in einer Datenbank, die mit den Berechtigungskonzepten von Nextcloud nichts zu tun hat. Wer direkten Zugriff auf das Backend hat, umgeht die Dateifreigaben komplett.

Daraus folgen ein paar sehr konkrete Konsequenzen. Elasticsearch gehört nicht ins offene Netz. Die Security-Features von Elasticsearch sind in der Basic-Lizenz enthalten und damit auch ohne kommerzielle Lizenz nutzbar: Authentifizierung, TLS, Rollen. Es gibt keinen guten Grund, darauf zu verzichten. Wenn Verschlüsselung auf Datenträgerebene ohnehin im Haus Standard ist, sollte das Verzeichnis mit den Elasticsearch-Daten davon nicht ausgenommen werden.

Die Zugriffskontrolle bei der Suche selbst funktioniert anders als es zunächst scheint. Der Index kennt keine Berechtigungen. Die Prüfung passiert bei der Abfrage: Der Provider gleicht die Treffer gegen die Dateidatenbank und die Rechte des suchenden Nutzers ab, bevor Ergebnisse ausgeliefert werden. Das ist der richtige Ansatz, aber es bedeutet auch, dass diese Schicht korrekt funktionieren muss. In der Vergangenheit hat es in diversen Suchanbindungen immer wieder Diskussionen um genau diesen Punkt gegeben. Wer sensible Datenbestände hat, sollte stichprobenartig testen, ob ein Nutzer über die Suche an Inhalte kommt, die er nicht öffnen darf.

Zwei Sonderfälle lohnt es sich zu kennen. Ende-zu-Ende-verschlüsselte Dateien landen gar nicht erst im Index – der Server kann sie schlicht nicht lesen. Und bei serverseitiger Verschlüsselung mit benutzerspezifischen Schlüsseln tut sich die Kommandozeilenindexierung schwer, weil ihr die Sitzung fehlt, in der entschlüsselt wird. Das ist ein bekanntes Spannungsfeld zwischen Verschlüsselung und Suchbarkeit; wer beides will, sollte das vor dem Rollout testen und nicht danach.

Typische Fehler und wo man anfängt zu suchen

Die Fehlerbilder wiederholen sich. Ein kurzer Abgleich, wenn die Suche nicht das tut, was sie soll:

Treffer nur über Dateinamen. Der Klassiker. Fast immer fehlt das Extraktionswerkzeug auf dem Server, häufig pdftotext oder eine vergleichbare Komponente. Zweiter Kandidat: Die Datei überschreitet die konfigurierte Größengrenze.
Überhaupt keine Treffer, auch nicht über den Dateinamen. Meistens wurde der Index nie vollständig aufgebaut, oder der Erstlauf ist abgebrochen. Ein erneuter Lauf mit occ fulltextsearch:index zeigt, ob noch Arbeit offen ist.
Die Schaltfläche für die Inhaltssuche ist verschwunden. Fast immer ein App-Problem nach einem Nextcloud-Update. Die Suchapps haben in der Vergangenheit nicht immer zeitgleich mit neuen Nextcloud-Versionen released; für ein paar Tage fehlt dann die Integration, während die App deaktiviert bleibt.
Plötzlich keine Treffer mehr nach einem Elasticsearch-Upgrade. Erst der Kompatibilitätsmodus, dann die Versionsmatrix der App. Hier hilft kein Herumprobieren an den Analyzern, sondern ein Blick in die Logs beider Seiten.
Suche findet Treffer, die der Nutzer nicht sehen dürfte. Sofortiger Handlungsbedarf. Das ist kein Feinschliff, sondern ein Berechtigungsproblem, und es wiegt schwerer als jede Performance-Frage.

Für die Fehlersuche selbst gilt eine einfache Reihenfolge: erst prüfen, ob die Extraktion funktioniert, dann, ob der Index vollständig ist, dann, ob die Suche die richtigen Ergebnisse filtert. Diese Reihenfolge erspart viel Zeit, weil sie in der Regel verhindert, dass man die Suche debuggt, während die eigentliche Ursache drei Schritte vorher liegt.

Grenzen, Alternativen und ein Blick nach vorn

So nützlich die Volltextsuche ist, sie bleibt eine Stichwortsuche. Wer nach „Verträge mit Lieferanten aus Frankreich, die 2023 geändert wurden“ sucht, wird mit einem invertierten Index nicht glücklich. Solche Fragen beantworten seit einiger Zeit Systeme, die auf Vektorähnlichkeit und Embeddings setzen. Auch rund um Nextcloud gibt es inzwischen Bestrebungen in diese Richtung, etwa im Umfeld der Assistenzfunktionen. Ein Ersatz für den klassischen Index sind sie nicht – sie ergänzen ihn, und für den Alltag in einem Dokumentenbestand ist die Stichwortsuche nach wie vor das Werkzeug, das am zuverlässigsten funktioniert.

Als Alternativen zum Elasticsearch-Backend kommen gelegentlich OpenSearch oder schlankere Suchdienste ins Gespräch. Die Auswahl in der Nextcloud-Welt ist hier allerdings überschaubar, und die unterstützte Kombination ist nach wie vor die mit Elasticsearch. Wer experimentiert, sollte das auf einer Testinstanz tun und nicht auf der Ablage, an der die Buchhaltung hängt.

Ein weiterer Aspekt, der in den kommenden Jahren wichtiger werden dürfte: die Frage, ob der Suchindex wirklich jeden Inhalt benötigt. Viele Häuser indexieren hemmungslos alles, inklusive privater Ordner, Feiertagsfotos und jahrelang nicht geöffneter Archive. Das kostet Speicher, Rechenzeit und im Zweifel Ärger, wenn ein Datenschutzbeauftragter nachfragt. Eine bewusste Auswahl des zu indexierenden Bestands ist keine Einschränkung, sondern eine der wirksamsten Maßnahmen überhaupt.

Fazit

Nextcloud Full Text Search ist eine der Funktionen, die den Unterschied zwischen einer Dateiablage und einem funktionierenden Wissensspeicher ausmachen. Für PDF-Dokumente funktioniert sie gut – unter zwei Bedingungen. Erstens muss die Extraktionskette vollständig sein: die richtigen Werkzeuge auf dem Server, eine sinnvolle Größengrenze, ein durchgelaufener Erstindex. Zweitens braucht es eine ehrliche Entscheidung über die Inhalte. Wer gescannte Dokumente durchsuchbar machen will, kommt um Tesseract und die damit verbundenen Kompromisse nicht herum. Wer sensible Bestände hat, muss den Index als das behandeln, was er ist: eine zweite, unverschlüsselte Kopie relevanter Textpassagen.

Die Einrichtung ist nichts für ein Abendessen zwischendurch. Aber sie ist auch kein Hexenwerk, wenn man die drei Komponenten auseinanderhält, den Erstlauf in einer tmux-Sitzung startet und sich vorher überlegt, was eigentlich indexiert werden soll. Danach – das ist die gute Nachricht – läuft das System weitgehend still vor sich hin. Und die Fachabteilung findet irgendwann tatsächlich die Passage auf Seite 14.

Nextcloud Volltextsuche und PDF Was im Index landet und was nicht