NextSearch

Volltextsuche über die Inhalte deiner Nextcloud-Ordner — ohne die Dateien anzufassen

Nextcloud speichert und teilt Dateien, findet aber nichts in ihnen. Wer wissen will, welche PDF von 2019 eine bestimmte Rechnungsnummer trägt, sucht von Hand — Ordner für Ordner, und über mehrere Instanzen hinweg wird es vollends zur Sucharbeit. Nextclouds eigene Volltextsuche gibt es, aber sie will einen Elasticsearch-Cluster daneben, den jemand betreiben muss.

Genau an dieser Stelle setzt NextSearch an. Es indexiert die Ordner, auf die man es zeigt — Unterordner eingeschlossen, über beliebig viele Instanzen — und macht deren Inhalt durchsuchbar. Der Zugriff auf Nextcloud ist dabei strikt lesend: NextSearch kann deine Dateien nicht verändern, verschieben oder löschen. Das ist keine Zusicherung im Kleingedruckten, sondern im Code erzwungen.

Das Problem: gespeichert ist nicht gefunden

Ein Archiv wächst über Jahre. Verträge, Rechnungen, Protokolle, gescannte Post — alles liegt sauber in Nextcloud, geteilt und synchronisiert. Nur der eine Satz, an den man sich erinnert, steht irgendwo in einem dieser Dokumente, und Nextcloud durchsucht nur Dateinamen. Bei einem Ordner geht das noch per Hand. Bei einem gewachsenen Bestand über mehrere Instanzen nicht mehr.

Die naheliegende Antwort wäre Nextclouds offizielle Full-Text-Search-App. Die kann das auch — verlangt aber eine Plattform daneben, in der Praxis einen Elasticsearch-Cluster, der gepflegt, aktualisiert und mit Arbeitsspeicher versorgt werden will. Für viele Setups steht der Betriebsaufwand in keinem Verhältnis zum Ziel: einfach den Inhalt finden.

NextSearch ist die kleinere Antwort auf dieselbe Frage. Ein Stack, ein Befehl, und die Suche steht.

Wie es funktioniert

NextSearch besteht aus wenigen Bausteinen, die per Docker Compose zusammenspielen: ein Nuxt-Frontend, ein Laravel-Backend auf FrankenPHP, Meilisearch als Suchindex, Apache Tika für die Textextraktion samt OCR, dazu Postgres, Redis und ein S3-kompatibler Objektspeicher.

Der Weg eines Dokuments in den Index läuft in vier Schritten:

1. Crawlen. Ein Scheduler prüft im Minutentakt, welcher Ordner fällig ist, und ein Worker liest ihn Ebene für Ebene über WebDAV. Für jede Datei vergleicht er fileid und ETag mit dem gespeicherten Stand — Unverändertes wird übersprungen, nur Neues und Geändertes läuft weiter. Ein zweiter Lauf über einen großen Ordner kostet also fast nichts.
2. Extrahieren. Die geänderte Datei geht an Tika. Für PDFs ohne Textebene greift OCR: erst ein Durchlauf ohne, und wenn dabei zu wenig Text herauskommt, ein zweiter mit Texterkennung. Nur wenn der mehr liefert, wird er behalten — und der Treffer später als OCR-Ergebnis markiert, weil Erkennungsfehler dazugehören.
3. Vorschau rendern. Von der ersten Seite entsteht ein kleines Vorschaubild, damit ein Treffer in der Ergebnisliste wiedererkennbar ist.
4. Indexieren. Volltext und Metadaten landen in Meilisearch, der Volltext zusätzlich als Blob im Objektspeicher.

git clone https://github.com/McGo/NextSearch.git
cd NextSearch
make init          # legt .env an und erzeugt den APP_KEY
$EDITOR .env       # ADMIN_EMAIL und ADMIN_PASSWORD setzen
make up

Danach die Oberfläche unter http://localhost:3000 öffnen, eine Nextcloud-Instanz hinterlegen, einen Ordner wählen. Den Rest erledigt der Scheduler.

Was NextSearch von der Nextcloud-eigenen Suche abhebt

Drei Dinge, die die offizielle Full-Text-Search-App so nicht bietet:

