From ArchWiki
Latest comment: 11 June 2023 by ZarakshR in topic root login fails

systemd-nspawn as a build environment

I've been struggling trying to set this up and i assume others will as well. Would be nice to have an example of a build workflow using this tool on this or on a seperate page. Captaincurrie (talk) 18:32, 19 January 2015 (UTC)Reply[reply]

The devtools package implements this for Arch packaging, and is used for building everything in the repositories. It's as simple as replacing makepkg with extra-i686-build + extra-x86_64-build. -- thestinger 18:41, 19 January 2015 (UTC)Reply[reply]
Cool, i'll give that a try. Thanks :) Captaincurrie (talk) 10:05, 20 January 2015 (UTC)Reply[reply]
The workflow is described in DeveloperWiki:Building in a clean chroot, closing. -- Lahwaacz (talk) 13:34, 23 August 2020 (UTC)Reply[reply]
That's for building on arch. What about creating an environment that will be used by other platforms ? (reopen) Louson (talk) 11:48, 15 September 2020 (UTC)Reply[reply]
There is systemd-nspawn#Build and test packages with a link. Of course there are not such nice wrappers as devtools provides. -- Lahwaacz (talk) 11:55, 15 September 2020 (UTC)Reply[reply]
You can also freeze a systemd-nspawn archlinux container that you can reuse later in order to keep the same environment. I used to combine systemd-nspawn with the archlinux archive but it's broken (changing the password returns an error: Authentication token manipulation error). It can be useful to build a kernel or a system with yocto or buildroot which are dependant of the gcc version. Louson (talk) 12:18, 15 September 2020 (UTC)Reply[reply]

Missing configuration of allowed devices

The other thing I have not find here is, how can I use devices from the container... Was set up an mpd server which needs network connection and an audio sink. My case the audio sink was ALSA devices (and not pulse socket). Had problem to undersand that I need to bind the device files to the container. (In the .nspawn file.) And also need DeviceAllow=char-alsa rwm line in the .service file. (Or to be precise in the override.conf of the service file.)

--Rizsotto (talk) 13:40, 26 September 2017 (UTC)Reply[reply]

As of this writing, does Nvidia GPUs answer these questions? 5.8 Run docker in systemd-nspawn also looks to me a similar, related, example. Regid (talk) 20:53, 28 March 2023 (UTC)

Wayland desktop environment inside nspawn

