systemd-nspawn never uses user namespaces, as you can see from the source. User namespaces do not appear to work with a chroot at all right now, because you can't enter one while in a chroot and you can't use chroot while in a user namespace. - thestinger (talk) 19:35, 23 April 2014 (UTC)
- The report is still open, I'm restoring the link here just in case: FS#36969. The removed content is . -- Kynikos (talk) 01:45, 25 April 2014 (UTC)
- In conclusion from above mentioning user namespaces was not relevant on this page (pity really). So the only way to restrict the nspawn-container appears to be limiting its capabilities on start-up (as per man systemd-nspawn). Regarding FS#36969: it was originally opened for lxc-containers anyway and those appear to support user namespaces now. Hence, the only question remaining for this article at this point would be, if there are any remaining issues arising for systemd in general when activating CONFIG_USER_NS for lxc (opinion on that?).
- I have added the bug and a couple links with background info to talk:linux containers so the reference does not get lost.
- --Indigo (talk) 08:56, 3 May 2014 (UTC)
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)
extra-x86_64-build. -- thestinger 18:41, 19 January 2015 (UTC) package implements this for Arch packaging, and is used for building everything in the repositories. It's as simple as replacing
systemd-nspawn usage examples
Missing configuration overview
First, thanks to everyone who contributed to this page. It's one of the best I could have found on the net about the topic.
I had trouble to understand how can I configure my containers. Was started to copy the
/usr/lib/systemd/system/systemd-nspawn@.service file to
/etc/systemd/system and made changes for network changes. This was not as good as to add the
/etc/systemd/nspawn/mycontainer.nspawn file and edit the relevant
[Files] parts there... So, I would recommend to hint with a small section at the top, to use the
.nspawn file rather than the command line parameters. And emphase those exceptions when only the command line can help.
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.)
- For the first point there is already a systemd-nspawn#Specify_per-container_settings section. -- Lahwaacz (talk) 14:43, 26 September 2017 (UTC)
Bootstrap Arch Linux i686 inside x86_64 host
Since Arch dropped 32 bit support in the install media + is dropping support altogether soon, isn't this section outdated/useless now?
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.