Eine Suche über mehrere Nextclouds. Instanz ist eine Filter-Facette wie jede andere. Man hinterlegt beliebig viele Instanzen und sucht in einem Rutsch über alle. Wer für jeden Kunden eine eigene Cloud betreibt, sucht nicht mehr fünfmal, sondern einmal.

Wer sucht, braucht keinen Nextcloud-Account. Die Zugangsdaten zur Cloud bleiben auf dem Server. NextSearch liefert Treffer und streamt das Originaldokument direkt in den Browser — ohne dass die suchende Person selbst einen Zugang zur Quell-Cloud hat. Ein ganzes Team sucht, ohne dass man dafür Seats auf der Nextcloud anlegt.

Nichts zu sichern außer einer kleinen Datenbank. Nextcloud bleibt die alleinige Quelle der Wahrheit. Alles, was NextSearch daraus ableitet — Suchindex, Vorschaubilder, Text-Blobs — lässt sich jederzeit neu aufbauen. Zu sichern bleibt nur eine kleine Postgres mit Instanzen, Ordnern, Nutzern und Rechten; ein pg_dump, und der Rest baut sich beim nächsten Lauf selbst. Ein Umzug auf einen anderen Server ist entsprechend genügsam.

Zwei Kleinigkeiten am Rande, die den Alltag glätten: Gespeicherte Suchen legen Suchbegriff, Filter und Sortierung unter einem Namen ab — die monatliche Rechnungssuche klickt man nicht jedes Mal neu zusammen. Und wenn der Bestand groß wird, skaliert man mit WORKER_REPLICAS=6 genau den Flaschenhals, der zählt: die Textextraktion. Der Delta-Crawl hält alles Übrige billig.

Die Alternativen — und warum keine dasselbe löst

Nextcloud Full Text Search

Die offizielle App kann Volltextsuche über die Dateien eines Nutzers, rechte-genau. Der Preis dafür ist eine Plattform daneben — meist Elasticsearch, ab Nextcloud 26 in Version 8 —, die betrieben, aktualisiert und mit Speicher versorgt werden will. Sie sucht innerhalb einer Instanz und respektiert deren Freigaben exakt. Wer genau das braucht und den Cluster stemmen kann, ist dort richtig. NextSearch tauscht die rechte-genaue Spiegelung gegen ein kleineres, durchschaubares Modell — und den Cluster gegen Meilisearch in einem Container.

Paperless-ngx

Paperless-ngx ist ein hervorragendes Dokumenten-Management-System — aber ein anderes Werkzeug. Dokumente kommen über ein Consume-Verzeichnis herein, werden verarbeitet und in Paperless' eigenem Bestand abgelegt. Das heißt: Man zieht seine Dateien in Paperless um. Dass man einen bestehenden Ordner nur durchsuchbar machen will, ohne ihn umzuziehen, ist bei Paperless ein oft gestellter, bewusst abgelehnter Wunsch — das System ist auf den eigenen Bestand ausgelegt. NextSearch legt sich stattdessen read-only über die Ordner, die schon in Nextcloud liegen, und bewegt nichts. Fährt man NextSearch herunter und verwirft die Volumes, bleibt in Nextcloud keine Spur. Wer ein DMS mit Verschlagwortung will, nimmt Paperless. Wer seinen bestehenden Nextcloud-Bestand durchsuchbar machen will, ohne ihn anzurühren, nimmt NextSearch.

Recoll, DocFetcher und Co.

Desktop-Volltextsuchen sind mächtig, aber einzelplatzgebunden. Sie indexieren lokale Verzeichnisse für einen Nutzer an einem Rechner. Für einen serverseitigen Index über mehrere Nextcloud-Instanzen, den ein Team gemeinsam nutzt, sind sie nicht gebaut.

Der Kern: Vertrauen als Designentscheidung

Ein Werkzeug, das fremde Dokumente liest und im Team durchsuchbar macht, steht und fällt mit Vertrauen. NextSearch beantwortet das an zwei Stellen — und beide sind bewusst so gebaut.

