Einrichten des Dienstkontos scheitert · Linux Fix Lab

Symptome und Geltungsbereich

Der Dienst meldet 217/USER oder 216/GROUP.
Ein konfiguriertes statisches Konto wird beim Start nicht aufgelöst.

Betroffene Umgebung

systemd-Dienste mit User, Group, SupplementaryGroups, DynamicUser oder PrivateUsers.

Erkennbare Meldungen (synthetische Beispiele)

systemd[1]: example.service: Main process exited, code=exited, status=217/USER

Prüfe die vorherige Meldung vor der Annahme eines fehlenden Kontos.

systemd[1]: example.service: Main process exited, code=exited, status=216/GROUP

Prüfe Haupt- und Zusatzgruppen.

Mögliche Ursachen

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

Ein statisches Konto oder eine Zusatzgruppe kann fehlen oder von nicht verfügbarer NSS-Infrastruktur abhängen.
217/USER umfasst auch Identitätswechsel und User-Namespaces; der Status beweist keinen fehlenden Benutzernamen.

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; diese Einstellungen benötigen normalerweise keine erhöhten Leserechte.

systemctl show example.service -p User -p Group -p SupplementaryGroups -p DynamicUser -p PrivateUsers

Ergebnis einordnen: DynamicUser vergibt Identitäten anders. PrivateUsers ergänzt einen Namespace-Schritt, den statische Kontenabfragen nicht prüfen.

Prüfschritt 2

Ersetze example durch den statischen User-Wert; ein inaktiver DynamicUser muss nicht dauerhaft existieren.

getent passwd example

Ergebnis einordnen: Keine Ausgabe bedeutet fehlende Auflösung im Host-NSS. Ein Treffer beweist keinen erfolgreichen Identitätswechsel oder Namespace-Aufbau.

Prüfschritt 3

Ersetze example durch den jeweils betroffenen statischen Wert aus Group oder SupplementaryGroups.

getent group example

Ergebnis einordnen: Eine fehlende Zusatzgruppe kann den Start verhindern, obwohl User aufgelöst wird. Vergleiche die Namen genau mit der Unit.

Nächste Schritte nach Befund

Das vorgesehene statische Konto bereitstellen

Wenn NSS ein fehlendes lokales Konto bestätigt, deklariere Konto und Gruppen über Benutzerkonfiguration oder sysusers vor dem Dienststart. Passe Dateneigentümer an die dokumentierte Identität an.

Vorsicht: Verwende nicht ersatzweise root oder die UID einer anderen Anwendung. Kontoänderungen können bestehende Dateneigentümer betreffen.

Wiederherstellung / Rücknahme: Stelle Konto und Unit zurück. Entferne eine ergänzte Identität erst nach Dateiprüfung und mit weiterhin passenden Eigentümern.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Bestätigten Namespace- oder NSS-Fehler beheben

Wenn das Journal eine User-Namespace-Einschränkung nennt, passe genau diese Funktion an Container oder Benutzer-Manager an. Ist entferntes NSS nicht verfügbar, behebe es statt eines doppelten lokalen Kontos.

Vorsicht: Prüfe die Schutzwirkung von PrivateUsers-Änderungen und vermeide UID-Kollisionen mit Verzeichnisdienst-Konten.

Wiederherstellung / Rücknahme: Stelle Namespace- oder NSS-Einstellungen wieder her und starte bei wieder verfügbarer Kontenauflösung.