Dennis HilkLinux Fix LabEN

Dienste und systemd

Dienst-Sandbox scheitert mit NAMESPACE

Eine Unit scheitert vor dem Start mit 226/NAMESPACE. Prüfe Sandbox-Pfade, Root-Images und Host-Fähigkeiten für den konkreten Isolationsfehler.

Redaktionelle Quellenprüfung: Mit den Hinweisen beginnenAnleitung teilen
Auf dieser Seite
  1. Symptome und Geltungsbereich
  2. Mögliche Ursachen
  3. Sicher prüfen
  4. Nächste Schritte nach Befund
  5. Quellen und Prüfung
  6. Verwandte Probleme

Symptome und Geltungsbereich

  • Der Start meldet status=226/NAMESPACE.
  • Das Journal nennt einen fehlgeschlagenen Namespace-Mount oder Quellpfad.

Betroffene Umgebung

systemd-Dateisystem-Sandbox, Root-Images und Mount-Namespaces in System- oder Benutzer-Managern.

Erkennbare Meldungen (synthetische Beispiele)
systemd[1]: example.service: Main process exited, code=exited, status=226/NAMESPACE

Prüfe Aufbaupfade und Host-Unterstützung vor Anwendungseinstellungen.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

  • Ein erforderlicher Pfad aus ReadWritePaths, BindPaths oder einer Image-Quelle kann fehlen.
  • Ein Container oder Benutzer-Manager kann die angeforderten Namespace-Fähigkeiten nicht besitzen.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Ersetze example.service; die Abfrage erstellt keinen Namespace.

systemctl show example.service -p RootDirectory -p RootImage -p ReadWritePaths -p BindPaths -p ProtectSystem -p PrivateTmp

Ergebnis einordnen: Vergleiche Quellpfade mit Host- oder Dienst-Root-Kontext. Unterscheide erforderliche von tatsächlich optionalen Pfaden.

Prüfschritt 2

Lies das betroffene Journal mit berechtigten Leserechten, falls eingeschränkt.

journalctl -b -u example.service --no-pager -n 80

Ergebnis einordnen: Die vorherige Meldung kann fehlende Datei, nicht unterstützte Operation oder verweigerten Aufbau nennen. 226 allein unterscheidet sie nicht.

Nächste Schritte nach Befund

Die genannte Sandbox-Quelle korrigieren

Wenn ein erforderlicher Pfad fehlt, stelle ihn bereit oder korrigiere seine Bindung. Nutze den dokumentierten Präfix für optionale Pfade nur, wenn die Anwendung ohne die Ressource auskommt.

Vorsicht: Ein optionaler Präfix kann fehlende Daten oder Geheimnisse verdecken und erteilt keine zusätzlichen Rechte. Prüfe die wirksame Unit nach der Änderung.

Wiederherstellung / Rücknahme: Stelle Pfadvorgabe und Deployment-Struktur zurück, lade die Unit neu und starte bei vorhandener Quelle.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Isolation an Host-Fähigkeiten anpassen

Wenn Logs fehlende Host-Fähigkeiten belegen, nutze eine unterstützte Umgebung oder passe nach Prüfung ihrer Schutzwirkung genau diese Sandbox-Funktion an. Behalte unbeteiligte Schutzvorgaben bei.

Vorsicht: Erteile keine pauschalen Container-Privilegien für einen Unit-Fehler. Prüfe Vorgaben im Handbuch der installierten systemd-Version.

Wiederherstellung / Rücknahme: Stelle Isolationsvorgabe oder Laufzeitumgebung wieder her und vergleiche denselben Dienststart.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Quellen und Prüfung

Diese Anleitung basiert auf Originalquellen von Projekten oder Distributionen und wurde am genannten Datum redaktionell geprüft. Das ist eine Quellenprüfung, kein Nachweis einer auf deiner Hardware reproduzierten Lösung. Log-Beispiele sind synthetische Testdaten. Versionsabhängige Details müssen zur installierten Ausgabe passen.