It would be great if someone with expertise wrote a section regarding starting graphical environments inside nspawn containers. It looks like there is some info on Github. This example shows how to run desktop environments in nspawn containers win kwin_wayland compositor. It should be possible to achieve this with mutter too, as it even supports nested mode with something like mutter --wayland --nested. Also we should be able to open new dbus session with something like eval $(dbus-launch --sh-syntax). Also it would be great if someone explained which packages could be omitted inside the container (like we don't need xorg org wayland installed if I get it right) on some popular distros.

—This unsigned comment is by Unb0rn (talk) 20:07, 23 June 2018‎. Please sign your posts with ~~~~!

As of this writing, does Systemd-nspawn#Use an X environment answer some of the questions? Regid (talk) 20:53, 28 March 2023 (UTC)Reply[reply]
I think it might be interesting to have a wayland-native session in the container, without using xwayland. Personally I experimented in the past with binding the /run/user/1000/wayland- socket and it was working, but this is probably not ideal. Kyleh (talk)

/tmp/.X11-unix contents have to be bind-mounted as read-only - still relevant?

For me (systemd version 239) X applications also work if /tmp/.X11-unix is bound rw. Can anybody confirm that?

-- Chleh (talk) 22:51, 2 January 2019 (UTC)Reply[reply]

I confirm it works with normal binding. Also the linked bug report is closed and apparently solved since 2017. -- Bonob (talk) 17:36, 27 November 2019 (UTC)Reply[reply]

I asked in the systemd IRC and user 'grawity' mentioned that the X server also listens on an abstract socket at @/tmp/.X11-unix/X0, which is available inside the container if you haven't isolated its network, and thus can still be used inside the container. This means that if you don't isolate the container's network, you don't even need to bind-mount /tmp/.X11-unix to get X applications running, and I guess you also get all the X security issues for free too, which might be worth mentioning in the article. --Tomaz (talk) 13:21, 25 November 2021 (UTC)Reply[reply]

Using machinectl without root permissions

In the Using machinectl without root permissions section of the systemd-nspawn wiki, the two PolKit rules that allow PolKit actions that start with org.freedesktop.machine1. enable the subject user to login as any other user including root without password using the following machinectl command:

$ machinectl shell --uid=root

Most of the default actions of the org.freedesktop.machine1.policy are backed with the auth_admin element which requires the PolKit defined administrator to identify itself. Note that the PolKit defined administrator defaults to any user who is in the wheel group and this is already reasonably flexible.

Nicolas Bouchinet (talk) 10:49, 18 March 2021 (UTC)Reply[reply]

Use an X environment - Move to Xorg page

Most of the information in this section applies to a broader set of use-cases and can be referenced in other parts of the wiki. LXC Xorg considerations, for instance, does not properly discuss running X clients inside containers, and suggests setting the very unsafe xhost + rather than the the cookie authentication method detailed method in this page. I'm planning to expand the LXC article once the page is moved. Jokersus (talk) 13:08, 19 January 2022 (UTC)Reply[reply]

The information does not fit into the Xorg page. It's revolving around the pages like xhost and Xephyr. Most of it seems bound to systemd-nspawn (at least via examples), but if you have a different idea, feel free to propose a specific draft. — Lahwaacz (talk) 09:46, 23 January 2022 (UTC)Reply[reply]
My bad, I should've clarified I was referring specifically to the xhost bits. Perhaps an article in Xorg about authenticating remote machines and containers or multiple users would be more appropriate? If not, I will just prepare a similar section for LXC if redundancy is not an issue. Jokersus (talk) 19:48, 23 January 2022 (UTC)Reply[reply]
You can't have an article in an article. xhost already has an article in xhost. — Lahwaacz (talk) 21:01, 23 January 2022 (UTC)Reply[reply]
The section is discussing a method of avoiding xhost, not xhost itself. In any case, I don't think it's fair that the only mention of cookie authentication in the wiki (to my knowledge) is in the systemd-nspawn article. Jokersus (talk) 16:31, 24 January 2022 (UTC)Reply[reply]

Domain name resolution: /etc/resolv.conf should have its own subsection; this section needs expansion

The "Domain name resolution" section is only about /etc/resolv.conf, but the current section doesn't clearly express what can --resolv-conf (or ResolvConf= in .nspawn file) can do: it can only changes /etc/resolv.conf, not everything. Yemoran (talk) 17:56, 6 February 2022 (UTC)Reply[reply]

It's useless to have a section with one introductory sentence and one subsection. In any case, it is not a reason to add a Template:Expansion, because this problem does not indicate anything missing—Template:Style should be used for that. What do you think the section is missing? — Lahwaacz (talk) 18:07, 6 February 2022 (UTC)Reply[reply]
About missing: the section does not discuss options other than "auto". For some cases DNS automatically works, but not all, and adding other confusing cases can help.
About one introductory sentence and one subsection: for this alone this is Template:Style. But the section is more about incomplete article, so its Template:Expansion. Template:Expansion at least resides in three points:
1. "Domain name resolution" is a larger topic than /etc/resolv.conf, and I believe there are more cases where DNS does not automatically work even after fixing /etc/resolv.conf, especially in the case of virtual network between host and container.
2. Even if the section is only about /etc/resolv.conf, the current description is confusing: the current situation is that the title is "Domain name resolution", which is a much broader one than configuring /etc/resolv.conf, but the current description does not describe it explicitly: the current description does not say the functions of the option --resolv-conf clearly, and can make the illusion that --resolv-conf makes systemd-nspawn magically configure DNS, but it's not. (I believe this section expresses itself pretty unclearly)
3. This section does not discuss possible values of --resolv-conf, and only describes "auto", which is unhelpful (because if it works, nobody search over the Internet for solutions). At least --resolv-conf=replace-host can be helpful in the case when no init program is launched but the container expects systemd-resolved.
Yemoran (talk) 18:36, 6 February 2022 (UTC)Reply[reply]
First, the section links to the manual (systemd-nspawn(1) § Integration Options) and only then it describes what auto means. If the user finds that it does not work for them, they can see the manual and configure the option accordingly for their container. The wiki does not duplicate manuals just for completeness.
It is also pretty obvious from the section that if --private-network is used (which is implied by --network-veth and other options), the configuration of /etc/resolv.conf is left up to the user according to the Domain name resolution page.
Also I don't see a problem with the section title "Domain name resolution" and omitting "/etc/resolv.conf" in the heading. If there was something other than /etc/resolv.conf to be described in the section, it would be mentioned, but since it does not seem to be the case, I'll reiterate that it's useless to have a section with one introductory sentence and one subsection.
Lahwaacz (talk) 19:02, 6 February 2022 (UTC)Reply[reply]

Unprivileged container and user namespace

systemd-nspawn's unprivileged container needs user namespace support. Its only common point with LXC is about user namespaces. A link should be given as Linux_Containers#Unprivileged_containers_on_linux-hardened_and_custom_kernels.

Note that systemd-nspawn must be root so it requires user namespace but not necessarily unprivilged user namespace, unlike LXC and other applications like browsers.

There is no wiki page for user namespace. The only places I found for user namespace are here, Linux_Containers#Unprivileged_containers_on_linux-hardened_and_custom_kernels and Security#Sandboxing_applications (the two scary note and warning).

Yemoran (talk) 20:09, 6 February 2022 (UTC)Reply[reply]

SystemCallFilter add_key not needed?

I experimented with Docker in systemd-nspawn a bit, and it seems that `add_key` is not used. I couldn't find any references to it nor from (likely wrong) source codes. Following up on this...

—This unsigned comment is by Compose (talk) 14:21, 25 June 2022. Please sign your posts with ~~~~!

Add info for 32 bit containers on 64 bit systems

For a great way to compile in 32 bit environment on 64 bit installs there exists an nspawn way. Can it be added to this wiki page? It's very straightforward using this (use a custom pacman.conf with i686 for architecture, add 32 bit mirror, install 32 bit keyring, pacstrap that, launch with 32 bit personaliity flag).

—This unsigned comment is by Hitchhacker (talk) 19:45, 5 November 2022. Please sign your posts with ~~~~!

A trick way to mount a NFS share with the container

Topic related section 6.4 Systemd-nspawn#Mounting_a_NFS_share_inside_the_container

I create this new topic to discuss because one user updates a trick way about how to share NFS mounting to the container in the Chinese page. I am not sure should I sync it to this original English page.

This way is to use the host to mount the NFS and then map it to the container directory. After mounting, you will encounter permission errors, this is because the user ID of the container is mapped by the host. There are various ways to solve this problem, such as the following.

  • Use administrator permissions on the host to change the user ID belonging to the NFS mount directory to the actual user ID for the container.
  • Use the --private-users parameter to specify the user to be used as a privileged user when the container is started.
  • Use the --bind-user parameter when mounting a directory to specify that the user to which the NFS directory belongs is mapped to the container.

As we see, this way is not mounting inside one container but host. I think it would be better that we add this way into section 5.4 Systemd-nspawn#Access host filesystem, and mention it in section 6.4 .

--Samuel as Amao (talk) 09:04, 9 January 2023 (UTC)Reply[reply]

root login fails

Is the section still accurate? On my system, adding pts/O to /etc/securetty on the container works properly and allows root login even after a container reboot. -- Cvlc (talk) 15:45, 13 February 2023 (UTC)Reply[reply]

I can confirm that adding pts/0 to /etc/securetty works even after rebooting on my machine as well. ZarakshR (talk) 18:53, 11 June 2023 (UTC)Reply[reply]