Orbiter — Bekannte Fehler & Lösungen

Installationsfehler

Fehler: „Run via SSH: php /opt/psa/admin/plib/modules/orbiter/scripts/post-install.php" Das Post-Install-Skript konnte nicht automatisch ausgeführt werden. Verbinden Sie sich per SSH als root und führen Sie den Befehl manuell aus:

php /opt/psa/admin/plib/modules/orbiter/scripts/post-install.php

Fehler: „install-deps failed" Die Installation der Systemabhängigkeiten ist fehlgeschlagen. Führen Sie als root aus:

bash /opt/psa/admin/plib/modules/orbiter/scripts/install-all.sh

Prüfen Sie, ob der Server über Internetzugang verfügt und ob der Paketmanager (apt/yum) normal funktioniert.

Fehler: „Dockerfile not found" Die Docker-Build-Dateien wurden während der Installation nicht korrekt kopiert. Führen Sie das Post-Install erneut aus oder installieren Sie die Erweiterung über den Plesk-Erweiterungsmanager neu.

Fehler: „Default nginx template not found" Das Nginx-Proxy-Template fehlt. Führen Sie erneut aus:

php /opt/psa/admin/plib/modules/orbiter/scripts/post-install.php

Fehler beim Erstellen des Docker-Images

Build failed / „Build failed" in der Oberfläche Prüfen Sie die Build-Logs, die unterhalb des Fortschrittsbalkens angezeigt werden. Häufige Ursachen:

• Kein Internetzugang zum Herunterladen der Basis-Images
• Unzureichender Festplattenspeicher (mindestens 20 GB empfohlen)
• Docker-Daemon läuft nicht: systemctl start docker

„docker run failed" / Container startet nicht Prüfen Sie, ob:

1. Docker läuft: systemctl status docker
2. Ausreichend RAM verfügbar ist (mindestens 2 GB insgesamt)
3. Keine Port-Konflikte bestehen: Prüfen Sie die Logs auf port already in use

„Web volume mount failed. Check that the path exists" Der Document-Root-Pfad der Domain existiert nicht oder ist nicht erreichbar. Überprüfen Sie in Plesk, dass der Dateipfad der Domain korrekt ist und das Verzeichnis auf dem Datenträger vorhanden ist.

Fehler beim Erstellen von Containern

„Error creating" / Container bleibt im Status „creating" hängen Ein vorheriger Erstellungsvorgang hat möglicherweise eine Lock-Datei hinterlassen. Prüfen Sie:

ls /opt/psa/var/modules/orbiter/locks/

Falls eine .lock-Datei für die Domain existiert und kein Vorgang läuft, löschen Sie sie:

rm /opt/psa/var/modules/orbiter/locks/<domain>.lock

„Container is delete-locked. Unlock it first, or use force=1" Für den Container ist die Löschsperre aktiviert. Wechseln Sie im Aktionspanel zum Abschnitt „Container", schalten Sie die Sperre auf „Entsperrt" und versuchen Sie den Vorgang erneut.

„Failed to apply network limit" Das Netzwerklimit von Docker konnte nicht angewendet werden. Dies ist in der Regel unkritisch — der Container läuft, jedoch ohne Begrenzung der Netzwerkgeschwindigkeit. Prüfen Sie die Kompatibilität der Docker-Version.

„Quota exceeded" Der Plesk-Kunde hat sein vom Administrator festgelegtes Kontingent an Containern, RAM oder Datenbanken erreicht. Wenden Sie sich an den Serveradministrator, um das Kontingent zu erhöhen, oder löschen Sie zunächst einen bestehenden Container.

„Failed to enable nginx PHP mode" Nginx konnte nicht so konfiguriert werden, dass PHP-Anfragen an den Container weitergeleitet werden. Führen Sie aus:

plesk repair web -y

MariaDB-Fehler

„MariaDB is starting, please wait a few seconds..." MariaDB wird innerhalb des Containers noch initialisiert. Warten Sie 10–15 Sekunden und aktualisieren Sie die Seite. Hält dies länger als 60 Sekunden an, starten Sie den Container neu.

„Dump failed. Check that MariaDB is running" MariaDB läuft innerhalb des Containers nicht. Wechseln Sie zum Datenbank-Panel und klicken Sie auf „MariaDB starten" oder starten Sie den gesamten Container neu. Tritt der Fehler wiederkehrend im nächtlichen Backup-Log auf (/opt/psa/var/modules/orbiter/logs/orbiter.log mit [Cron] FAIL ALL: Dump failed), hängt der MariaDB-Dienst im Container wahrscheinlich im Status FATAL. Prüfen Sie dies mit:

