Die große Nextcloud-Odyssee

oder we aus einem einfachen Skript eine Reise in die Tiefen von Proxmox wurde

Datum: 18. Juni 2025
Autor: Ein tapferer Systemadmin
Café getrunken: Unzählige Kannen.

Es begann so unschuldig. "Ich installiere mal eben schnell Nextcloud auf einer VM", sagte ich zu mir. "Mit Gesichtserkennung, für die Fotos. Wie schwer kann das schon sein? Ein kleines Bash-Skript, das die LAMP-Stack-Installation automatisiert, und die Sache ist in einer Stunde erledigt."

Und außerdem will man ja auf Dauer keine Daten unnötig oder überhaupt bei Google lagern. Und warum ein Script? Naja... man weiß ja nie, ob man mal in Zukunft etwas "schnell" deployen will, was kein Docker ist.

Spoiler: Es war nicht in einer Stunde erledigt. Es wurde zu einer epischen Quest, die mich an den Rand des Wahnsinns und wieder zurückbrachte.

Akt I: Die Skript-Apokalypse

Mein treues Bash-Skript, mein ganzer Stolz, sollte alles erledigen. apt update, apt install, ein bisschen sed hier, eine Prise occ da. Der erste Lauf endete in einem Blutbad aus C++-Kompilierungsfehlern. Eine obskure PHP-Erweiterung namens pdlib schrie mich in Farben an, die ich nicht kannte. Fatal error, compilation terminated. Okay, dachte ich, das ist der Job. Abhängigkeiten jagen.

Was folgte, war ein Abstieg in die tiefsten Kreise der Sysadmin-Hölle.
Ich kämpfte mich durch:

• Fehlende PHP-Header (php.h, zend.h).
• Fehlende dlib-Bibliotheken.
• Unsichtbare Sonderzeichen aus der Copy-Paste-Hölle (syntax error near unexpected token 'then').
• Eine Rebellion des Redis-Caches, der sich weigerte, mit PHP zu sprechen, obwohl sie im selben Raum standen und das Namensschild des anderen kannten.

Jedes Mal, wenn ich ein Problem löse, offenbarte sich dahinter ein neues, wie eine russische Matrjoschka-Puppe des Scheiterns. Der Wechsel von Ubuntu auf ein frisches Debian 12 brachte neue Herausforderungen: "Paket php8.3 kann nicht gefunden werden." Natürlich nicht, Debian spricht standardmäßig php8.2! Also baute ich dem Skript eine Debian-Erkennung mit dem SURY PPA ein. Das Skript wurde zu einem Meisterwerk der Fehlerbehandlung. Es war intelligent. Es war robust. Es war... immer noch kaputt.

Der www-data-Benutzer, der treue Diener des Webservers, weigerte sich standhaft, mit Redis zu kommunizieren. Als root? Kein Problem. Als www-data? "Memcache not available." Ich versuchte echt alles: TCP-Ports, IP-Adressen, Unix-Sockets, ich fügte Benutzer zu Gruppen hinzu, startete Dienste neu, haben AppArmor in den "Mecker-Modus" versetzt. Nichts. Die Verzweiflung war real.

Akt II: Die Docker-Erlösung

An diesem Punkt warf ich das Handtuch. Das Skript landete im digitalen Schredder und wurde mit vielen Nullen und Einsen terminiert. Es musste einen besseren Weg geben. Und den gab es: Nextcloud AIO (All-in-One).

Anstatt zu versuchen, ein Dutzend zankender Systemkomponenten zur Zusammenarbeit zu zwingen, versprach AIO eine Oase der Ruhe: eine vorgefertigte, perfekt abgestimmte Umgebung, die in isolierten Docker-Containern läuft. Kein Streit mehr über PHP-Versionen, keine Berechtigungsprobleme mehr.

Die Installation war eine Offenbarung. Ein einziger Docker– Befehl.

sudo docker run \
--init \
--sig-proxy=false \
--name nextcloud-aio-mastercontainer \
--restart always \
--publish 8080:8080 \
--env APACHE_PORT=11000 \
--env APACHE_IP_BINDING=0.0.0.0 \
--env APACHE_ADDITIONAL_NETWORK="" \
--env SKIP_DOMAIN_VALIDATION=false \
--volume nextcloud_aio_mastercontainer:/mnt/docker-aio-config \
--volume /var/run/docker.sock:/var/run/docker.sock:ro \
ghcr.io/nextcloud-releases/all-in-one:latest

Ich habe das Ganze noch mit einem Reverse Proxy garniert. Die AIO-Verwaltungsoberfläche auf Port 8080 wurde über eine passwortgeschützte Subdomain (aiosetup.domain.tld) sicher gemacht, während der eigentliche Nextcloud-Traffic auf Port 11000 an die frei zugängliche cloud.domain.tld weitergeleitet wird. Elegant. Sicher. Es funktionierte. Ich war im Himmel.

Akt III: Der finale Endgegner - Illegal instruction

Der Himmel war nur von kurzer Dauer. Ich aktivierte in der AIO-Oberfläche aus den Community Containers den "Computing container for facerecognition" und... nichts. Ein Blick in die Docker-Logs enthüllte den neuen Erzfeind: Could not resolve host: nextcloud-aio-facerecognition. Ein weiterer Blick mit docker ps -a zeigte die Wahrheit: Der Recognize-Container war in einer Endlosschleife aus Abstürzen gefangen.

Die Logs des Containers spuckten immer wieder nur eine, kryptische Meldung aus:

Illegal instruction (core dumped)

Das war der Moment der Erleuchtung. Stellen Sie sich vor, der Container spricht einen "hochmodernen" CPU-Dialekt (AVX-Instruktionen), aber die CPU meiner Proxmox-VM versteht nur "Standard-Hochdeutsch". Jedes Mal, wenn der Container einen modernen Befehl gab, verstand die CPU nur Bahnhof, sagte "Ungültiger Befehl!" und warf den Container raus.

Die Ursache war die Standardeinstellung in Proxmox, die einer VM aus Kompatibilitätsgründen nur eine generische kvm64-CPU gibt.

Die Lösung war ein einziger Klick, tief in den Hardware-Einstellungen der VM: den CPU-Typ von kvm64 auf host ändern. Damit reicht Proxmox die vollen Fähigkeiten der physischen CPU an die VM durch.

VM neu gestartet. Der Recognize-Container startete. Blieb online. Die Fehlermeldung verschwand.

Fazit

Jetzt läuft sie. Stabil, schnell und voller automatisch erkannter Gesichter von Menschen. Die Reise war lang, die Nächte kurz. Was habe ich gelernt?

1. Ein Bash-Skript ist nicht immer die Antwort. Manchmal ist die vorgefertigte "Komplettlösung" der schnellere und nervenschonendere Weg.
2. Virtualisierung ist Magie, aber der Teufel steckt im Detail. Eine simple CPU-Einstellung kann den Unterschied zwischen Erfolg und einer Endlosschleife aus Abstürzen ausmachen.
3. Gib niemals auf. Und schau immer in die verdammten Logs.

Und ich? Ich brauche jetzt erst mal einen Kaffee. Einen sehr, sehr großen Kaffee.