/run/user/uid missing when using `incus exec container -- sudo --user uname --login`

Baba_Open · June 30, 2025, 6:40pm

Hello,

If I use incus console container then login the folder is there…

But if I use incus exec container -- sudo --user uname --login the folder /run/user/1000doesn’t exist.

I tried to see if any of the --user services are running using:
systemctl --user list-units state=active
but it produced an error
Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
And indeed both environment variables are empty.
If I manually export the dbus session using
export $(dbus-launch)
And run the list-unit command again, then systemd exists with error code 1. Below is the related journalctl log

Jun 30 18:31:46 test-x-container dbus-daemon[1533]: [session uid=1000 pid=1531 pidfd=5] Activating service name='org.freedesktop.systemd1' requested by ':1.0' (uid=1000 pid=1536 comm="systemctl --user list-units state=active")
Jun 30 18:31:46 test-x-container dbus-daemon[1533]: [session uid=1000 pid=1531 pidfd=5] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1

For now I just use the console mode but I’d like to hear how to troubleshoot this issue…I’ve probably done something wrong…

Thanks in advance!

stgraber · June 30, 2025, 7:01pm

It’s basically a matter of whether the full stack including integration with logind kicks in or not.

You could probably do incus exec container -- login and go through that login sequence which would then work the same as with incus console.

May be worth also trying su -l NAME to see if that kicks the right part of PAM.

Baba_Open · June 30, 2025, 7:13pm

Thank you for the quick response.

As you had suspected incus exec container -- login works

But if I enter with exec then try su -l UNAME the folder are still missing…

I don’t know anything about PAM, I’ve put it on my to-do list

But I was wondering, is this expected behavior or maybe something about my container. I used incus launch images:archlinux/current/amd64 test-x-container to build the container.

I can also try with another linux-distro to test…

Stephane thanks for all the hard-work…your youtube tutorials have saved me on several occations!

stgraber · July 16, 2025, 8:46pm

It’s generally expected that incus exec BLAH bash will not hit the PAM stack. incus shell BLAH may hit the PAM stack though that may depend between distros.

Look in /etc/pam.d, there typically are su and su-l specific profiles for those commands. Though I’m mostly familiar with the Debian/Ubuntu behavior, different distros may have different configs there.

Baba_Open · July 18, 2025, 9:45pm

Thank you @stgraber. And thank you for pointing me to PAM.

(I will try incus shell later & report back).

Today I had time so read up on pam and I tried something using your earlier hint.

I ended up using pam_warn.so (couldn’t get the pam_echo to work) to figure which configuration was being invoked.

When I do incus exec qt-apps -- sudo --login --user user1 /bin/bash it is the /etc/pam.d/sudo that’s being triggered (as best as I can see)

I logged in and checked journalctl for pam records.

I suspect it maybe a combination of systemd.so & systemd_home.so modules that are missing from sudo (those logs are missing from journalctl when I use incus exec qt-apps -- sudo --login --user user1 /bin/bash)

>>>login
Jul 18 20:41:32 qt-apps login[2821]: pam_unix(login:session): session opened for user user1(uid=1000) by user1(uid=0)
Jul 18 20:41:32 qt-apps systemd-logind[193]: New session c7 of user user1.
Jul 18 20:41:32 qt-apps systemd[1]: Started Session c7 of User user1.
Jul 18 20:41:32 qt-apps login[2821]: LOGIN ON pts/2 BY user1
                              >>>exit<<<
Jul 18 20:42:44 qt-apps login[2821]: pam_unix(login:session): session closed for user user1
Jul 18 20:42:44 qt-apps systemd[1]: session-c7.scope: Deactivated successfully.
Jul 18 20:42:44 qt-apps systemd-logind[193]: Session c7 logged out. Waiting for processes to exit.
Jul 18 20:42:44 qt-apps systemd-logind[193]: Removed session c7.

Then I did something really stupid (I’ll come back to it and fix it later) - this is probably a horrible idea (sorry for including it here)

Added the last line to the /etc/pam.d/sudo

auth            include         system-auth
account         include         system-auth
session         include         system-auth
session       include      system-local-login

The last include imports a whole bunch of things for the session control including executing the systemd.so and systemd_home.so

Now when I do incus exec qt-apps -- sudo --login --user user1 /bin/bash I have /run/user/1000 and the proxies are linked in!

And If I do `incus exec qt-apps – sudo --login --user user1 /bin/bash -ilc “firefox” it works! (aside: Reverted my changes just to see if this approach of invoking firefox would work without changing pam…the /run/user/1000 was missing…so nope.)

But if I do incus exec qt-apps -- sudo --login --user user1 firefox /tmp/.X11-unix/X0` is missing

All this was before I saw your last post, I’ll come back to this when I have more time.