Desktop, X11 & Wayland

The session runtime directory is missing or invalid

Wayland and desktop IPC depend on a private runtime directory. Check ownership, mode and login lifetime before changing session variables.

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

  • Apps warn about XDG_RUNTIME_DIR after su, sudo or a custom login.
  • A compositor cannot create or connect to its session socket.

Relevant environment

Desktop sessions using XDG_RUNTIME_DIR; systemd/logind commands apply only to distributions using that session integration.

Recognizable messages (synthetic examples)
error: XDG_RUNTIME_DIR is invalid or not set in the environment.

Inspect the login context and ownership; setting a directory string alone does not create a valid session.

Possible causes

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

  • The process may belong to another user than the original login session.
  • A hard-coded runtime path may have the wrong owner, mode or lifetime.

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

Read these values in the failing process’s launch context, not only in another working terminal.

printenv XDG_RUNTIME_DIR XDG_SESSION_ID XDG_SESSION_TYPE

Interpret the result: An unset directory or one belonging to another account supports a session-setup problem; a session ID can be absent in non-logind environments.

Check 2

Run only after checking the variable; reads the existing directory and follows its target without changing it.

stat -Lc "%U %u %a %F %n" "$XDG_RUNTIME_DIR"

Interpret the result: The directory must be local, owned by this user and mode 0700. Metadata alone cannot establish that its creation and removal follow session lifetime.

Evidence-guided next steps

Start from the intended user’s real login session

If the app is launched via another user or an incomplete login wrapper, save work and start it from the intended account’s normal display-manager or PAM-backed login. On logind systems this allows the supported login stack to create the private runtime directory.

Precautions: Do not reuse another user’s /run/user directory or chmod it 0777. Do not run the compositor as root.

Recovery / rollback: Close the temporary session. If a login wrapper was changed, restore its backup through a working console.

Did this solution help you?

Share this solution#

Remove a stale runtime-directory export

If shell or launcher files force an obsolete runtime path, back up the file and remove only that assignment. Log out fully and log back in so the normal session environment is rebuilt; verify the actual directory rather than creating a replacement in /tmp.

Precautions: Deleting a live runtime directory interrupts sockets and user services. Leave its lifetime to the supported session manager.

Recovery / rollback: Restore the saved assignment only if it belongs to a verified custom session setup; otherwise restore the supported login configuration.

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.