docker exec php-fpm-<domain> supervisorctl status mariadb

Meldet er FATAL Exited too quickly, siehe MariaDB FATAL-Status (Can't initialize timers) weiter unten.

MariaDB FATAL-Status (Can't initialize timers) — PidsLimit zu niedrig MariaDB benötigt für den Start mehrere interne Threads (Timer, Signal-Handler, InnoDB-Worker). Liegt der pids.max-Wert der cgroup des Containers unterhalb der Anforderung von MariaDB, bricht mariadbd beim Start sofort ab mit:

Can't initialize timers
[ERROR] Aborting

Supervisord versucht es 3-mal erneut und markiert den Dienst dann als FATAL. Der Container bleibt aktiv — nur die darin enthaltene MariaDB ist tot — und die nächtlichen Backups schlagen jede Nacht still fehl.

So erkennen Sie es. Inspizieren Sie die Container-Limits:

docker inspect php-fpm-<domain> --format '{{.HostConfig.PidsLimit}}'

Gibt dies 100 oder weniger zurück und ist im Container MariaDB aktiviert, haben Sie die Ursache gefunden.

So beheben Sie es. Erhöhen Sie das cgroup-Limit im laufenden Betrieb (kein Recreate nötig) und starten Sie den Dienst neu:

docker update --pids-limit=512 php-fpm-<domain>
docker exec php-fpm-<domain> supervisorctl restart mariadb

Überprüfen Sie anschließend: docker exec php-fpm-<domain> supervisorctl status mariadb sollte nun RUNNING anzeigen. Das nächtliche Backup wird von selbst wieder aufgenommen.

Vorbeugung. Orbiter wendet ein MariaDB-Minimum von 150 PIDs an, wenn die Engine beim Erstellen des Containers aktiviert wird, doch ein Container, der vor dieser Schutzmaßnahme erstellt wurde (oder einer, bei dem das Limit manuell über das Limits-Modal gesenkt wurde), kann unter den Schwellenwert geraten. Überprüfen Sie nach einer Aktivierung per + MariaDB, dass das PIDs-Limit des Containers kein Überbleibsel einer Conservative-Voreinstellung ist. In der Oberfläche graut das Limits-Modal nun PIDs-Werte unter 150 aus, wenn auf derselben Website MariaDB aktiv ist.

MariaDB stürzt unmittelbar nach dem Container-Start ab (io_uring-Fehler) Dies betrifft Hosts, bei denen io_uring_disabled=2 gilt oder libaio nicht verfügbar ist. Die Korrektur wird seit Orbiter 1.5.4 automatisch angewendet. Wenn Sie eine ältere Version verwenden, führen Sie aus:

php /opt/psa/admin/plib/modules/orbiter/scripts/post-install.php

Dies trägt die Konfiguration innodb_use_native_aio=0 nachträglich in alle laufenden MariaDB-Container ein.

„MySQL error" beim Anlegen eines Benutzers / Erteilen von Berechtigungen Möglicherweise hat sich das MariaDB-Root-Passwort geändert, oder der Container benötigt einen Neustart. Starten Sie MariaDB über das Datenbank-Panel neu und versuchen Sie den Vorgang erneut.

phpMyAdmin „Failed to set session cookie" Dies tritt nach einer phpMyAdmin-Slug-Migration auf, bei der der nginx-vhost und die config.inc.php im Container nicht synchron sind. Behoben in Orbiter 1.5.3. Aktualisieren Sie auf die neueste Version oder erstellen Sie den Container neu.

Datenbankimport schlägt mit Syntaxfehler fehl Die importierte SQL-Datei enthält möglicherweise Anweisungen auf Systemebene, die herausgefiltert wurden. Orbiter entfernt gefährliche Anweisungen automatisch. Schlägt der Import vollständig fehl, prüfen Sie, ob die Datei gültiges SQL ist (keine einzeilige Textdatei) und nicht beschädigt ist.

Nginx-/Webserver-Fehler

„Failed to write proxy configuration" Orbiter konnte die Nginx-Proxy-Konfiguration für die Domain nicht schreiben. Prüfen Sie den Festplattenspeicher und die Berechtigungen unter /etc/nginx/. Führen Sie plesk repair web -y aus, um die Nginx-Konfiguration zurückzusetzen.

Website liefert nach der Container-Erstellung 502 Bad Gateway Der Container befindet sich möglicherweise noch im Startvorgang. Warten Sie 10–15 Sekunden und aktualisieren Sie die Seite. Falls das Problem fortbesteht:

1. Prüfen Sie in Orbiter, ob der Container läuft
2. Prüfen Sie die Container-Logs auf PHP-FPM-Startfehler
3. Versuchen Sie, den Container neu zu starten

Website liefert bei PHP-Dateien 403 Forbidden, wenn Shield aktiviert ist Dies ist das korrekte Verhalten von Shield. Shield blockiert die Ausführung von PHP-Dateien in schreibgeschützten Verzeichnissen. Wird eine legitime PHP-Datei blockiert, gehen Sie wie folgt vor:

• Fügen Sie das übergeordnete Verzeichnis der Liste der beschreibbaren Verzeichnisse in den Shield-Einstellungen hinzu
• Oder deaktivieren Sie Shield vorübergehend zum Testen

„Container is not starting correctly. Logs:" gefolgt von Fehlerausgabe Lesen Sie die in der Fehlermeldung angezeigten Logs. Häufige Ursachen:

• PHP-FPM-Konfigurationsfehler (prüfen Sie die benutzerdefinierte php.ini auf Syntaxfehler)
• Port-Konflikt (ein anderer Prozess verwendet den zugewiesenen Port)
• Unzureichender Arbeitsspeicher

Cache-Fehler

Cache-Bereinigung gibt „Permission denied" zurück Nginx erstellt Cache-Unterverzeichnisse im Modus 700. Orbiter setzt seit Version 1.5.0 automatisch chmod -R 777 auf die Cache-Unterverzeichnisse. Sehen Sie diesen Fehler in einer älteren Version, aktualisieren Sie Orbiter oder führen Sie aus:

chmod -R 777 /var/cache/orbiter/<domain>/

„Error during flush" Der Nginx-Cache konnte nicht geleert werden. Prüfen Sie, ob das Cache-Verzeichnis existiert und erreichbar ist. Versuchen Sie, den Cache über das Cache-Panel in der Orbiter-Oberfläche zu leeren.

CLI-Fehler

--version meldet die falsche Version Behoben in Orbiter 1.5.2. Aktualisieren Sie auf die neueste Version. Die CLI liest meta.xml nun dynamisch aus.

--db-export > dump.sql erzeugt eine einzeilige Textdatei Behoben in Orbiter 1.5.2. Der SQL-Dump wird nun an stdout und die Statusmeldung an stderr ausgegeben. Aktualisieren Sie auf die neueste Version.

WARNING: Error loading config file: open /root/.docker/config.json: permission denied Diese Warnung erschien in Versionen vor 1.5.2 bei jedem Docker-Befehl. Sie ist rein kosmetischer Natur und beeinträchtigt die Funktionalität nicht. Behoben in Orbiter 1.5.2 durch Setzen von DOCKER_CONFIG=/nonexistent.

Sync-/Backup-Fehler

„Sync failed" / „Connection failed" Für externe Backup-Ziele (S3, SFTP, FTPS):

1. Überprüfen Sie die Zugangsdaten in der Konfiguration des Backup-Ziels
2. Verwenden Sie die Schaltfläche „Verbindung testen" zur Diagnose
3. Prüfen Sie, ob der Server den entfernten Host erreichen kann (Firewall, DNS)

„Cannot read inventory file" Die Konfigurationsdatei des Sync-Ziels fehlt oder ist beschädigt. Löschen Sie das Ziel und fügen Sie es über das Panel Einstellungen → Backups erneut hinzu.

Nächtliches Backup meldet wiederholt FAIL ALL: Dump failed für eine Domain Der MariaDB-Dienst innerhalb dieses Containers hängt im Status FATAL. Siehe MariaDB FATAL-Status (Can't initialize timers) im Abschnitt MariaDB-Fehler oben für Diagnose und Behebung.

Allgemeine Fehler

„sysop returned invalid JSON" Ein interner Kommunikationsfehler zwischen dem Orbiter-PHP-Code und dem privilegierten sysop-Binary. In der Regel vorübergehend. Versuchen Sie den Vorgang erneut. Bei Fortbestehen prüfen Sie /var/lib/orbiter/orbiter.log auf Details.

„ConfigStore init failed, falling back to JSON" Die SQLite-Konfigurationsdatenbank konnte nicht geöffnet werden. Orbiter weicht automatisch auf den JSON-Speicher aus, sodass die Funktionalität erhalten bleibt. Prüfen Sie den Festplattenspeicher unter /var/lib/orbiter/.

„Unknown error" bei einem beliebigen Vorgang Prüfen Sie die Orbiter-Log-Datei auf Details:

tail -100 /var/lib/orbiter/orbiter.log

Prüfen Sie zudem das Plesk-Fehlerprotokoll:

tail -100 /var/log/plesk/panel.log