How to Fix systemctl --user Failed to connect to bus: No medium found

On a Linux server, you switch over with sudo -iu project-user, run systemctl --user daemon-reload, and get Failed to connect to bus: No medium found. I ran into this systemctl –user No medium found error in October 2026 while turning Claude Code Remote Control into an always-on service.

The short version: this is usually not a broken systemd or a bad unit file. The shell that sudo -iu opens has no user bus for that user. The fix is to go back to an admin account with sudo rights, turn on linger, confirm the user manager is running, and then run systemctl --user through sudo -u with XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS set explicitly. Do not use sudo systemctl --user.

This post is my record of a deployment on an Oracle Cloud Ubuntu 24.04 (ARM64) server in October 2026. The commands use Ubuntu 24.04, and usernames are replaced with examples such as project-a. Other distributions or systemd versions may behave differently; the official documentation is what counts.

What the error looks like and when it appears

What I did was simple: SSH into the server with the admin account (Ubuntu’s default ubuntu), switch to the project user, and manage that user’s own systemd user service from there.

sudo -iu project-a
systemctl --user daemon-reload
# Failed to connect to bus: No medium found

This project user has no password and never logs in directly; I only reach it through sudo -iu. The full always-on Remote Control setup is in Running Claude Code Remote Control on a Free Oracle Cloud Server. This post deals only with this error.

Why systemctl –user says No medium found

systemctl --user needs to reach “this user’s own systemd user manager”, and it connects through the user D-Bus. During a normal SSH login, the login process prepares the runtime directory /run/user/<UID>/ for you and sets environment variables such as XDG_RUNTIME_DIR.

The shell that sudo -iu opens is not a full login session. Those variables may be missing, and the user bus may not exist yet. When systemctl cannot find a bus to connect to, it fails with No medium found.

You can confirm this in that shell first:

echo "$XDG_RUNTIME_DIR"
echo "$DBUS_SESSION_BUS_ADDRESS"
ls -l "/run/user/$(id -u)/bus"

If the first two lines are empty, or the bus file does not exist, this is your situation.

The fix: point to the user bus from the admin account

Run all of the following from the admin account with sudo rights, not inside the sudo -iu shell.

Turn on linger first and confirm the user manager is running

PROJECT_USER=project-a
uid=$(id -u "$PROJECT_USER")

sudo loginctl enable-linger "$PROJECT_USER"
loginctl show-user "$PROJECT_USER" -p Linger   # expected: Linger=yes

# If /run/user/$uid/bus does not exist, check the user manager's status first
systemctl status "user@${uid}.service" --no-pager

Linger starts this user’s user manager at boot and keeps it after logout (loginctl documentation, checked on 12 October 2026). If you want the service to keep running after SSH disconnects and come back after a reboot, you need this step anyway.

Run it with XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS

sudo -u "$PROJECT_USER" \
  XDG_RUNTIME_DIR="/run/user/$uid" \
  DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$uid/bus" \
  systemctl --user daemon-reload

Typing all that every time invites mistakes, so you can wrap it in a function in the admin shell:

uctl() {
  sudo -u "$PROJECT_USER" \
    XDG_RUNTIME_DIR="/run/user/$uid" \
    DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$uid/bus" \
    systemctl --user "$@"
}

uctl daemon-reload
uctl enable --now claude-project-a.service
uctl status claude-project-a.service --no-pager -l

Reading the logs works the same way:

sudo -u "$PROJECT_USER" \
  XDG_RUNTIME_DIR="/run/user/$uid" \
  DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$uid/bus" \
  journalctl --user -u claude-project-a.service -n 80 --no-pager

Why sudo systemctl –user doesn’t work

sudo systemctl --user ... looks like “managing a user service with sudo rights”, but by default sudo may switch to root, so you are talking to root’s user manager, not project-a’s. You may reload the wrong target, fail to find the service, or see an unrelated status.

To manage a user’s user service, run as that user (sudo -u project-a) and point to that user’s bus.

enabled, active (running) and inactive (dead): what’s the difference

Once the bus is connected, the next common mistake is assuming enabled means the service is running. That happened to me: one Remote Control service showed Loaded: ... enabled but Active: inactive (dead) (Result: exit-code), while another service at the same time was active (running), and I had already confirmed Linger=yes.

Check whether it is enabled and what state it is in:

uctl is-enabled claude-project-a.service
uctl status claude-project-a.service --no-pager -l
uctl --failed --no-pager

Only start it directly when you are sure the service was stopped on purpose and there is no unresolved startup error. If you see status=1/FAILURE, read the journal first. For the exit code 1 I saw that time, I don’t have enough logs to confirm the root cause, so I am not presenting it here as “found the cause”. For the troubleshooting order when a service keeps failing to start, see Running Multiple Claude Code Remote Controls on One Server.

An incomplete unit file: check it with systemd-analyze

Another case I actually hit: I wrote a unit file with a shell heredoc (cat > file <<'EOF' ... EOF), the end marker was not closed properly, and the file was missing its final [Install] section. The result can be a failing systemctl enable, or a service you think is set up while the file is actually incomplete.

After writing a unit, check it before you reload:

tail -n 12 ~/.config/systemd/user/claude-project-a.service
systemd-analyze --user verify ~/.config/systemd/user/claude-project-a.service

A complete user service should end with:

[Install]
WantedBy=default.target

Without an [Install] section, enable does not know which target to attach the service to. If systemd-analyze --user also cannot run because of the user bus, have the admin check the file contents and then daemon-reload the way shown above. When fixing files, touch only the one with the problem; don’t overwrite other services that are working fine while you’re at it.

How to verify the fix

1. loginctl show-user project-a -p Linger returns Linger=yes.
2. uctl is-enabled returns enabled, and uctl status shows active (running).
3. The logs show the process starting normally (for Claude Code Remote Control, Connected and the environment name).
4. Close SSH completely, reconnect, and the service is still running.
5. Pick a time when nothing important is running, reboot, and confirm the service comes back on its own.

active (running) only proves the process exists. Whether Remote Control is actually connected is something you check in the logs and in the environment list on your phone or the web. The full always-on setup is in Running Claude Code Remote Control on a Free Oracle Cloud Server; for the tools behind the whole site, see Jason Finance from Zero to One.

FAQ

Why does systemctl --user say No medium found?

It usually happens when you run it after switching to another user with sudo -iu. That shell is not a full login, so XDG_RUNTIME_DIR and the user D-Bus address may not be set, and systemctl cannot find that user's user manager. It does not mean systemd is broken or that the unit file is wrong.

How do I fix systemctl --user No medium found?

Go back to an admin account with sudo rights. Turn on linger for the user with loginctl enable-linger, confirm that user@UID.service is running, then run systemctl --user through sudo -u with XDG_RUNTIME_DIR=/run/user/UID and DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/UID/bus.

Can I just use sudo systemctl --user?

Not recommended. By default sudo may switch to root, so you would be talking to root's user manager rather than the project user's, and you end up changing the wrong thing or reading the wrong status.

The service shows enabled. Why isn't it running?

enabled only means systemd will try to start it when its start conditions are met; active (running) is what tells you the process exists right now. A service that was stopped by hand or failed to start can still be enabled while its state is inactive (dead).

What does activating (auto-restart) mean?

systemd is restarting the service according to its Restart setting, which usually means it keeps failing to start. Read the journalctl logs first instead of restarting it by hand over and over.

How do I check that a unit file is complete?

Look at the end of the file with tail, then check it with systemd-analyze --user verify. If the [Install] section is missing, systemctl enable may fail, or you may think the service is set up when the file is actually incomplete.