Der Zugriff auf Nextcloud ist erzwungen lesend. Der einzige Code, der mit einer Instanz spricht, erlaubt exakt vier HTTP-Methoden — GET, HEAD, PROPFIND, OPTIONS — und wirft bei allem anderen eine Ausnahme, bevor überhaupt ein Socket aufgeht. Dieselbe Prüfung hängt zusätzlich als Middleware im HTTP-Client, damit auch künftiger Code den Pfad nicht umgehen kann. Ein Test läuft über jedes Schreib-Verb und weist nach, dass keins durchkommt. NextSearch legt in Nextcloud keine Datei an, ändert keine, verschiebt keine, löscht keine.

Die Rechte spiegelt NextSearch bewusst nicht. Nextclouds Berechtigungen kommen aus Gruppen, Freigaben, Freigabe-Links, Gruppenordnern, externem Speicher und Verschlüsselung. Die zuverlässig nachzubilden hieße, all das zu replizieren und synchron zu halten — und ein Fehler in diesem Spiegel wäre ein stilles Leck. Stattdessen gibt es zwei Rollen und ein kleines Modell: Administratoren verwalten Instanzen, Ordner und Konten; Nutzer sehen nur die Ordner, die man ihnen ausdrücklich zuweist. Wer keinen zugewiesen bekommt, dessen Suche bleibt leer. Ein Modell, das man ansehen und verstehen kann, ist hier die ehrlichere Wahl als eine Spiegelung, der man blind vertrauen müsste.

Für die Praxis heißt das: einen eigenen Nextcloud-Account nur fürs Indexieren anlegen, mit einem App-Passwort statt dem Konto-Passwort, und genau die Ordner freigeben, die durchsuchbar sein sollen. Dann ist die Grenze schon auf der Nextcloud-Seite gezogen. Das App-Passwort liegt bei NextSearch mit dem APP_KEY verschlüsselt in der Datenbank und lässt sich in Nextcloud jederzeit einzeln widerrufen.

Was sonst noch drinsteckt

Jenseits der großen Linien ein paar Dinge, die im Alltag zählen: Die Ergebnisliste filtert über Facetten — Instanz, Ordner, Dateityp, Jahr, Größe, Autor, Sprache, ob OCR im Spiel war, ob eine Vorschau existiert. Werte derselben Facette werden ODER-verknüpft, verschiedene Facetten UND. Der Stack läuft gebündelt auf einem Host, lässt sich aber Stück für Stück nach außen ziehen: Postgres, Redis, Meilisearch und der Objektspeicher können auf externe Dienste zeigen, etwa eine RDS-Instanz oder echtes S3 mit eigenem Prefix. Und die Formatabdeckung reicht über das Übliche hinaus — PDF, Office, OpenDocument, aber auch E-Mails als .eml/.msg mit Betreff, Absender, Empfänger und Text, Tabellen zeilenweise, PowerPoint samt Notizen, EPUB. Was Tika sonst noch kann, schaltet man über eine Liste in der .env frei.

Fazit

NextSearch macht eine Sache: den Inhalt bestehender Nextcloud-Ordner durchsuchbar, self-hosted, ohne die Dateien anzurühren und ohne Cluster daneben. Es spiegelt keine Rechte, es importiert nichts, es kann read-only nicht mehr als lesen. Das ist bewusst schmal gehalten — und genau deshalb überschaubar im Betrieb.

Wer einen gewachsenen Dokumentenbestand hat und darin bisher von Hand sucht, bekommt mit einem docker compose up einen durchsuchbaren Index. Mehr will es nicht sein.

Call to Action

NextSearch ist Open Source und auf GitHub verfügbar: https://github.com/McGo/NextSearch

Ausprobieren geht ohne eigene Nextcloud: make demo zieht eine Wegwerf-Instanz hoch, make demo-seed kippt Beispieldateien hinein — darunter eine textlose Scan-PDF, an der sich die OCR direkt überprüfen lässt.

Wer NextSearch für ein Team oder eine ganze Organisation aufsetzen will — mit eigenem S3, hinter einem Reverse-Proxy, angebunden an mehrere Instanzen — kann sich gerne melden. Als Backend- & Solution Architect kenne ich die Stellen, an denen self-hosted Dokumenten-Suche zwischen „läuft lokal" und „läuft im Betrieb" ins Straucheln kommt.