Symptoms & scope
- The service reports 217/USER or 216/GROUP.
- A configured static account is unresolved at startup.
Relevant environment
systemd services using User, Group, SupplementaryGroups, DynamicUser or PrivateUsers.
Recognizable messages (synthetic examples)
systemd[1]: example.service: Main process exited, code=exited, status=217/USERRead the preceding error before deciding that an account is absent.
systemd[1]: example.service: Main process exited, code=exited, status=216/GROUPInspect both primary and supplementary groups.
Possible causes
These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.
- A static account or supplementary group may be missing or depend on unavailable NSS infrastructure.
- 217/USER also covers credential changes and user namespace setup; it does not prove a username is absent.
Diagnose safely
Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.
Check 1
Replace example.service; these settings normally need no elevated read access.
systemctl show example.service -p User -p Group -p SupplementaryGroups -p DynamicUser -p PrivateUsersInterpret the result: DynamicUser allocates identities differently. PrivateUsers adds namespace setup not covered by static-account lookup.
Check 2
Replace example with the static User value; do not expect an inactive DynamicUser to exist permanently.
getent passwd exampleInterpret the result: No result means unresolved in the host NSS context. A result does not prove credential switching or namespace creation succeeds.
Check 3
Replace example with each affected static Group or SupplementaryGroups value.
getent group exampleInterpret the result: A missing supplementary group can fail setup even if User resolves. Compare the exact names with the unit.
Evidence-guided next steps
Provision the intended static account
If NSS confirms a missing local identity, declare the account and groups with the distribution user configuration or sysusers before service startup. Match data ownership to the documented service identity.
Precautions: Do not substitute root or another application's UID. Account changes can affect ownership of existing data.
Recovery / rollback: Restore prior account and unit definitions. Remove an added identity only after checking its files and keeping ownership consistent.
Did this solution help you?
Correct the proven namespace or NSS issue
If the detailed journal identifies a user namespace restriction, adapt that specific feature to the container or user-manager capabilities. If remote NSS is unavailable, repair it instead of inventing a duplicate local identity.
Precautions: Review the security effect of PrivateUsers changes and avoid UID collisions with directory-backed accounts.
Recovery / rollback: Restore the namespace or NSS settings and restart after account resolution is available again.
Did this solution help you?
References & review
This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.
- systemd.exec — upstream manual hosted by Debian (project or distribution documentation)
- systemd.unit — upstream manual hosted by Debian (project or distribution documentation)