Dennis HilkLinux Fix LabDE

Services & systemd

Service sandbox setup fails with NAMESPACE

A unit fails with 226/NAMESPACE before execution. Inspect sandbox paths, root images and host capabilities to identify the specific isolation failure.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • Startup reports status=226/NAMESPACE.
  • The journal names a failed namespace mount or source path.

Relevant environment

systemd filesystem sandbox directives, root images and mount namespaces in system or user managers.

Recognizable messages (synthetic examples)
systemd[1]: example.service: Main process exited, code=exited, status=226/NAMESPACE

Inspect setup paths and host support before application settings.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • A mandatory ReadWritePaths, BindPaths or image source may be absent.
  • A container or user manager may lack the namespace capabilities requested by the unit.

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; the query creates no namespace.

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

Interpret the result: Compare source paths with their host or service-root context. Distinguish required paths from genuinely optional paths.

Check 2

Read the affected journal with authorized read access if restricted.

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

Interpret the result: The preceding error can name a missing file, unsupported operation or denied namespace setup. 226 alone does not distinguish them.

Evidence-guided next steps

Repair the named sandbox source

If the error identifies a missing required path, provision it or correct its binding. Use the documented optional-path prefix only if the application truly tolerates that resource being absent.

Precautions: An optional prefix can hide missing state or secrets and grants no extra access. Review the effective unit after editing.

Recovery / rollback: Restore the original path declaration and deployment layout, reload the unit and restart when its source exists.

Did this solution help you?

Share this solution#

Align isolation with host capabilities

If logs prove the host cannot create the requested namespace, use a supported environment or narrowly adapt that particular sandbox feature after reviewing its security purpose. Retain unrelated isolation directives.

Precautions: Do not grant blanket container privileges for one unit failure. Check directive availability in the installed systemd manual.

Recovery / rollback: Restore the isolation directive or runtime environment and compare the same startup inspection.

Did this solution help you?

Share this solution#

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.