[SOLVED] nspawn container login and dbus issue

AcidDemon · 2025-02-16 16:47:11

I'm having a problem with an `nspawn` container and don't know what to check.

The issue is that I can start the container with:

systemd-nspawn -D /var/lib/machines/tor-container -b

It boots up without any problems (more on that later), and I can log in as `root` without any issues.

When I try to login with a different user, it fails with:
-- username: /home/username: change directory failed: Permission denied

So there seems to be a problem directly during the login and access.
More on it later.

The same problem (or maybe another problem?) occurs when trying to login via:

machinectl login tor-container

I have added pts/0 to /etc/securetty.
The logfile (journalctl -b) of the container shows the following:

Feb 16 16:24:18 tor systemd[1]: Starting D-Bus System Message Bus...
Feb 16 16:24:18 tor systemd[1]: Started D-Bus System Message Bus.
Feb 16 16:24:18 tor dbus-broker-launch[86]: ERROR launcher_run_child @ ../dbus-broker-36/src/launch/
Feb 16 16:24:18 tor dbus-broker-launch[85]: ERROR service_add @ ../dbus-broker-36/src/launch/service
Feb 16 16:24:18 tor dbus-broker-launch[85]:       launcher_add_services @ ../dbus-broker-36/src/laun
Feb 16 16:24:18 tor dbus-broker-launch[85]:       launcher_run @ ../dbus-broker-36/src/launch/launch
Feb 16 16:24:18 tor dbus-broker-launch[85]:       run @ ../dbus-broker-36/src/launch/main.c +152
Feb 16 16:24:18 tor dbus-broker-launch[85]:       main @ ../dbus-broker-36/src/launch/main.c +178
Feb 16 16:24:18 tor dbus-broker-launch[85]: Exiting due to fatal error: -107
Feb 16 16:24:18 tor systemd[1]: dbus-broker.service: Main process exited, code=exited, status=1/FAIL
Feb 16 16:24:18 tor systemd[1]: dbus-broker.service: Failed with result 'exit-code'.
Feb 16 16:24:18 tor systemd[1]: dbus-broker.service: Start request repeated too quickly.
Feb 16 16:24:18 tor systemd[1]: dbus-broker.service: Failed with result 'exit-code'.
Feb 16 16:24:18 tor systemd[1]: Failed to start D-Bus System Message Bus.

Just to understand the situation:
The `dbus-broker` inside the container needs access to D-Bus on the host and fails.
At least, that's what I see in the logs.

This occurs in the log when machinectl login is executed:

feb 16 16:41:08 tor login[94]: pam_unix(login:session): session opened for user root(uid=0) by root(
Feb 16 16:41:08 tor login[94]: pam_systemd(login:session): Failed to connect to system bus: Connecti

The container was created via the following steps:

mkdir /var/lib/machines/tor-container
pacstrap -k -c -i /var/lib/machines/tor-container base base-devel tor nyx --ignore linux --ignore li

After running `pacstrap` and booting into the container, I noticed that nearly all folders had an owner and group consisting of a long integer. I could not associate these values with any user on the host, nor did I find any relevant mappings in `subuid`/`subgid`.
Searching the host filesystem also yielded no results.

I'm aware that an `nspawn` container can be started with `--private-users=pick`,
but as I understand it, this should only affect the namespace and not the filesystem.
Is this assumption incorrect?

For clarity, the container was **not** started with this option—I'm just curious about how it works.

The resolve the permission issues, the following approach was taken:

pacman -Qkk 2>&1| awk '/^warning.*mismatch/ {print $3}'| pacrepairfile --uid --gid --mode

Nevertheless, it does not fix the issue, and I don't know where to look for the problem.
Any help would be greatly appreciated!

Tl;dr
- nspawn container created and strapped with pacstrap
- file permissions messed up
- problem logging in via machinectl login container (permission denied)
- dbus errors in journalctl -b
- permissions repaired with pacrepairfile

Questions:
How does the container interact with the host via dbus?
Did anything change to the arch wiki, describing nspawn container creation?

Last edited by AcidDemon (2025-02-18 12:23:56)

jonno2002 · 2025-02-16 18:50:56

i think this where your problem lies:
https://wiki.archlinux.org/title/System … wn_options
the -U appears to be a default value even though your not specifying it during launch...

but i highly recommend reading that whole page if you havent already.
its been a LONG time since i set up my nspawn containers so im a bit rusty, but i use systemd-nspawn@.service to start mine.

EDIT:
just checked my config and yea i dont use -U or private-users:

[Exec]
Boot=1
PrivateUsers=no
..........

Last edited by jonno2002 (2025-02-16 18:53:24)

NuSkool · 2025-02-18 09:04:26

systemd-nspawn -D /var/lib/machines/tor-container -b

Are you running as root here, or?

When I try to login with a different user, it fails

I need to have you post the commands with output you've tried using to log in as user?
It's so much easier to troubleshoot with all the info. ie: Exact commands and output/logs.
If the logs are too long though, set up a link to it.
And for clarification, can you 'su user' in the container? ie: You've set up and verified user account works.

Could you post the command you've tried using to log in as user?

I'd prefer to see what you've tried first. I may be able to walk you through the process.
If you're familiar with scripting, here are a bunch of examples though. https://github.com/Cody-Learner/aurch

all folders had an owner and group consisting of a long integer

AFAIK it's normal to have a numerical uid/gid from inside the container. They'll be normal from outside the container.
How long they are used to depend on how you've configured your /etc/subuid subgid.

I've wrote scripts to automated building containers that are used from both inside, and from the outside using the host system.
To work around the uid/gid issues and make things easier I've used this and similar:

hostUID="$(id -u ${USER})"
hostGID="$(id -g ${USER})"

This would undoubtedly compromise the isolation aspects though, so do be aware...
If you don't specifically need matching uid/gid inside to out, I'd definitely not do it.

EDIT:
OK, the 'dbus- - -' in your logs has me curious now.
I've never noticed that involved with nspawn in my logs. This is from the journal when calling a script used to interact with a container.

sudo[41582]:     jeff : TTY=pts/2 ; PWD=/usr/local/aurch/base/chroot-g2a/home/builduser/webfs ; USER=root ; COMMAND=/usr/bin/systemd-nspawn

Nothing about dbus. And for verification you're not manually trying to use dbus-* to run or launch anything?
If not, I'm thinking your container name may be an issue. ie: Could the 'tor-*' command possibly be getting grabbed by your host tor install?
Try renaming your container.... Better yet just build another from scratch.
Your 'pacrepairfile' fix may have created more harm than good on the container filesystem ownership/permissions.

Last edited by NuSkool (2025-02-18 10:05:09)

AcidDemon · 2025-02-18 12:23:33

Thanks for all the answers! I just (2min ago) solved the problem and it was a very simple mistake I made...

I have a umask of 077 in my shell settings and while the permissions inside the container were as they should, the folder I created for the container was not! All problems related to the failed dbus start were related to that mistake...

As suggested, I will create a new container to avoid trouble resulting from the permission fixing.

Thanks for the help and suggestions!

Last edited by AcidDemon (2025-02-18 18:52:21)

AcidDemon · 2025-02-18 12:55:17

Just for those interested in the working of dbus and machinectl login I have found a github discussion https://github.com/systemd/systemd/issues/685 which explains a little bit:

machinectl login works by creating the pty and speaking to the d-bus daemon in the container,
asking systemd to start a container-getty@$pty.service.
If you're not running systemd or d-bus in the container it can't start this service.
Additionally, it machinectl login cannot currently handle containers in uid-shifted user namespaces,
since machinectl login doesn't enter the uid namespace when trying to talk to the
d-bus daemon in the container, so the credential check fails from having the wrong UIDs.

Thanks for the suggestion NuSkool, I will take a look at the scripts. Sounds interesting.

NuSkool · 2025-02-18 19:45:20

Good job troubleshooting!

IIRC, I've seen warnings/errors when creating containers in a base dir with improper permissions. It may not have been with 'pacstrap' though. Maybe 'mkosi' or others...

I have a umask of 077 in my shell settings

Intersting... I've never found a need to change the default. Wouldn't 077 permission on created files result in no access for the user without using group access? Why/What's the purpose of that setting? Did you mean '700'? Reading umask wiki... 077 is the umask setting, not the created file permission. changing permission from 755 to 700 makes perfect sense.

One more thing with your containers, you may already be aware but if not note the '-a, --as-pid2' option.

Last edited by NuSkool (2025-02-18 20:12:42)

Arch Linux

#1 2025-02-16 16:47:11

[SOLVED] nspawn container login and dbus issue

#2 2025-02-16 18:50:56

Re: [SOLVED] nspawn container login and dbus issue

#3 2025-02-18 09:04:26

Re: [SOLVED] nspawn container login and dbus issue

#4 2025-02-18 12:23:33

Re: [SOLVED] nspawn container login and dbus issue

#5 2025-02-18 12:55:17

Re: [SOLVED] nspawn container login and dbus issue

#6 2025-02-18 19:45:20

Re: [SOLVED] nspawn container login and dbus issue

Board footer