2 <!DOCTYPE refentry PUBLIC
"-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
4 <!ENTITY % entities SYSTEM
"custom-entities.ent" >
7 <!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
9 <refentry id=
"systemd-nspawn"
10 xmlns:
xi=
"http://www.w3.org/2001/XInclude">
13 <title>systemd-nspawn
</title>
14 <productname>systemd
</productname>
18 <refentrytitle>systemd-nspawn
</refentrytitle>
19 <manvolnum>1</manvolnum>
23 <refname>systemd-nspawn
</refname>
24 <refpurpose>Spawn a command or OS in a light-weight container
</refpurpose>
29 <command>systemd-nspawn
</command>
30 <arg choice=
"opt" rep=
"repeat">OPTIONS
</arg>
31 <arg choice=
"opt"><replaceable>COMMAND
</replaceable>
32 <arg choice=
"opt" rep=
"repeat">ARGS
</arg>
36 <command>systemd-nspawn
</command>
37 <arg choice=
"plain">--boot
</arg>
38 <arg choice=
"opt" rep=
"repeat">OPTIONS
</arg>
39 <arg choice=
"opt" rep=
"repeat">ARGS
</arg>
44 <title>Description
</title>
46 <para><command>systemd-nspawn
</command> may be used to run a command or OS in a light-weight namespace
47 container. In many ways it is similar to
<citerefentry
48 project='man-pages'
><refentrytitle>chroot
</refentrytitle><manvolnum>1</manvolnum></citerefentry>, but more powerful
49 since it fully virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems and
50 the host and domain name.
</para>
52 <para><command>systemd-nspawn
</command> may be invoked on any directory tree containing an operating system tree,
53 using the
<option>--directory=
</option> command line option. By using the
<option>--machine=
</option> option an OS
54 tree is automatically searched for in a couple of locations, most importantly in
55 <filename>/var/lib/machines/
</filename>, the suggested directory to place OS container images installed on the
58 <para>In contrast to
<citerefentry
59 project='man-pages'
><refentrytitle>chroot
</refentrytitle><manvolnum>1</manvolnum></citerefentry> <command>systemd-nspawn
</command>
60 may be used to boot full Linux-based operating systems in a container.
</para>
62 <para><command>systemd-nspawn
</command> limits access to various kernel interfaces in the container to read-only,
63 such as
<filename>/sys/
</filename>,
<filename>/proc/sys/
</filename> or
<filename>/sys/fs/selinux/
</filename>. The
64 host's network interfaces and the system clock may not be changed from within the container. Device nodes may not
65 be created. The host system cannot be rebooted and kernel modules may not be loaded from within the
68 <para>Use a tool like
<citerefentry
69 project='mankier'
><refentrytitle>dnf
</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry
70 project='die-net'
><refentrytitle>debootstrap
</refentrytitle><manvolnum>8</manvolnum></citerefentry>, or
71 <citerefentry project='archlinux'
><refentrytitle>pacman
</refentrytitle><manvolnum>8</manvolnum></citerefentry> to
72 set up an OS directory tree suitable as file system hierarchy for
<command>systemd-nspawn
</command> containers. See
73 the Examples section below for details on suitable invocation of these commands.
</para>
75 <para>As a safety check
<command>systemd-nspawn
</command> will verify the existence of
76 <filename>/usr/lib/os-release
</filename> or
<filename>/etc/os-release
</filename> in the container tree before
77 booting a container (see
78 <citerefentry><refentrytitle>os-release
</refentrytitle><manvolnum>5</manvolnum></citerefentry>). It might be
79 necessary to add this file to the container tree manually if the OS of the container is too old to contain this
80 file out-of-the-box.
</para>
82 <para><command>systemd-nspawn
</command> may be invoked directly from the interactive command line or run as system
83 service in the background. In this mode each container instance runs as its own service instance; a default
84 template unit file
<filename>systemd-nspawn@.service
</filename> is provided to make this easy, taking the container
85 name as instance identifier. Note that different default options apply when
<command>systemd-nspawn
</command> is
86 invoked by the template unit file than interactively on the command line. Most importantly the template unit file
87 makes use of the
<option>--boot
</option> option which is not the default in case
<command>systemd-nspawn
</command>
88 is invoked from the interactive command line. Further differences with the defaults are documented along with the
89 various supported options below.
</para>
91 <para>The
<citerefentry><refentrytitle>machinectl
</refentrytitle><manvolnum>1</manvolnum></citerefentry> tool may
92 be used to execute a number of operations on containers. In particular it provides easy-to-use commands to run
93 containers as system services using the
<filename>systemd-nspawn@.service
</filename> template unit
96 <para>Along with each container a settings file with the
<filename>.nspawn
</filename> suffix may exist, containing
97 additional settings to apply when running the container. See
98 <citerefentry><refentrytitle>systemd.nspawn
</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
99 details. Settings files override the default options used by the
<filename>systemd-nspawn@.service
</filename>
100 template unit file, making it usually unnecessary to alter this template file directly.
</para>
102 <para>Note that
<command>systemd-nspawn
</command> will mount file systems private to the container to
103 <filename>/dev/
</filename>,
<filename>/run/
</filename> and similar. These will not be visible outside of the
104 container, and their contents will be lost when the container exits.
</para>
106 <para>Note that running two
<command>systemd-nspawn
</command> containers from the same directory tree will not make
107 processes in them see each other. The PID namespace separation of the two containers is complete and the containers
108 will share very few runtime objects except for the underlying file system. Rather use
109 <citerefentry><refentrytitle>machinectl
</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
110 <command>login
</command> or
<command>shell
</command> commands to request an additional login session in a running
113 <para><command>systemd-nspawn
</command> implements the
<ulink
114 url=
"https://systemd.io/CONTAINER_INTERFACE">Container Interface
</ulink> specification.
</para>
116 <para>While running, containers invoked with
<command>systemd-nspawn
</command> are registered with the
117 <citerefentry><refentrytitle>systemd-machined
</refentrytitle><manvolnum>8</manvolnum></citerefentry> service that
118 keeps track of running containers, and provides programming interfaces to interact with them.
</para>
122 <title>Unprivileged Operation
</title>
124 <para><command>systemd-nspawn
</command> may be invoked with or without privileges. The full functionality
125 is currently only available when invoked with privileges. When invoked without privileges, various
126 limitations apply, including, but not limited to:
</para>
129 <listitem><para>Only disk image based containers are supported (i.e.
<option>--image=
</option>).
130 Directory based ones (i.e.
<option>--directory=
</option>) are not supported.
</para></listitem>
132 <listitem><para>Machine registration via
<option>--machine=
</option> is not supported.
</para></listitem>
134 <listitem><para>Only
<option>--private-network
</option> and
<option>--network-veth
</option> networking modes are supported.
</para></listitem>
137 <para>When running in unprivileged mode, some needed functionality is provided via
138 <citerefentry><refentrytitle>systemd-mountfsd.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry>
140 <citerefentry><refentrytitle>systemd-nsresourced.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry></para>
144 <title>Options
</title>
146 <para>If option
<option>--boot
</option> is specified, the arguments
147 are used as arguments for the init program. Otherwise,
148 <replaceable>COMMAND
</replaceable> specifies the program to launch
149 in the container, and the remaining arguments are used as
150 arguments for this program. If
<option>--boot
</option> is not used and
151 no arguments are specified, a shell is launched in the
154 <para>The following options are understood:
</para>
159 <term><option>-q
</option></term>
160 <term><option>--quiet
</option></term>
162 <listitem><para>Turns off any status output by the tool
163 itself. When this switch is used, the only output from nspawn
164 will be the console output of the container OS
167 <xi:include href=
"version-info.xml" xpointer=
"v209"/></listitem>
171 <term><option>--settings=
<replaceable>MODE
</replaceable></option></term>
173 <listitem><para>Controls whether
174 <command>systemd-nspawn
</command> shall search for and use
175 additional per-container settings from
176 <filename>.nspawn
</filename> files. Takes a boolean or the
177 special values
<option>override
</option> or
178 <option>trusted
</option>.
</para>
180 <para>If enabled (the default), a settings file named after the
181 machine (as specified with the
<option>--machine=
</option>
182 setting, or derived from the directory or image file name)
183 with the suffix
<filename>.nspawn
</filename> is searched in
184 <filename>/etc/systemd/nspawn/
</filename> and
185 <filename>/run/systemd/nspawn/
</filename>. If it is found
186 there, its settings are read and used. If it is not found
187 there, it is subsequently searched in the same directory as the
188 image file or in the immediate parent of the root directory of
189 the container. In this case, if the file is found, its settings
190 will be also read and used, but potentially unsafe settings
191 are ignored. Note that in both these cases, settings on the
192 command line take precedence over the corresponding settings
193 from loaded
<filename>.nspawn
</filename> files, if both are
194 specified. Unsafe settings are considered all settings that
195 elevate the container's privileges or grant access to
196 additional resources such as files or directories of the
197 host. For details about the format and contents of
198 <filename>.nspawn
</filename> files, consult
199 <citerefentry><refentrytitle>systemd.nspawn
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
201 <para>If this option is set to
<option>override
</option>, the
202 file is searched, read and used the same way, however, the order of
203 precedence is reversed: settings read from the
204 <filename>.nspawn
</filename> file will take precedence over
205 the corresponding command line options, if both are
208 <para>If this option is set to
<option>trusted
</option>, the
209 file is searched, read and used the same way, but regardless
210 of being found in
<filename>/etc/systemd/nspawn/
</filename>,
211 <filename>/run/systemd/nspawn/
</filename> or next to the image
212 file or container root directory, all settings will take
213 effect, however, command line arguments still take precedence
214 over corresponding settings.
</para>
216 <para>If disabled, no
<filename>.nspawn
</filename> file is read
217 and no settings except the ones on the command line are in
220 <xi:include href=
"version-info.xml" xpointer=
"v226"/></listitem>
226 <title>Image Options
</title>
231 <term><option>-D
</option></term>
232 <term><option>--directory=
</option></term>
234 <listitem><para>Directory to use as file system root for the container.
</para>
236 <para>If neither
<option>--directory=
</option>, nor
<option>--image=
</option> is specified the
237 directory is determined by searching for a directory named the same as the machine name specified
238 with
<option>--machine=
</option>. See
239 <citerefentry><refentrytitle>machinectl
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
240 section
"Files and Directories" for the precise search path.
</para>
242 <xi:include href=
"vpick.xml" xpointer=
"directory"/>
244 <para>If neither
<option>--directory=
</option>,
<option>--image=
</option>, nor
245 <option>--machine=
</option> are specified, the current directory will be used. May not be specified
246 together with
<option>--image=
</option>.
</para></listitem>
250 <term><option>--template=
</option></term>
252 <listitem><para>Directory or
<literal>btrfs
</literal> subvolume to use as template for the
253 container's root directory. If this is specified and the container's root directory (as configured by
254 <option>--directory=
</option>) does not yet exist it is created as
<literal>btrfs
</literal> snapshot
255 (if supported) or plain directory (otherwise) and populated from this template tree. Ideally, the
256 specified template path refers to the root of a
<literal>btrfs
</literal> subvolume, in which case a
257 simple copy-on-write snapshot is taken, and populating the root directory is instant. If the
258 specified template path does not refer to the root of a
<literal>btrfs
</literal> subvolume (or not
259 even to a
<literal>btrfs
</literal> file system at all), the tree is copied (though possibly in a
260 'reflink' copy-on-write scheme — if the file system supports that), which can be substantially more
261 time-consuming. Note that the snapshot taken is of the specified directory or subvolume, including
262 all subdirectories and subvolumes below it, but excluding any sub-mounts. May not be specified
263 together with
<option>--image=
</option> or
<option>--ephemeral
</option>.
</para>
265 <para>Note that this switch leaves hostname, machine ID and
266 all other settings that could identify the instance
269 <xi:include href=
"version-info.xml" xpointer=
"v219"/></listitem>
273 <term><option>-x
</option></term>
274 <term><option>--ephemeral
</option></term>
276 <listitem><para>If specified, the container is run with a temporary snapshot of its file system that is removed
277 immediately when the container terminates. May not be specified together with
278 <option>--template=
</option>.
</para>
279 <para>Note that this switch leaves hostname, machine ID and all other settings that could identify
280 the instance unmodified. Please note that — as with
<option>--template=
</option> — taking the
281 temporary snapshot is more efficient on file systems that support subvolume snapshots or 'reflinks'
282 natively (
<literal>btrfs
</literal> or new
<literal>xfs
</literal>) than on more traditional file
283 systems that do not (
<literal>ext4
</literal>). Note that the snapshot taken is of the specified
284 directory or subvolume, including all subdirectories and subvolumes below it, but excluding any
287 <para>With this option no modifications of the container image are retained. Use
288 <option>--volatile=
</option> (described below) for other mechanisms to restrict persistency of
289 container images during runtime.
</para>
291 <xi:include href=
"version-info.xml" xpointer=
"v219"/>
296 <term><option>-i
</option></term>
297 <term><option>--image=
</option></term>
299 <listitem><para>Disk image to mount the root directory for the
300 container from. Takes a path to a regular file or to a block
301 device node. The file or block device must contain
305 <listitem><para>An MBR partition table with a single
306 partition of type
0x83 that is marked
307 bootable.
</para></listitem>
309 <listitem><para>A GUID partition table (GPT) with a single
311 0fc63daf-
8483-
4772-
8e79-
3d69d8477de4.
</para></listitem>
313 <listitem><para>A GUID partition table (GPT) with a marked
314 root partition which is mounted as the root directory of the
315 container. Optionally, GPT images may contain a home and/or
316 a server data partition which are mounted to the appropriate
317 places in the container. All these partitions must be
318 identified by the partition types defined by the
<ulink
319 url=
"https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable
320 Partitions Specification
</ulink>.
</para></listitem>
322 <listitem><para>No partition table, and a single file system spanning the whole image.
</para></listitem>
325 <para>On GPT images, if an EFI System Partition (ESP) is discovered, it is automatically mounted to
326 <filename>/efi
</filename> (or
<filename>/boot
</filename> as fallback) in case a directory by this name exists
329 <para>Partitions encrypted with LUKS are automatically decrypted. Also, on GPT images dm-verity data integrity
330 hash partitions are set up if the root hash for them is specified using the
<option>--root-hash=
</option>
333 <para>Single file system images (i.e. file systems without a surrounding partition table) can be opened using
334 dm-verity if the integrity data is passed using the
<option>--root-hash=
</option> and
335 <option>--verity-data=
</option> (and optionally
<option>--root-hash-sig=
</option>) options.
</para>
337 <para>Any other partitions, such as foreign partitions or swap partitions are not mounted. May not be specified
338 together with
<option>--directory=
</option>,
<option>--template=
</option>.
</para>
340 <xi:include href=
"vpick.xml" xpointer=
"image"/>
342 <xi:include href=
"version-info.xml" xpointer=
"v211"/></listitem>
346 <term><option>--image-policy=
<replaceable>policy
</replaceable></option></term>
348 <listitem><para>Takes an image policy string as argument, as per
349 <citerefentry><refentrytitle>systemd.image-policy
</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
350 policy is enforced when operating on the disk image specified via
<option>--image=
</option>, see
351 above. If not specified defaults to
352 <literal>root=verity+signed+encrypted+unprotected+absent:usr=verity+signed+encrypted+unprotected+absent:home=encrypted+unprotected+absent:srv=encrypted+unprotected+absent:esp=unprotected+absent:xbootldr=unprotected+absent:tmp=encrypted+unprotected+absent:var=encrypted+unprotected+absent
</literal>,
353 i.e. all recognized file systems in the image are used, but not the swap partition.
</para>
355 <xi:include href=
"version-info.xml" xpointer=
"v254"/></listitem>
359 <term><option>--oci-bundle=
</option></term>
361 <listitem><para>Takes the path to an OCI runtime bundle to invoke, as specified in the
<ulink
362 url=
"https://github.com/opencontainers/runtime-spec/blob/master/spec.md">OCI Runtime Specification
</ulink>. In
363 this case no
<filename>.nspawn
</filename> file is loaded, and the root directory and various settings are read
364 from the OCI runtime JSON data (but data passed on the command line takes precedence).
</para>
366 <xi:include href=
"version-info.xml" xpointer=
"v242"/></listitem>
370 <term><option>--read-only
</option></term>
372 <listitem><para>Mount the container's root file system (and any other file systems container in the container
373 image) read-only. This has no effect on additional mounts made with
<option>--bind=
</option>,
374 <option>--tmpfs=
</option> and similar options. This mode is implied if the container image file or directory is
375 marked read-only itself. It is also implied if
<option>--volatile=
</option> is used. In this case the container
376 image on disk is strictly read-only, while changes are permitted but kept non-persistently in memory only. For
377 further details, see below.
</para></listitem>
381 <term><option>--volatile
</option></term>
382 <term><option>--volatile=
<replaceable>MODE
</replaceable></option></term>
384 <listitem><para>Boots the container in volatile mode. When no mode parameter is passed or when mode is
385 specified as
<option>yes
</option>, full volatile mode is enabled. This means the root directory is mounted as a
386 mostly unpopulated
<literal>tmpfs
</literal> instance, and
<filename>/usr/
</filename> from the OS tree is
387 mounted into it in read-only mode (the system thus starts up with read-only OS image, but pristine state and
388 configuration, any changes are lost on shutdown). When the mode parameter is specified as
389 <option>state
</option>, the OS tree is mounted read-only, but
<filename>/var/
</filename> is mounted as a
390 writable
<literal>tmpfs
</literal> instance into it (the system thus starts up with read-only OS resources and
391 configuration, but pristine state, and any changes to the latter are lost on shutdown). When the mode parameter
392 is specified as
<option>overlay
</option> the read-only root file system is combined with a writable
393 <filename>tmpfs
</filename> instance through
<literal>overlayfs
</literal>, so that it appears at it normally
394 would, but any changes are applied to the temporary file system only and lost when the container is
395 terminated. When the mode parameter is specified as
<option>no
</option> (the default), the whole OS tree is
396 made available writable (unless
<option>--read-only
</option> is specified, see above).
</para>
398 <para>Note that if one of the volatile modes is chosen, its effect is limited to the root file system
399 (or
<filename>/var/
</filename> in case of
<option>state
</option>), and any other mounts placed in the
400 hierarchy are unaffected — regardless if they are established automatically (e.g. the EFI system
401 partition that might be mounted to
<filename>/efi/
</filename> or
<filename>/boot/
</filename>) or
402 explicitly (e.g. through an additional command line option such as
<option>--bind=
</option>, see
403 below). This means, even if
<option>--volatile=overlay
</option> is used changes to
404 <filename>/efi/
</filename> or
<filename>/boot/
</filename> are prohibited in case such a partition
405 exists in the container image operated on, and even if
<option>--volatile=state
</option> is used the
406 hypothetical file
<filename index=
"false">/etc/foobar
</filename> is potentially writable if
407 <option>--bind=/etc/foobar
</option> if used to mount it from outside the read-only container
408 <filename>/etc/
</filename> directory.
</para>
410 <para>The
<option>--ephemeral
</option> option is closely related to this setting, and provides similar
411 behaviour by making a temporary, ephemeral copy of the whole OS image and executing that. For further details,
414 <para>The
<option>--tmpfs=
</option> and
<option>--overlay=
</option> options provide similar functionality, but
415 for specific sub-directories of the OS image only. For details, see below.
</para>
417 <para>This option provides similar functionality for containers as the
<literal>systemd.volatile=
</literal>
418 kernel command line switch provides for host systems. See
419 <citerefentry><refentrytitle>kernel-command-line
</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
422 <para>Note that setting this option to
<option>yes
</option> or
<option>state
</option> will only work
423 correctly with operating systems in the container that can boot up with only
424 <filename>/usr/
</filename> mounted, and are able to automatically populate
<filename>/var/
</filename>
425 (and
<filename>/etc/
</filename> in case of
<literal>--volatile=yes
</literal>). Specifically, this
426 means that operating systems that follow the historic split of
<filename>/bin/
</filename> and
427 <filename>/lib/
</filename> (and related directories) from
<filename>/usr/
</filename> (i.e. where the
428 former are not symlinks into the latter) are not supported by
<literal>--volatile=yes
</literal> as
429 container payload. The
<option>overlay
</option> option does not require any particular preparations
430 in the OS, but do note that
<literal>overlayfs
</literal> behaviour differs from regular file systems
431 in a number of ways, and hence compatibility is limited.
</para>
433 <xi:include href=
"version-info.xml" xpointer=
"v216"/></listitem>
437 <term><option>--root-hash=
</option></term>
439 <listitem><para>Takes a data integrity (dm-verity) root hash specified in hexadecimal. This option enables data
440 integrity checks using dm-verity, if the used image contains the appropriate integrity data (see above). The
441 specified hash must match the root hash of integrity data, and is usually at least
256 bits (and hence
64
442 formatted hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but
443 the image file carries the
<literal>user.verity.roothash
</literal> extended file attribute (see
<citerefentry
444 project='man-pages'
><refentrytitle>xattr
</refentrytitle><manvolnum>7</manvolnum></citerefentry>), then the root
445 hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found (or
446 is not supported by the underlying file system), but a file with the
<filename>.roothash
</filename> suffix is
447 found next to the image file, bearing otherwise the same name (except if the image has the
448 <filename>.raw
</filename> suffix, in which case the root hash file must not have it in its name), the root hash
449 is read from it and automatically used, also as formatted hexadecimal characters.
</para>
451 <para>Note that this configures the root hash for the root file system. Disk images may also contain
452 separate file systems for the
<filename>/usr/
</filename> hierarchy, which may be Verity protected as
453 well. The root hash for this protection may be configured via the
454 <literal>user.verity.usrhash
</literal> extended file attribute or via a
<filename>.usrhash
</filename>
455 file adjacent to the disk image, following the same format and logic as for the root hash for the
456 root file system described here. Note that there's currently no switch to configure the root hash for
457 the
<filename>/usr/
</filename> from the command line.
</para>
459 <para>Also see the
<varname>RootHash=
</varname> option in
460 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
462 <xi:include href=
"version-info.xml" xpointer=
"v233"/>
467 <term><option>--root-hash-sig=
</option></term>
469 <listitem><para>Takes a PKCS7 signature of the
<option>--root-hash=
</option> option.
470 The semantics are the same as for the
<varname>RootHashSignature=
</varname> option, see
471 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
474 <xi:include href=
"version-info.xml" xpointer=
"v246"/></listitem>
478 <term><option>--verity-data=
</option></term>
480 <listitem><para>Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks
481 using dm-verity, if a root-hash is passed and if the used image itself does not contain the integrity data.
482 The integrity data must be matched by the root hash. If this option is not specified, but a file with the
483 <filename>.verity
</filename> suffix is found next to the image file, bearing otherwise the same name (except if
484 the image has the
<filename>.raw
</filename> suffix, in which case the verity data file must not have it in its name),
485 the verity data is read from it and automatically used.
</para>
487 <xi:include href=
"version-info.xml" xpointer=
"v246"/></listitem>
491 <term><option>--pivot-root=
</option></term>
493 <listitem><para>Pivot the specified directory to
<filename>/
</filename> inside the container, and either unmount the
494 container's old root, or pivot it to another specified directory. Takes one of: a path argument — in which case the
495 specified path will be pivoted to
<filename>/
</filename> and the old root will be unmounted; or a colon-separated pair
496 of new root path and pivot destination for the old root. The new root path will be pivoted to
<filename>/
</filename>,
497 and the old
<filename>/
</filename> will be pivoted to the other directory. Both paths must be absolute, and are resolved
498 in the container's file system namespace.
</para>
500 <para>This is for containers which have several bootable directories in them; for example, several
501 <ulink url=
"https://ostree.readthedocs.io/en/latest/">OSTree
</ulink> deployments. It emulates the
502 behavior of the boot loader and the initrd which normally select which directory to mount as the root
503 and start the container's PID
1 in.
</para>
505 <xi:include href=
"version-info.xml" xpointer=
"v233"/></listitem>
509 </refsect2><refsect2>
510 <title>Execution Options
</title>
514 <term><option>-a
</option></term>
515 <term><option>--as-pid2
</option></term>
517 <listitem><para>Invoke the shell or specified program as process ID (PID)
2 instead of PID
1 (init). By
518 default, if neither this option nor
<option>--boot
</option> is used, the selected program is run as the process
519 with PID
1, a mode only suitable for programs that are aware of the special semantics that the process with
520 PID
1 has on UNIX. For example, it needs to reap all processes reparented to it, and should implement
521 <command>sysvinit
</command> compatible signal handling (specifically: it needs to reboot on SIGINT, reexecute
522 on SIGTERM, reload configuration on SIGHUP, and so on). With
<option>--as-pid2
</option> a minimal stub init
523 process is run as PID
1 and the selected program is executed as PID
2 (and hence does not need to implement any
524 special semantics). The stub init process will reap processes as necessary and react appropriately to
525 signals. It is recommended to use this mode to invoke arbitrary commands in containers, unless they have been
526 modified to run correctly as PID
1. Or in other words: this switch should be used for pretty much all commands,
527 except when the command refers to an init or shell implementation, as these are generally capable of running
528 correctly as PID
1. This option may not be combined with
<option>--boot
</option>.
</para>
530 <xi:include href=
"version-info.xml" xpointer=
"v229"/>
535 <term><option>-b
</option></term>
536 <term><option>--boot
</option></term>
538 <listitem><para>Automatically search for an init program and invoke it as PID
1, instead of a shell or a user
539 supplied program. If this option is used, arguments specified on the command line are used as arguments for the
540 init program. This option may not be combined with
<option>--as-pid2
</option>.
</para>
542 <para>The following table explains the different modes of invocation and relationship to
543 <option>--as-pid2
</option> (see above):
</para>
546 <title>Invocation Mode
</title>
547 <tgroup cols='
2' align='left' colsep='
1' rowsep='
1'
>
548 <colspec colname=
"switch" />
549 <colspec colname=
"explanation" />
552 <entry>Switch
</entry>
553 <entry>Explanation
</entry>
558 <entry>Neither
<option>--as-pid2
</option> nor
<option>--boot
</option> specified
</entry>
559 <entry>The passed parameters are interpreted as the command line, which is executed as PID
1 in the container.
</entry>
563 <entry><option>--as-pid2
</option> specified
</entry>
564 <entry>The passed parameters are interpreted as the command line, which is executed as PID
2 in the container. A stub init process is run as PID
1.
</entry>
568 <entry><option>--boot
</option> specified
</entry>
569 <entry>An init program is automatically searched for and run as PID
1 in the container. The passed parameters are used as invocation parameters for this process.
</entry>
576 <para>Note that
<option>--boot
</option> is the default mode of operation if the
577 <filename>systemd-nspawn@.service
</filename> template unit file is used.
</para>
582 <term><option>--chdir=
</option></term>
584 <listitem><para>Change to the specified working directory before invoking the process in the container. Expects
585 an absolute path in the container's file system namespace.
</para>
587 <xi:include href=
"version-info.xml" xpointer=
"v229"/></listitem>
591 <term><option>-E
<replaceable>NAME
</replaceable>[=
<replaceable>VALUE
</replaceable>]
</option></term>
592 <term><option>--setenv=
<replaceable>NAME
</replaceable>[=
<replaceable>VALUE
</replaceable>]
</option></term>
594 <listitem><para>Specifies an environment variable to pass to the init process in the container. This
595 may be used to override the default variables or to set additional variables. It may be used more
596 than once to set multiple variables. When
<literal>=
</literal> and
<replaceable>VALUE
</replaceable>
597 are omitted, the value of the variable with the same name in the program environment will be used.
600 <xi:include href=
"version-info.xml" xpointer=
"v209"/></listitem>
604 <term><option>-u
</option></term>
605 <term><option>--user=
</option></term>
607 <listitem><para>After transitioning into the container, change to the specified user defined in the
608 container's user database. Like all other systemd-nspawn features, this is not a security feature and
609 provides protection against accidental destructive operations only.
</para>
611 <para>Note that if credentials are used in combination with a non-root
<option>--user=
</option>
612 (e.g.:
<option>--set-credential=
</option>,
<option>--load-credential=
</option> or
613 <option>--import-credential=
</option>), then
<option>--no-new-privileges=yes
</option> must be used, and
614 <option>--boot
</option> or
<option>--as-pid2
</option> must not be used, as the credentials would
615 otherwise be unreadable by the container due to missing privileges after switching to the specified
616 user.
</para></listitem>
620 <term><option>--kill-signal=
</option></term>
622 <listitem><para>Specify the process signal to send to the container's PID
1 when nspawn itself receives
623 <constant>SIGTERM
</constant>, in order to trigger an orderly shutdown of the container. Defaults to
624 <constant>SIGRTMIN+
3</constant> if
<option>--boot
</option> is used (on systemd-compatible init systems
625 <constant>SIGRTMIN+
3</constant> triggers an orderly shutdown). If
<option>--boot
</option> is not used and this
626 option is not specified the container's processes are terminated abruptly via
<constant>SIGKILL
</constant>. For
627 a list of valid signals, see
<citerefentry
628 project='man-pages'
><refentrytitle>signal
</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
</para>
630 <xi:include href=
"version-info.xml" xpointer=
"v220"/></listitem>
634 <term><option>--notify-ready=
</option></term>
636 <listitem><para>Configures support for notifications from the container's init process.
637 <option>--notify-ready=
</option> takes a boolean (
<option>no
</option> and
<option>yes
</option>).
638 With option
<option>no
</option> systemd-nspawn notifies systemd
639 with a
<literal>READY=
1</literal> message when the init process is created.
640 With option
<option>yes
</option> systemd-nspawn waits for the
641 <literal>READY=
1</literal> message from the init process in the container
642 before sending its own to systemd. For more details about notifications
643 see
<citerefentry><refentrytitle>sd_notify
</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
</para>
645 <xi:include href=
"version-info.xml" xpointer=
"v231"/></listitem>
649 <term><option>--suppress-sync=
</option></term>
651 <listitem><para>Expects a boolean argument. If true, turns off any form of on-disk file system
652 synchronization for the container payload. This means all system calls such as
<citerefentry
653 project='man-pages'
><refentrytitle>sync
</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
654 <function>fsync()
</function>,
<function>syncfs()
</function>, … will execute no operation, and the
655 <constant>O_SYNC
</constant>/
<constant>O_DSYNC
</constant> flags to
<citerefentry
656 project='man-pages'
><refentrytitle>open
</refentrytitle><manvolnum>2</manvolnum></citerefentry> and
657 related calls will be made unavailable. This is potentially dangerous, as assumed data integrity
658 guarantees to the container payload are not actually enforced (i.e. data assumed to have been written
659 to disk might be lost if the system is shut down abnormally). However, this can dramatically improve
660 container runtime performance – as long as these guarantees are not required or desirable, for
661 example because any data written by the container is of temporary, redundant nature, or just an
662 intermediary artifact that will be further processed and finalized by a later step in a
663 pipeline. Defaults to false.
</para>
665 <xi:include href=
"version-info.xml" xpointer=
"v250"/></listitem>
669 </refsect2><refsect2>
670 <title>System Identity Options
</title>
674 <term><option>-M
</option></term>
675 <term><option>--machine=
</option></term>
677 <listitem><para>Sets the machine name for this container. This
678 name may be used to identify this container during its runtime
679 (for example in tools like
680 <citerefentry><refentrytitle>machinectl
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
681 and similar), and is used to initialize the container's
682 hostname (which the container can choose to override,
683 however). If not specified, the last component of the root
684 directory path of the container is used, possibly suffixed
685 with a random identifier in case
<option>--ephemeral
</option>
686 mode is selected. If the root directory selected is the host's
687 root directory the host's hostname is used as default
690 <xi:include href=
"version-info.xml" xpointer=
"v202"/></listitem>
694 <term><option>--hostname=
</option></term>
696 <listitem><para>Controls the hostname to set within the container, if different from the machine name. Expects
697 a valid hostname as argument. If this option is used, the kernel hostname of the container will be set to this
698 value, otherwise it will be initialized to the machine name as controlled by the
<option>--machine=
</option>
699 option described above. The machine name is used for various aspect of identification of the container from the
700 outside, the kernel hostname configurable with this option is useful for the container to identify itself from
701 the inside. It is usually a good idea to keep both forms of identification synchronized, in order to avoid
702 confusion. It is hence recommended to avoid usage of this option, and use
<option>--machine=
</option>
703 exclusively. Note that regardless whether the container's hostname is initialized from the name set with
704 <option>--hostname=
</option> or the one set with
<option>--machine=
</option>, the container can later override
705 its kernel hostname freely on its own as well.
</para>
707 <xi:include href=
"version-info.xml" xpointer=
"v239"/>
712 <term><option>--uuid=
</option></term>
714 <listitem><para>Set the specified UUID for the container. The
715 init system will initialize
716 <filename>/etc/machine-id
</filename> from this if this file is
717 not set yet. Note that this option takes effect only if
718 <filename>/etc/machine-id
</filename> in the container is
719 unpopulated.
</para></listitem>
723 </refsect2><refsect2>
724 <title>Property Options
</title>
728 <term><option>-S
</option></term>
729 <term><option>--slice=
</option></term>
731 <listitem><para>Make the container part of the specified slice, instead of the default
732 <filename>machine.slice
</filename>. This applies only if the machine is run in its own scope unit, i.e. if
733 <option>--keep-unit
</option> isn't used.
</para>
735 <xi:include href=
"version-info.xml" xpointer=
"v206"/>
740 <term><option>--property=
</option></term>
742 <listitem><para>Set a unit property on the scope unit to register for the machine. This applies only if the
743 machine is run in its own scope unit, i.e. if
<option>--keep-unit
</option> isn't used. Takes unit property
744 assignments in the same format as
<command>systemctl set-property
</command>. This is useful to set memory
745 limits and similar for the container.
</para>
747 <xi:include href=
"version-info.xml" xpointer=
"v220"/>
752 <term><option>--register=
</option></term>
754 <listitem><para>Controls whether the container is registered with
755 <citerefentry><refentrytitle>systemd-machined
</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Takes a
756 boolean argument, which defaults to
<literal>yes
</literal>. This option should be enabled when the container
757 runs a full Operating System (more specifically: a system and service manager as PID
1), and is useful to
758 ensure that the container is accessible via
759 <citerefentry><refentrytitle>machinectl
</refentrytitle><manvolnum>1</manvolnum></citerefentry> and shown by
760 tools such as
<citerefentry
761 project='man-pages'
><refentrytitle>ps
</refentrytitle><manvolnum>1</manvolnum></citerefentry>. If the container
762 does not run a service manager, it is recommended to set this option to
763 <literal>no
</literal>.
</para>
765 <xi:include href=
"version-info.xml" xpointer=
"v209"/></listitem>
769 <term><option>--keep-unit
</option></term>
771 <listitem><para>Instead of creating a transient scope unit to run the container in, simply use the service or
772 scope unit
<command>systemd-nspawn
</command> has been invoked in. If
<option>--register=yes
</option> is set
773 this unit is registered with
774 <citerefentry><refentrytitle>systemd-machined
</refentrytitle><manvolnum>8</manvolnum></citerefentry>. This
775 switch should be used if
<command>systemd-nspawn
</command> is invoked from within a service unit, and the
776 service unit's sole purpose is to run a single
<command>systemd-nspawn
</command> container. This option is not
777 available if run from a user session.
</para>
778 <para>Note that passing
<option>--keep-unit
</option> disables the effect of
<option>--slice=
</option> and
779 <option>--property=
</option>. Use
<option>--keep-unit
</option> and
<option>--register=no
</option> in
780 combination to disable any kind of unit allocation or registration with
781 <command>systemd-machined
</command>.
</para>
783 <xi:include href=
"version-info.xml" xpointer=
"v209"/></listitem>
787 </refsect2><refsect2>
788 <title>User Namespacing Options
</title>
792 <term><option>--private-users=
</option></term>
794 <listitem><para>Controls user namespacing. If enabled, the container will run with its own private set of UNIX
795 user and group ids (UIDs and GIDs). This involves mapping the private UIDs/GIDs used in the container (starting
796 with the container's root user
0 and up) to a range of UIDs/GIDs on the host that are not used for other
797 purposes (usually in the range beyond the host's UID/GID
65536). The parameter may be specified as follows:
</para>
800 <listitem><para>If one or two colon-separated numbers are specified, user namespacing is turned on. The first
801 parameter specifies the first host UID/GID to assign to the container, the second parameter specifies the
802 number of host UIDs/GIDs to assign to the container. If the second parameter is omitted,
65536 UIDs/GIDs are
803 assigned.
</para></listitem>
805 <listitem><para>If the parameter is
<literal>yes
</literal>, user namespacing is turned on. The
806 UID/GID range to use is determined automatically from the file ownership of the root directory of
807 the container's directory tree. To use this option, make sure to prepare the directory tree in
808 advance, and ensure that all files and directories in it are owned by UIDs/GIDs in the range you'd
809 like to use. Also, make sure that used file ACLs exclusively reference UIDs/GIDs in the appropriate
810 range. In this mode, the number of UIDs/GIDs assigned to the container is
65536, and the owner
811 UID/GID of the root directory must be a multiple of
65536.
</para></listitem>
813 <listitem><para>If the parameter is
<literal>no
</literal>, user namespacing is turned off. This is
817 <listitem><para>If the parameter is
<literal>identity
</literal>, user namespacing is employed with
818 an identity mapping for the first
65536 UIDs/GIDs. This is mostly equivalent to
819 <option>--private-users=
0:
65536</option>. While it does not provide UID/GID isolation, since all
820 host and container UIDs/GIDs are chosen identically it does provide process capability isolation,
821 and hence is often a good choice if proper user namespacing with distinct UID maps is not
822 appropriate.
</para></listitem>
824 <listitem><para>The special value
<literal>pick
</literal> turns on user namespacing. In this case
825 the UID/GID range is automatically chosen. As first step, the file owner UID/GID of the root
826 directory of the container's directory tree is read, and it is checked that no other container is
827 currently using it. If this check is successful, the UID/GID range determined this way is used,
828 similarly to the behavior if
<literal>yes
</literal> is specified. If the check is not successful
829 (and thus the UID/GID range indicated in the root directory's file owner is already used elsewhere)
830 a new – currently unused – UID/GID range of
65536 UIDs/GIDs is randomly chosen between the host
831 UID/GIDs of
524288 and
1878982656, always starting at a multiple of
65536, and, if possible,
832 consistently hashed from the machine name. This setting implies
833 <option>--private-users-ownership=auto
</option> (see below), which possibly has the effect that the
834 files and directories in the container's directory tree will be owned by the appropriate users of
835 the range picked. Using this option makes user namespace behavior fully automatic. Note that the
836 first invocation of a previously unused container image might result in picking a new UID/GID range
837 for it, and thus in the (possibly expensive) file ownership adjustment operation. However,
838 subsequent invocations of the container will be cheap (unless of course the picked UID/GID range is
839 assigned to a different use by then).
</para></listitem>
842 <para>It is recommended to assign at least
65536 UIDs/GIDs to each container, so that the usable UID/GID range in the
843 container covers
16 bit. For best security, do not assign overlapping UID/GID ranges to multiple containers. It is
844 hence a good idea to use the upper
16 bit of the host
32-bit UIDs/GIDs as container identifier, while the lower
16
845 bit encode the container UID/GID used. This is in fact the behavior enforced by the
846 <option>--private-users=pick
</option> option.
</para>
848 <para>When user namespaces are used, the GID range assigned to each container is always chosen identical to the
851 <para>In most cases, using
<option>--private-users=pick
</option> is the recommended option as it enhances
852 container security massively and operates fully automatically in most cases.
</para>
854 <para>Note that the picked UID/GID range is not written to
<filename>/etc/passwd
</filename> or
855 <filename>/etc/group
</filename>. In fact, the allocation of the range is not stored persistently anywhere,
856 except in the file ownership of the files and directories of the container.
</para>
858 <para>Note that when user namespacing is used file ownership on disk reflects this, and all of the container's
859 files and directories are owned by the container's effective user and group IDs. This means that copying files
860 from and to the container image requires correction of the numeric UID/GID values, according to the UID/GID
861 shift applied.
</para>
863 <xi:include href=
"version-info.xml" xpointer=
"v220"/></listitem>
867 <term><option>--private-users-ownership=
</option></term>
869 <listitem><para>Controls how to adjust the container image's UIDs and GIDs to match the UID/GID range
870 chosen with
<option>--private-users=
</option>, see above. Takes one of
<literal>off
</literal> (to
871 leave the image as is),
<literal>chown
</literal> (to recursively
<function>chown()
</function> the
872 container's directory tree as needed),
<literal>map
</literal> (in order to use transparent ID mapping
873 mounts) or
<literal>auto
</literal> for automatically using
<literal>map
</literal> where available and
874 <literal>chown
</literal> where not.
</para>
876 <para>If
<literal>chown
</literal> is selected, all files and directories in the container's directory
877 tree will be adjusted so that they are owned by the appropriate UIDs/GIDs selected for the container
878 (see above). This operation is potentially expensive, as it involves iterating through the full
879 directory tree of the container. Besides actual file ownership, file ACLs are adjusted as
882 <para>Typically
<literal>map
</literal> is the best choice, since it transparently maps UIDs/GIDs in
883 memory as needed without modifying the image, and without requiring an expensive recursive adjustment
884 operation. However, it is not available for all file systems, currently.
</para>
886 <para>The
<option>--private-users-ownership=auto
</option> option is implied if
887 <option>--private-users=pick
</option> is used. This option has no effect if user namespacing is not
890 <xi:include href=
"version-info.xml" xpointer=
"v230"/></listitem>
894 <term><option>-U
</option></term>
896 <listitem><para>If the kernel supports the user namespaces feature, equivalent to
897 <option>--private-users=pick --private-users-ownership=auto
</option>, otherwise equivalent to
898 <option>--private-users=no
</option>.
</para>
900 <para>Note that
<option>-U
</option> is the default if the
901 <filename>systemd-nspawn@.service
</filename> template unit file is used.
</para>
903 <para>Note: it is possible to undo the effect of
<option>--private-users-ownership=chown
</option> (or
904 <option>-U
</option>) on the file system by redoing the operation with the first UID of
0:
</para>
906 <programlisting>systemd-nspawn … --private-users=
0 --private-users-ownership=chown
</programlisting>
908 <xi:include href=
"version-info.xml" xpointer=
"v230"/>
914 </refsect2><refsect2>
915 <title>Networking Options
</title>
920 <term><option>--private-network
</option></term>
922 <listitem><para>Disconnect networking of the container from
923 the host. This makes all network interfaces unavailable in the
924 container, with the exception of the loopback device and those
925 specified with
<option>--network-interface=
</option> and
926 configured with
<option>--network-veth
</option>. If this
927 option is specified, the
<constant>CAP_NET_ADMIN
</constant> capability will be
928 added to the set of capabilities the container retains. The
929 latter may be disabled by using
<option>--drop-capability=
</option>.
930 If this option is not specified (or implied by one of the options
931 listed below), the container will have full access to the host network.
936 <term><option>--network-interface=
</option></term>
938 <listitem><para>Assign the specified network interface to the container. Either takes a single
939 interface name, referencing the name on the host, or a colon-separated pair of interfaces, in which
940 case the first one references the name on the host, and the second one the name in the container.
941 When the container terminates, the interface is moved back to the calling namespace and renamed to
942 its original name. Note that
<option>--network-interface=
</option> implies
943 <option>--private-network
</option>. This option may be used more than once to add multiple network
944 interfaces to the container.
</para>
946 <para>Note that any network interface specified this way must already exist at the time the container
947 is started. If the container shall be started automatically at boot via a
948 <filename>systemd-nspawn@.service
</filename> unit file instance, it might hence make sense to add a
949 unit file drop-in to the service instance
950 (e.g.
<filename>/etc/systemd/system/systemd-nspawn@foobar.service.d/
50-network.conf
</filename>) with
951 contents like the following:
</para>
953 <programlisting>[Unit]
954 Wants=sys-subsystem-net-devices-ens1.device
955 After=sys-subsystem-net-devices-ens1.device
</programlisting>
957 <para>This will make sure that activation of the container service will be delayed until the
958 <literal>ens1
</literal> network interface has shown up. This is required since hardware probing is
959 fully asynchronous, and network interfaces might be discovered only later during the boot process,
960 after the container would normally be started without these explicit dependencies.
</para>
962 <xi:include href=
"version-info.xml" xpointer=
"v209"/>
967 <term><option>--network-macvlan=
</option></term>
969 <listitem><para>Create a
<literal>macvlan
</literal> interface of the specified Ethernet network
970 interface and add it to the container. Either takes a single interface name, referencing the name
971 on the host, or a colon-separated pair of interfaces, in which case the first one references the name
972 on the host, and the second one the name in the container. A
<literal>macvlan
</literal> interface is
973 a virtual interface that adds a second MAC address to an existing physical Ethernet link. If the
974 container interface name is not defined, the interface in the container will be named after the
975 interface on the host, prefixed with
<literal>mv-
</literal>. Note that
976 <option>--network-macvlan=
</option> implies
<option>--private-network
</option>. This option may be
977 used more than once to add multiple network interfaces to the container.
</para>
979 <para>As with
<option>--network-interface=
</option>, the underlying Ethernet network interface must
980 already exist at the time the container is started, and thus similar unit file drop-ins as described
981 above might be useful.
</para>
983 <xi:include href=
"version-info.xml" xpointer=
"v211"/></listitem>
987 <term><option>--network-ipvlan=
</option></term>
989 <listitem><para>Create an
<literal>ipvlan
</literal> interface of the specified Ethernet network
990 interface and add it to the container. Either takes a single interface name, referencing the name on
991 the host, or a colon-separated pair of interfaces, in which case the first one references the name
992 on the host, and the second one the name in the container. An
<literal>ipvlan
</literal> interface is
994 similar to a
<literal>macvlan
</literal> interface, which uses the same MAC address as the underlying
995 interface. If the container interface name is not defined, the interface in the container will be
996 named after the interface on the host, prefixed
997 with
<literal>iv-
</literal>. Note that
<option>--network-ipvlan=
</option> implies
998 <option>--private-network
</option>. This option may be used more than once to add multiple network
999 interfaces to the container.
</para>
1001 <para>As with
<option>--network-interface=
</option>, the underlying Ethernet network interface must
1002 already exist at the time the container is started, and thus similar unit file drop-ins as described
1003 above might be useful.
</para>
1005 <xi:include href=
"version-info.xml" xpointer=
"v219"/></listitem>
1009 <term><option>-n
</option></term>
1010 <term><option>--network-veth
</option></term>
1012 <listitem><para>Create a virtual Ethernet link (
<literal>veth
</literal>) between host and container. The host
1013 side of the Ethernet link will be available as a network interface named after the container's name (as
1014 specified with
<option>--machine=
</option>), prefixed with
<literal>ve-
</literal>. The container side of the
1015 Ethernet link will be named
<literal>host0
</literal>. The
<option>--network-veth
</option> option implies
1016 <option>--private-network
</option>.
</para>
1019 <citerefentry><refentrytitle>systemd-networkd.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry>
1020 includes by default a network file
<filename>/usr/lib/systemd/network/
80-container-ve.network
</filename>
1021 matching the host-side interfaces created this way, which contains settings to enable automatic address
1022 provisioning on the created virtual link via DHCP, as well as automatic IP routing onto the host's external
1023 network interfaces. It also contains
<filename>/usr/lib/systemd/network/
80-container-host0.network
</filename>
1024 matching the container-side interface created this way, containing settings to enable client side address
1025 assignment via DHCP. In case
<filename>systemd-networkd
</filename> is running on both the host and inside the
1026 container, automatic IP communication from the container to the host is thus available, with further
1027 connectivity to the external network.
</para>
1029 <para>Note that
<option>--network-veth
</option> is the default if the
1030 <filename>systemd-nspawn@.service
</filename> template unit file is used.
</para>
1032 <para>Note that on Linux network interface names may have a length of
15 characters at maximum, while
1033 container names may have a length up to
64 characters. As this option derives the host-side interface
1034 name from the container name the name is possibly truncated. Thus, care needs to be taken to ensure
1035 that interface names remain unique in this case, or even better container names are generally not
1036 chosen longer than
12 characters, to avoid the truncation. If the name is truncated,
1037 <command>systemd-nspawn
</command> will automatically append a
4-digit hash value to the name to
1038 reduce the chance of collisions. However, the hash algorithm is not collision-free. (See
1039 <citerefentry><refentrytitle>systemd.net-naming-scheme
</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1040 for details on older naming algorithms for this interface). Alternatively, the
1041 <option>--network-veth-extra=
</option> option may be used, which allows free configuration of the
1042 host-side interface name independently of the container name — but might require a bit more
1043 additional configuration in case bridging in a fashion similar to
<option>--network-bridge=
</option>
1046 <xi:include href=
"version-info.xml" xpointer=
"v209"/>
1051 <term><option>--network-veth-extra=
</option></term>
1053 <listitem><para>Adds an additional virtual Ethernet link
1054 between host and container. Takes a colon-separated pair of
1055 host interface name and container interface name. The latter
1056 may be omitted in which case the container and host sides will
1057 be assigned the same name. This switch is independent of
1058 <option>--network-veth
</option>, and — in contrast — may be
1059 used multiple times, and allows configuration of the network
1060 interface names. Note that
<option>--network-bridge=
</option>
1061 has no effect on interfaces created with
1062 <option>--network-veth-extra=
</option>.
</para>
1064 <xi:include href=
"version-info.xml" xpointer=
"v228"/></listitem>
1068 <term><option>--network-bridge=
</option></term>
1070 <listitem><para>Adds the host side of the Ethernet link created with
<option>--network-veth
</option>
1071 to the specified Ethernet bridge interface. Expects a valid network interface name of a bridge device
1072 as argument. Note that
<option>--network-bridge=
</option> implies
<option>--network-veth
</option>. If
1073 this option is used, the host side of the Ethernet link will use the
<literal>vb-
</literal> prefix
1074 instead of
<literal>ve-
</literal>. Regardless of the used naming prefix the same network interface
1075 name length limits imposed by Linux apply, along with the complications this creates (for details see
1078 <para>As with
<option>--network-interface=
</option>, the underlying bridge network interface must
1079 already exist at the time the container is started, and thus similar unit file drop-ins as described
1080 above might be useful.
</para>
1082 <xi:include href=
"version-info.xml" xpointer=
"v209"/></listitem>
1086 <term><option>--network-zone=
</option></term>
1088 <listitem><para>Creates a virtual Ethernet link (
<literal>veth
</literal>) to the container and adds it to an
1089 automatically managed Ethernet bridge interface. The bridge interface is named after the passed argument,
1090 prefixed with
<literal>vz-
</literal>. The bridge interface is automatically created when the first container
1091 configured for its name is started, and is automatically removed when the last container configured for its
1092 name exits. Hence, each bridge interface configured this way exists only as long as there's at least one
1093 container referencing it running. This option is very similar to
<option>--network-bridge=
</option>, besides
1094 this automatic creation/removal of the bridge device.
</para>
1096 <para>This setting makes it easy to place multiple related containers on a common, virtual Ethernet-based
1097 broadcast domain, here called a
"zone". Each container may only be part of one zone, but each zone may contain
1098 any number of containers. Each zone is referenced by its name. Names may be chosen freely (as long as they form
1099 valid network interface names when prefixed with
<literal>vz-
</literal>), and it is sufficient to pass the same
1100 name to the
<option>--network-zone=
</option> switch of the various concurrently running containers to join
1101 them in one zone.
</para>
1104 <citerefentry><refentrytitle>systemd-networkd.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry>
1105 includes by default a network file
<filename>/usr/lib/systemd/network/
80-container-vz.network
</filename>
1106 matching the bridge interfaces created this way, which contains settings to enable automatic address
1107 provisioning on the created virtual network via DHCP, as well as automatic IP routing onto the host's external
1108 network interfaces. Using
<option>--network-zone=
</option> is hence in most cases fully automatic and
1109 sufficient to connect multiple local containers in a joined broadcast domain to the host, with further
1110 connectivity to the external network.
</para>
1112 <xi:include href=
"version-info.xml" xpointer=
"v230"/>
1117 <term><option>--network-namespace-path=
</option></term>
1119 <listitem><para>Takes the path to a file representing a kernel
1120 network namespace that the container shall run in. The specified path
1121 should refer to a (possibly bind-mounted) network namespace file, as
1122 exposed by the kernel below
<filename>/proc/$PID/ns/net
</filename>.
1123 This makes the container enter the given network namespace. One of the
1124 typical use cases is to give a network namespace under
1125 <filename>/run/netns
</filename> created by
<citerefentry
1126 project='man-pages'
><refentrytitle>ip-netns
</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1127 for example,
<option>--network-namespace-path=/run/netns/foo
</option>.
1128 Note that this option cannot be used together with other
1129 network-related options, such as
<option>--private-network
</option>
1130 or
<option>--network-interface=
</option>.
</para>
1132 <xi:include href=
"version-info.xml" xpointer=
"v236"/></listitem>
1136 <term><option>-p
</option></term>
1137 <term><option>--port=
</option></term>
1139 <listitem><para>If private networking is enabled, maps an IP
1140 port on the host onto an IP port on the container. Takes a
1141 protocol specifier (either
<literal>tcp
</literal> or
1142 <literal>udp
</literal>), separated by a colon from a host port
1143 number in the range
1 to
65535, separated by a colon from a
1144 container port number in the range from
1 to
65535. The
1145 protocol specifier and its separating colon may be omitted, in
1146 which case
<literal>tcp
</literal> is assumed. The container
1147 port number and its colon may be omitted, in which case the
1148 same port as the host port is implied. This option is only
1149 supported if private networking is used, such as with
1150 <option>--network-veth
</option>,
<option>--network-zone=
</option>
1151 <option>--network-bridge=
</option>.
</para>
1153 <xi:include href=
"version-info.xml" xpointer=
"v219"/></listitem>
1157 </refsect2><refsect2>
1158 <title>Security Options
</title>
1162 <term><option>--capability=
</option></term>
1164 <listitem><para>List one or more additional capabilities to grant the container. Takes a
1165 comma-separated list of capability names, see
<citerefentry
1166 project='man-pages'
><refentrytitle>capabilities
</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1167 for more information. Note that the following capabilities will be granted in any way:
1168 <constant>CAP_AUDIT_CONTROL
</constant>,
<constant>CAP_AUDIT_WRITE
</constant>,
1169 <constant>CAP_CHOWN
</constant>,
<constant>CAP_DAC_OVERRIDE
</constant>,
1170 <constant>CAP_DAC_READ_SEARCH
</constant>,
<constant>CAP_FOWNER
</constant>,
1171 <constant>CAP_FSETID
</constant>,
<constant>CAP_IPC_OWNER
</constant>,
<constant>CAP_KILL
</constant>,
1172 <constant>CAP_LEASE
</constant>,
<constant>CAP_LINUX_IMMUTABLE
</constant>,
1173 <constant>CAP_MKNOD
</constant>,
<constant>CAP_NET_BIND_SERVICE
</constant>,
1174 <constant>CAP_NET_BROADCAST
</constant>,
<constant>CAP_NET_RAW
</constant>,
1175 <constant>CAP_SETFCAP
</constant>,
<constant>CAP_SETGID
</constant>,
<constant>CAP_SETPCAP
</constant>,
1176 <constant>CAP_SETUID
</constant>,
<constant>CAP_SYS_ADMIN
</constant>,
1177 <constant>CAP_SYS_BOOT
</constant>,
<constant>CAP_SYS_CHROOT
</constant>,
1178 <constant>CAP_SYS_NICE
</constant>,
<constant>CAP_SYS_PTRACE
</constant>,
1179 <constant>CAP_SYS_RESOURCE
</constant>,
<constant>CAP_SYS_TTY_CONFIG
</constant>. Also
1180 <constant>CAP_NET_ADMIN
</constant> is retained if
<option>--private-network
</option> is specified.
1181 If the special value
<literal>all
</literal> is passed, all capabilities are retained.
</para>
1183 <para>If the special value of
<literal>help
</literal> is passed, the program will print known
1184 capability names and exit.
</para>
1186 <para>This option sets the bounding set of capabilities which
1187 also limits the ambient capabilities as given with the
1188 <option>--ambient-capability=
</option>.
</para>
1190 <xi:include href=
"version-info.xml" xpointer=
"v186"/></listitem>
1194 <term><option>--drop-capability=
</option></term>
1196 <listitem><para>Specify one or more additional capabilities to
1197 drop for the container. This allows running the container with
1198 fewer capabilities than the default (see
1201 <para>If the special value of
<literal>help
</literal> is passed, the program will print known
1202 capability names and exit.
</para>
1204 <para>This option sets the bounding set of capabilities which
1205 also limits the ambient capabilities as given with the
1206 <option>--ambient-capability=
</option>.
</para>
1208 <xi:include href=
"version-info.xml" xpointer=
"v209"/></listitem>
1212 <term><option>--ambient-capability=
</option></term>
1214 <listitem><para>Specify one or more additional capabilities to
1215 pass in the inheritable and ambient set to the program started
1216 within the container. The value
<literal>all
</literal> is not
1217 supported for this setting.
</para>
1219 <para>All capabilities specified here must be in the set
1220 allowed with the
<option>--capability=
</option> and
1221 <option>--drop-capability=
</option> options. Otherwise, an
1222 error message will be shown.
</para>
1224 <para>This option cannot be combined with the boot mode of the
1225 container (as requested via
<option>--boot
</option>).
</para>
1227 <para>If the special value of
<literal>help
</literal> is
1228 passed, the program will print known capability names and
1231 <xi:include href=
"version-info.xml" xpointer=
"v248"/></listitem>
1235 <term><option>--no-new-privileges=
</option></term>
1237 <listitem><para>Takes a boolean argument. Specifies the value of the
1238 <constant>PR_SET_NO_NEW_PRIVS
</constant> flag for the container payload. Defaults to off. When turned
1239 on the payload code of the container cannot acquire new privileges, i.e. the
"setuid" file bit as
1240 well as file system capabilities will not have an effect anymore. See
<citerefentry
1241 project='man-pages'
><refentrytitle>prctl
</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
1242 details about this flag.
</para>
1244 <xi:include href=
"version-info.xml" xpointer=
"v239"/></listitem>
1248 <term><option>--system-call-filter=
</option></term> <listitem><para>Alter the system call filter
1249 applied to containers. Takes a space-separated list of system call names or group names (the latter
1250 prefixed with
<literal>@
</literal>, as listed by the
<command>syscall-filter
</command> command of
1251 <citerefentry><refentrytitle>systemd-analyze
</refentrytitle><manvolnum>1</manvolnum></citerefentry>). Passed
1252 system calls will be permitted. The list may optionally be prefixed by
<literal>~
</literal>, in which
1253 case all listed system calls are prohibited. If this command line option is used multiple times the
1254 configured lists are combined. If both a positive and a negative list (that is one system call list
1255 without and one with the
<literal>~
</literal> prefix) are configured, the negative list takes
1256 precedence over the positive list. Note that
<command>systemd-nspawn
</command> always implements a
1257 system call allow list (as opposed to a deny list!), and this command line option hence adds or
1258 removes entries from the default allow list, depending on the
<literal>~
</literal> prefix. Note that
1259 the applied system call filter is also altered implicitly if additional capabilities are passed using
1260 the
<command>--capabilities=
</command>.
</para>
1262 <xi:include href=
"version-info.xml" xpointer=
"v235"/></listitem>
1266 <term><option>-Z
</option></term>
1267 <term><option>--selinux-context=
</option></term>
1269 <listitem><para>Sets the SELinux security context to be used
1270 to label processes in the container.
</para>
1272 <xi:include href=
"version-info.xml" xpointer=
"v209"/>
1277 <term><option>-L
</option></term>
1278 <term><option>--selinux-apifs-context=
</option></term>
1280 <listitem><para>Sets the SELinux security context to be used
1281 to label files in the virtual API file systems in the
1284 <xi:include href=
"version-info.xml" xpointer=
"v209"/>
1289 </refsect2><refsect2>
1290 <title>Resource Options
</title>
1295 <term><option>--rlimit=
</option></term>
1297 <listitem><para>Sets the specified POSIX resource limit for the container payload. Expects an assignment of the
1299 <literal><replaceable>LIMIT
</replaceable>=
<replaceable>SOFT
</replaceable>:
<replaceable>HARD
</replaceable></literal>
1300 or
<literal><replaceable>LIMIT
</replaceable>=
<replaceable>VALUE
</replaceable></literal>, where
1301 <replaceable>LIMIT
</replaceable> should refer to a resource limit type, such as
1302 <constant>RLIMIT_NOFILE
</constant> or
<constant>RLIMIT_NICE
</constant>. The
<replaceable>SOFT
</replaceable> and
1303 <replaceable>HARD
</replaceable> fields should refer to the numeric soft and hard resource limit values. If the
1304 second form is used,
<replaceable>VALUE
</replaceable> may specify a value that is used both as soft and hard
1305 limit. In place of a numeric value the special string
<literal>infinity
</literal> may be used to turn off
1306 resource limiting for the specific type of resource. This command line option may be used multiple times to
1307 control limits on multiple limit types. If used multiple times for the same limit type, the last use
1308 wins. For details about resource limits see
<citerefentry
1309 project='man-pages'
><refentrytitle>setrlimit
</refentrytitle><manvolnum>2</manvolnum></citerefentry>. By default
1310 resource limits for the container's init process (PID
1) are set to the same values the Linux kernel originally
1311 passed to the host init system. Note that some resource limits are enforced on resources counted per user, in
1312 particular
<constant>RLIMIT_NPROC
</constant>. This means that unless user namespacing is deployed
1313 (i.e.
<option>--private-users=
</option> is used, see above), any limits set will be applied to the resource
1314 usage of the same user on all local containers as well as the host. This means particular care needs to be
1315 taken with these limits as they might be triggered by possibly less trusted code. Example:
1316 <literal>--rlimit=RLIMIT_NOFILE=
8192:
16384</literal>.
</para>
1318 <xi:include href=
"version-info.xml" xpointer=
"v239"/></listitem>
1322 <term><option>--oom-score-adjust=
</option></term>
1324 <listitem><para>Changes the OOM (
"Out Of Memory") score adjustment value for the container payload. This controls
1325 <filename>/proc/self/oom_score_adj
</filename> which influences the preference with which this container is
1326 terminated when memory becomes scarce. For details see
<citerefentry
1327 project='man-pages'
><refentrytitle>proc
</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Takes an
1328 integer in the range -
1000…
1000.
</para>
1330 <xi:include href=
"version-info.xml" xpointer=
"v239"/></listitem>
1334 <term><option>--cpu-affinity=
</option></term>
1336 <listitem><para>Controls the CPU affinity of the container payload. Takes a comma separated list of CPU numbers
1337 or number ranges (the latter's start and end value separated by dashes). See
<citerefentry
1338 project='man-pages'
><refentrytitle>sched_setaffinity
</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
1341 <xi:include href=
"version-info.xml" xpointer=
"v239"/></listitem>
1345 <term><option>--personality=
</option></term>
1347 <listitem><para>Control the architecture (
"personality")
1349 <citerefentry project='man-pages'
><refentrytitle>uname
</refentrytitle><manvolnum>2</manvolnum></citerefentry>
1350 in the container. Currently, only
<literal>x86
</literal> and
1351 <literal>x86-
64</literal> are supported. This is useful when
1352 running a
32-bit container on a
64-bit host. If this setting
1353 is not used, the personality reported in the container is the
1354 same as the one reported on the host.
</para>
1356 <xi:include href=
"version-info.xml" xpointer=
"v209"/></listitem>
1360 </refsect2><refsect2>
1361 <title>Integration Options
</title>
1365 <term><option>--resolv-conf=
</option></term>
1367 <listitem><para>Configures how
<filename>/etc/resolv.conf
</filename> inside of the container shall be
1368 handled (i.e. DNS configuration synchronization from host to container). Takes one of
1369 <literal>off
</literal>,
<literal>copy-host
</literal>,
<literal>copy-static
</literal>,
1370 <literal>copy-uplink
</literal>,
<literal>copy-stub
</literal>,
<literal>replace-host
</literal>,
1371 <literal>replace-static
</literal>,
<literal>replace-uplink
</literal>,
1372 <literal>replace-stub
</literal>,
<literal>bind-host
</literal>,
<literal>bind-static
</literal>,
1373 <literal>bind-uplink
</literal>,
<literal>bind-stub
</literal>,
<literal>delete
</literal> or
1374 <literal>auto
</literal>.
</para>
1376 <para>If set to
<literal>off
</literal> the
<filename>/etc/resolv.conf
</filename> file in the
1377 container is left as it is included in the image, and neither modified nor bind mounted over.
</para>
1379 <para>If set to
<literal>copy-host
</literal>, the
<filename>/etc/resolv.conf
</filename> file from the
1380 host is copied into the container, unless the file exists already and is not a regular file (e.g. a
1381 symlink). Similarly, if
<literal>replace-host
</literal> is used the file is copied, replacing any
1382 existing inode, including symlinks. Similarly, if
<literal>bind-host
</literal> is used, the file is
1383 bind mounted from the host into the container.
</para>
1385 <para>If set to
<literal>copy-static
</literal>,
<literal>replace-static
</literal> or
1386 <literal>bind-static
</literal> the static
<filename>resolv.conf
</filename> file supplied with
1387 <citerefentry><refentrytitle>systemd-resolved.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry>
1388 (specifically:
<filename>/usr/lib/systemd/resolv.conf
</filename>) is copied or bind mounted into the
1391 <para>If set to
<literal>copy-uplink
</literal>,
<literal>replace-uplink
</literal> or
1392 <literal>bind-uplink
</literal> the uplink
<filename>resolv.conf
</filename> file managed by
1393 <filename>systemd-resolved.service
</filename> (specifically:
1394 <filename>/run/systemd/resolve/resolv.conf
</filename>) is copied or bind mounted into the
1397 <para>If set to
<literal>copy-stub
</literal>,
<literal>replace-stub
</literal> or
1398 <literal>bind-stub
</literal> the stub
<filename>resolv.conf
</filename> file managed by
1399 <filename>systemd-resolved.service
</filename> (specifically:
1400 <filename>/run/systemd/resolve/stub-resolv.conf
</filename>) is copied or bind mounted into the
1403 <para>If set to
<literal>delete
</literal> the
<filename>/etc/resolv.conf
</filename> file in the
1404 container is deleted if it exists.
</para>
1406 <para>Finally, if set to
<literal>auto
</literal> the file is left as it is if private networking is
1407 turned on (see
<option>--private-network
</option>). Otherwise, if
1408 <filename>systemd-resolved.service
</filename> is running its stub
<filename>resolv.conf
</filename>
1409 file is used, and if not the host's
<filename>/etc/resolv.conf
</filename> file. In the latter cases
1410 the file is copied if the image is writable, and bind mounted otherwise.
</para>
1412 <para>It's recommended to use
<literal>copy-…
</literal> or
<literal>replace-…
</literal> if the
1413 container shall be able to make changes to the DNS configuration on its own, deviating from the
1414 host's settings. Otherwise
<literal>bind
</literal> is preferable, as it means direct changes to
1415 <filename>/etc/resolv.conf
</filename> in the container are not allowed, as it is a read-only bind
1416 mount (but note that if the container has enough privileges, it might simply go ahead and unmount the
1417 bind mount anyway). Note that both if the file is bind mounted and if it is copied no further
1418 propagation of configuration is generally done after the one-time early initialization (this is
1419 because the file is usually updated through copying and renaming). Defaults to
1420 <literal>auto
</literal>.
</para>
1422 <xi:include href=
"version-info.xml" xpointer=
"v239"/></listitem>
1426 <term><option>--timezone=
</option></term>
1428 <listitem><para>Configures how
<filename>/etc/localtime
</filename> inside of the container
1429 (i.e. local timezone synchronization from host to container) shall be handled. Takes one of
1430 <literal>off
</literal>,
<literal>copy
</literal>,
<literal>bind
</literal>,
<literal>symlink
</literal>,
1431 <literal>delete
</literal> or
<literal>auto
</literal>. If set to
<literal>off
</literal> the
1432 <filename>/etc/localtime
</filename> file in the container is left as it is included in the image, and
1433 neither modified nor bind mounted over. If set to
<literal>copy
</literal> the
1434 <filename>/etc/localtime
</filename> file of the host is copied into the container. Similarly, if
1435 <literal>bind
</literal> is used, the file is bind mounted from the host into the container. If set to
1436 <literal>symlink
</literal>, a symlink is created pointing from
<filename>/etc/localtime
</filename> in
1437 the container to the timezone file in the container that matches the timezone setting on the host. If
1438 set to
<literal>delete
</literal>, the file in the container is deleted, should it exist. If set to
1439 <literal>auto
</literal> and the
<filename>/etc/localtime
</filename> file of the host is a symlink,
1440 then
<literal>symlink
</literal> mode is used, and
<literal>copy
</literal> otherwise, except if the
1441 image is read-only in which case
<literal>bind
</literal> is used instead. Defaults to
1442 <literal>auto
</literal>.
</para>
1444 <xi:include href=
"version-info.xml" xpointer=
"v239"/></listitem>
1448 <term><option>--link-journal=
</option></term>
1450 <listitem><para>Control whether the container's journal shall
1451 be made visible to the host system. If enabled, allows viewing
1452 the container's journal files from the host (but not vice
1453 versa). Takes one of
<literal>no
</literal>,
1454 <literal>host
</literal>,
<literal>try-host
</literal>,
1455 <literal>guest
</literal>,
<literal>try-guest
</literal>,
1456 <literal>auto
</literal>. If
<literal>no
</literal>, the journal
1457 is not linked. If
<literal>host
</literal>, the journal files
1458 are stored on the host file system (beneath
1459 <filename>/var/log/journal/
<replaceable>machine-id
</replaceable></filename>)
1460 and the subdirectory is bind-mounted into the container at the
1461 same location. If
<literal>guest
</literal>, the journal files
1462 are stored on the guest file system (beneath
1463 <filename>/var/log/journal/
<replaceable>machine-id
</replaceable></filename>)
1464 and the subdirectory is symlinked into the host at the same
1465 location.
<literal>try-host
</literal> and
1466 <literal>try-guest
</literal> do the same but do not fail if
1467 the host does not have persistent journaling enabled, or if
1468 the container is in the
<option>--ephemeral
</option> mode. If
1469 <literal>auto
</literal> (the default), and the right
1470 subdirectory of
<filename>/var/log/journal
</filename> exists,
1471 it will be bind mounted into the container. If the
1472 subdirectory does not exist, no linking is performed.
1473 Effectively, booting a container once with
1474 <literal>guest
</literal> or
<literal>host
</literal> will link
1475 the journal persistently if further on the default of
1476 <literal>auto
</literal> is used.
</para>
1478 <para>Note that
<option>--link-journal=try-guest
</option> is the default if the
1479 <filename>systemd-nspawn@.service
</filename> template unit file is used.
</para>
1481 <xi:include href=
"version-info.xml" xpointer=
"v187"/></listitem>
1485 <term><option>-j
</option></term>
1487 <listitem><para>Equivalent to
1488 <option>--link-journal=try-guest
</option>.
</para>
1490 <xi:include href=
"version-info.xml" xpointer=
"v187"/></listitem>
1495 </refsect2><refsect2>
1496 <title>Mount Options
</title>
1501 <term><option>--bind=
</option></term>
1502 <term><option>--bind-ro=
</option></term>
1504 <listitem><para>Bind mount a file or directory from the host into the container. Takes one of: a path
1505 argument — in which case the specified path will be mounted from the host to the same path in the container, or
1506 a colon-separated pair of paths — in which case the first specified path is the source in the host, and the
1507 second path is the destination in the container, or a colon-separated triple of source path, destination path
1508 and mount options. The source path may optionally be prefixed with a
<literal>+
</literal> character. If so, the
1509 source path is taken relative to the image's root directory. This permits setting up bind mounts within the
1510 container image. The source path may be specified as empty string, in which case a temporary directory below
1511 the host's
<filename>/var/tmp/
</filename> directory is used. It is automatically removed when the container is
1512 shut down. If the source path is not absolute, it is resolved relative to the current working directory.
1513 The
<option>--bind-ro=
</option> option creates read-only bind mounts. Backslash escapes are interpreted,
1514 so
<literal>\:
</literal> may be used to embed colons in either path. This option may be specified
1515 multiple times for creating multiple independent bind mount points.
</para>
1517 <para>Mount options are comma-separated.
<option>rbind
</option> and
<option>norbind
</option> control whether
1518 to create a recursive or a regular bind mount. Defaults to
<option>rbind
</option>.
<option>noidmap
</option>,
1519 <option>idmap
</option>,
<option>rootidmap
</option> and
<option>owneridmap
</option> control ID mapping.
</para>
1521 <para>Using
<option>idmap
</option>,
<option>rootidmap
</option> or
<option>owneridmap
</option> requires support
1522 by the source filesystem for user/group ID mapped mounts. Defaults to
<option>noidmap
</option>. With
1523 <option>x
</option> being the container's UID range offset,
<option>y
</option> being the length of the
1524 container's UID range, and
<option>p
</option> being the owner UID of the bind mount source inode on the host:
1527 <listitem><para>If
<option>noidmap
</option> is used, any user
<option>z
</option> in the range
1528 <option>0 … y
</option> seen from inside of the container is mapped to
<option>x + z
</option> in the
1529 <option>x … x + y
</option> range on the host. Other host users are mapped to
1530 <option>nobody
</option> inside the container.
</para></listitem>
1532 <listitem><para>If
<option>idmap
</option> is used, any user
<option>z
</option> in the UID range
1533 <option>0 … y
</option> as seen from inside the container is mapped to the same
<option>z
</option>
1534 in the same
<option>0 … y
</option> range on the host. Other host users are mapped to
1535 <option>nobody
</option> inside the container.
</para></listitem>
1537 <listitem><para>If
<option>rootidmap
</option> is used, the user
<option>0</option> seen from inside
1538 of the container is mapped to
<option>p
</option> on the host. Other host users are mapped to
1539 <option>nobody
</option> inside the container.
</para></listitem>
1541 <listitem><para>If
<option>owneridmap
</option> is used, the owner of the target directory inside of the
1542 container is mapped to
<option>p
</option> on the host. Other host users are mapped to
1543 <option>nobody
</option> inside the container.
</para></listitem>
1544 </itemizedlist></para>
1546 <para>Whichever ID mapping option is used, the same mapping will be used for users and groups IDs. If
1547 <option>rootidmap
</option> or
<option>owneridmap
</option> are used, the group owning the bind mounted directory
1548 will have no effect.
</para>
1550 <para>Note that when this option is used in combination with
<option>--private-users
</option>, the resulting
1551 mount points will be owned by the
<constant>nobody
</constant> user. That's because the mount and its files and
1552 directories continue to be owned by the relevant host users and groups, which do not exist in the container,
1553 and thus show up under the wildcard UID
65534 (nobody). If such bind mounts are created, it is recommended to
1554 make them read-only, using
<option>--bind-ro=
</option>. Alternatively you can use the
"idmap" mount option to
1555 map the filesystem IDs.
</para>
1557 <xi:include href=
"version-info.xml" xpointer=
"v198"/></listitem>
1561 <term><option>--bind-user=
</option></term>
1563 <listitem><para>Binds the home directory of the specified user on the host into the container. Takes
1564 the name of an existing user on the host as argument. May be used multiple times to bind multiple
1565 users into the container. This does three things:
</para>
1568 <listitem><para>The user's home directory is bind mounted from the host into
1569 <filename>/run/host/home/
</filename>.
</para></listitem>
1571 <listitem><para>An additional UID/GID mapping is added that maps the host user's UID/GID to a
1572 container UID/GID, allocated from the
60514…
60577 range.
</para></listitem>
1574 <listitem><para>A JSON user and group record is generated in
<filename>/run/userdb/
</filename> that
1575 describes the mapped user. It contains a minimized representation of the host's user record,
1576 adjusted to the UID/GID and home directory path assigned to the user in the container. The
1577 <citerefentry><refentrytitle>nss-systemd
</refentrytitle><manvolnum>8</manvolnum></citerefentry>
1578 glibc NSS module will pick up these records from there and make them available in the container's
1579 user/group databases.
</para></listitem>
1582 <para>The combination of the three operations above ensures that it is possible to log into the
1583 container using the same account information as on the host. The user is only mapped transiently,
1584 while the container is running, and the mapping itself does not result in persistent changes to the
1585 container (except maybe for log messages generated at login time, and similar). Note that in
1586 particular the UID/GID assignment in the container is not made persistently. If the user is mapped
1587 transiently, it is best to not allow the user to make persistent changes to the container. If the
1588 user leaves files or directories owned by the user, and those UIDs/GIDs are reused during later
1589 container invocations (possibly with a different
<option>--bind-user=
</option> mapping), those files
1590 and directories will be accessible to the
"new" user.
</para>
1592 <para>The user/group record mapping only works if the container contains systemd
249 or newer, with
1593 <command>nss-systemd
</command> properly configured in
<filename>nsswitch.conf
</filename>. See
1594 <citerefentry><refentrytitle>nss-systemd
</refentrytitle><manvolnum>8</manvolnum></citerefentry> for
1597 <para>Note that the user record propagated from the host into the container will contain the UNIX
1598 password hash of the user, so that seamless logins in the container are possible. If the container is
1599 less trusted than the host it's hence important to use a strong UNIX password hash function
1600 (e.g. yescrypt or similar, with the
<literal>$y$
</literal> hash prefix).
</para>
1602 <para>When binding a user from the host into the container checks are executed to ensure that the
1603 username is not yet known in the container. Moreover, it is checked that the UID/GID allocated for it
1604 is not currently defined in the user/group databases of the container. Both checks directly access
1605 the container's
<filename>/etc/passwd
</filename> and
<filename>/etc/group
</filename>, and thus might
1606 not detect existing accounts in other databases.
</para>
1608 <para>This operation is only supported in combination with
1609 <option>--private-users=
</option>/
<option>-U
</option>.
</para>
1611 <xi:include href=
"version-info.xml" xpointer=
"v249"/></listitem>
1615 <term><option>--inaccessible=
</option></term>
1617 <listitem><para>Make the specified path inaccessible in the container. This over-mounts the specified path
1618 (which must exist in the container) with a file node of the same type that is empty and has the most
1619 restrictive access mode supported. This is an effective way to mask files, directories and other file system
1620 objects from the container payload. This option may be used more than once in case all specified paths are
1623 <xi:include href=
"version-info.xml" xpointer=
"v242"/></listitem>
1627 <term><option>--tmpfs=
</option></term>
1629 <listitem><para>Mount a tmpfs file system into the container. Takes a single absolute path argument that
1630 specifies where to mount the tmpfs instance to (in which case the directory access mode will be chosen as
0755,
1631 owned by root/root), or optionally a colon-separated pair of path and mount option string that is used for
1632 mounting (in which case the kernel default for access mode and owner will be chosen, unless otherwise
1633 specified). Backslash escapes are interpreted in the path, so
<literal>\:
</literal> may be used to embed colons
1636 <para>Note that this option cannot be used to replace the root file system of the container with a temporary
1637 file system. However, the
<option>--volatile=
</option> option described below provides similar
1638 functionality, with a focus on implementing stateless operating system images.
</para>
1640 <xi:include href=
"version-info.xml" xpointer=
"v214"/></listitem>
1644 <term><option>--overlay=
</option></term>
1645 <term><option>--overlay-ro=
</option></term>
1647 <listitem><para>Combine multiple directory trees into one overlay file system and mount it into the
1648 container. Takes a list of colon-separated paths to the directory trees to combine and the
1649 destination mount point.
</para>
1651 <para>Backslash escapes are interpreted in the paths, so
<literal>\:
</literal> may be used to embed
1652 colons in the paths.
</para>
1654 <para>If three or more paths are specified, then the last specified path is the destination mount
1655 point in the container, all paths specified before refer to directory trees on the host and are
1656 combined in the specified order into one overlay file system. The left-most path is hence the lowest
1657 directory tree, the second-to-last path the highest directory tree in the stacking order. If
1658 <option>--overlay-ro=
</option> is used instead of
<option>--overlay=
</option>, a read-only overlay
1659 file system is created. If a writable overlay file system is created, all changes made to it are
1660 written to the highest directory tree in the stacking order, i.e. the second-to-last specified.
1663 <para>If only two paths are specified, then the second specified path is used both as the top-level
1664 directory tree in the stacking order as seen from the host, as well as the mount point for the
1665 overlay file system in the container. At least two paths have to be specified.
</para>
1667 <para>The source paths may optionally be prefixed with
<literal>+
</literal> character. If so they are
1668 taken relative to the image's root directory. The uppermost source path may also be specified as an
1669 empty string, in which case a temporary directory below the host's
<filename>/var/tmp/
</filename> is
1670 used. The directory is removed automatically when the container is shut down. This behaviour is
1671 useful in order to make read-only container directories writable while the container is running. For
1672 example, use
<literal>--overlay=+/var::/var
</literal> in order to automatically overlay a writable
1673 temporary directory on a read-only
<filename>/var/
</filename> directory. If a source path is not
1674 absolute, it is resolved relative to the current working directory.
</para>
1676 <para>For details about overlay file systems, see
<ulink
1677 url=
"https://docs.kernel.org/filesystems/overlayfs.html">Overlay Filesystem
</ulink>.
1678 Note that the semantics of overlay file systems are substantially different from normal file systems,
1679 in particular regarding reported device and inode information. Device and inode information may
1680 change for a file while it is being written to, and processes might see out-of-date versions of files
1681 at times. Note that this switch automatically derives the
<literal>workdir=
</literal> mount option
1682 for the overlay file system from the top-level directory tree, making it a sibling of it. It is hence
1683 essential that the top-level directory tree is not a mount point itself (since the working directory
1684 must be on the same file system as the top-most directory tree). Also note that the
1685 <literal>lowerdir=
</literal> mount option receives the paths to stack in the opposite order of this
1688 <para>Note that this option cannot be used to replace the root file system of the container with an overlay
1689 file system. However, the
<option>--volatile=
</option> option described above provides similar functionality,
1690 with a focus on implementing stateless operating system images.
</para>
1692 <xi:include href=
"version-info.xml" xpointer=
"v220"/></listitem>
1698 <title>Input/Output Options
</title>
1702 <term><option>--console=
<replaceable>MODE
</replaceable></option></term>
1704 <listitem><para>Configures how to set up standard input, output and error output for the container
1705 payload, as well as the
<filename>/dev/console
</filename> device for the container. Takes one of
1706 <option>interactive
</option>,
<option>read-only
</option>,
<option>passive
</option>,
1707 <option>pipe
</option> or
<option>autopipe
</option>. If
<option>interactive
</option>, a pseudo-TTY is
1708 allocated and made available as
<filename>/dev/console
</filename> in the container. It is then
1709 bi-directionally connected to the standard input and output passed to
1710 <command>systemd-nspawn
</command>.
<option>read-only
</option> is similar but only the output of the
1711 container is propagated and no input from the caller is read. If
<option>passive
</option>, a pseudo
1712 TTY is allocated, but it is not connected anywhere. In
<option>pipe
</option> mode no pseudo TTY is
1713 allocated, but the standard input, output and error output file descriptors passed to
1714 <command>systemd-nspawn
</command> are passed on — as they are — to the container payload, see the
1715 following paragraph. Finally,
<option>autopipe
</option> mode operates like
1716 <option>interactive
</option> when
<command>systemd-nspawn
</command> is invoked on a terminal, and
1717 like
<option>pipe
</option> otherwise. Defaults to
<option>interactive
</option> if
1718 <command>systemd-nspawn
</command> is invoked from a terminal, and
<option>read-only
</option>
1721 <para>In
<option>pipe
</option> mode,
<filename>/dev/console
</filename> will not exist in the
1722 container. This means that the container payload generally cannot be a full init system as init
1723 systems tend to require
<filename>/dev/console
</filename> to be available. On the other hand, in this
1724 mode container invocations can be used within shell pipelines. This is because intermediary pseudo
1725 TTYs do not permit independent bidirectional propagation of the end-of-file (EOF) condition, which is
1726 necessary for shell pipelines to work correctly.
<emphasis>Note that the
<option>pipe
</option> mode
1727 should be used carefully
</emphasis>, as passing arbitrary file descriptors to less trusted container
1728 payloads might open up unwanted interfaces for access by the container payload. For example, if a
1729 passed file descriptor refers to a TTY of some form, APIs such as
<constant>TIOCSTI
</constant> may be
1730 used to synthesize input that might be used for escaping the container. Hence
<option>pipe
</option>
1731 mode should only be used if the payload is sufficiently trusted or when the standard
1732 input/output/error output file descriptors are known safe, for example pipes.
</para>
1734 <xi:include href=
"version-info.xml" xpointer=
"v242"/></listitem>
1738 <term><option>--pipe
</option></term>
1739 <term><option>-P
</option></term>
1741 <listitem><para>Equivalent to
<option>--console=pipe
</option>.
</para>
1743 <xi:include href=
"version-info.xml" xpointer=
"v242"/></listitem>
1747 <term><option>--background=
<replaceable>COLOR
</replaceable></option></term>
1749 <listitem><para>Change the terminal background color to the specified ANSI color as long as the
1750 container runs. The color specified should be an ANSI X3.64 SGR background color, i.e. strings such
1751 as
<literal>40</literal>,
<literal>41</literal>, …,
<literal>47</literal>,
<literal>48;
2;…
</literal>,
1752 <literal>48;
5;…
</literal>. See
<ulink
1753 url=
"https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Rendition)_parameters">ANSI
1754 Escape Code (Wikipedia)
</ulink> for details. Assign an empty string to disable any coloring.
</para>
1756 <xi:include href=
"version-info.xml" xpointer=
"v256"/>
1764 <title>Credentials
</title>
1768 <term><option>--load-credential=
<replaceable>ID
</replaceable>:
<replaceable>PATH
</replaceable></option></term>
1769 <term><option>--set-credential=
<replaceable>ID
</replaceable>:
<replaceable>VALUE
</replaceable></option></term>
1771 <listitem><para>Pass a credential to the container. These two options correspond to the
1772 <varname>LoadCredential=
</varname> and
<varname>SetCredential=
</varname> settings in unit files. See
1773 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
1774 details about these concepts, as well as the syntax of the option's arguments.
</para>
1776 <para>Note: when
<command>systemd-nspawn
</command> runs as systemd system service it can propagate
1777 the credentials it received via
<varname>LoadCredential=
</varname>/
<varname>SetCredential=
</varname>
1778 to the container payload. A systemd service manager running as PID
1 in the container can further
1779 propagate them to the services it itself starts. It is thus possible to easily propagate credentials
1780 from a parent service manager to a container manager service and from there into its payload. This
1781 can even be done recursively.
</para>
1783 <para>In order to embed binary data into the credential data for
<option>--set-credential=
</option>,
1784 use C-style escaping (i.e.
<literal>\n
</literal> to embed a newline, or
<literal>\x00
</literal> to
1785 embed a
<constant>NUL
</constant> byte). Note that the invoking shell might already apply unescaping
1786 once, hence this might require double escaping!
</para>
1789 <citerefentry><refentrytitle>systemd-sysusers.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry>
1791 <citerefentry><refentrytitle>systemd-firstboot
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1792 services read credentials configured this way for the purpose of configuring the container's root
1793 user's password and shell, as well as system locale, keymap and timezone during the first boot
1794 process of the container. This is particularly useful in combination with
1795 <option>--volatile=yes
</option> where every single boot appears as first boot, since configuration
1796 applied to
<filename>/etc/
</filename> is lost on container reboot cycles. See the respective man
1797 pages for details. Example:
</para>
1799 <programlisting># systemd-nspawn -i image.raw \
1801 --set-credential=firstboot.locale:de_DE.UTF-
8 \
1802 --set-credential=passwd.hashed-password.root:'$y$j9T$yAuRJu1o5HioZAGDYPU5d.$F64ni6J2y2nNQve90M/p0ZP0ECP/qqzipNyaY9fjGpC' \
1805 <para>The above command line will invoke the specified image file
<filename>image.raw
</filename> in
1806 volatile mode, i.e. with empty
<filename>/etc/
</filename> and
<filename>/var/
</filename>. The
1807 container payload will recognize this as a first boot, and will invoke
1808 <filename>systemd-firstboot.service
</filename>, which then reads the two passed credentials to
1809 configure the system's initial locale and root password.
</para>
1811 <xi:include href=
"version-info.xml" xpointer=
"v247"/>
1816 </refsect2><refsect2>
1817 <title>Other
</title>
1820 <xi:include href=
"standard-options.xml" xpointer=
"no-pager" />
1821 <xi:include href=
"standard-options.xml" xpointer=
"help" />
1822 <xi:include href=
"standard-options.xml" xpointer=
"version" />
1827 <xi:include href=
"common-variables.xml" />
1830 <title>Examples
</title>
1832 <xi:include href=
"importctl.xml" xpointer=
"example-import-tar" />
1835 <title>Build and boot a minimal Fedora distribution in a container
</title>
1837 <programlisting># dnf -y --releasever=
&fedora_latest_version; --installroot=/var/lib/machines/f
&fedora_latest_version; \
1838 --repo=fedora --repo=updates --setopt=install_weak_deps=False install \
1839 passwd dnf fedora-release vim-minimal util-linux systemd systemd-networkd
1840 # systemd-nspawn -bD /var/lib/machines/f
&fedora_latest_version;</programlisting>
1842 <para>This installs a minimal Fedora distribution into the
1843 directory
<filename index=
"false">/var/lib/machines/f
&fedora_latest_version;</filename>
1844 and then boots that OS in a namespace container. Because the installation
1845 is located underneath the standard
<filename>/var/lib/machines/
</filename>
1846 directory, it is also possible to start the machine using
1847 <command>systemd-nspawn -M f
&fedora_latest_version;</command>.
</para>
1851 <title>Spawn a shell in a container of a minimal Debian unstable distribution
</title>
1853 <programlisting># debootstrap unstable ~/debian-tree/
1854 # systemd-nspawn -D ~/debian-tree/
</programlisting>
1856 <para>This installs a minimal Debian unstable distribution into
1857 the directory
<filename>~/debian-tree/
</filename> and then
1858 spawns a shell from this image in a namespace container.
</para>
1860 <para><command>debootstrap
</command> supports
1861 <ulink url=
"https://www.debian.org">Debian
</ulink>,
1862 <ulink url=
"https://www.ubuntu.com">Ubuntu
</ulink>,
1863 and
<ulink url=
"https://www.tanglu.org">Tanglu
</ulink>
1864 out of the box, so the same command can be used to install any of those. For other
1865 distributions from the Debian family, a mirror has to be specified, see
1866 <citerefentry project='die-net'
><refentrytitle>debootstrap
</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
1871 <title>Boot a minimal
1872 <ulink url=
"https://www.archlinux.org">Arch Linux
</ulink> distribution in a container
</title>
1874 <programlisting># pacstrap -c ~/arch-tree/ base
1875 # systemd-nspawn -bD ~/arch-tree/
</programlisting>
1877 <para>This installs a minimal Arch Linux distribution into the
1878 directory
<filename>~/arch-tree/
</filename> and then boots an OS
1879 in a namespace container in it.
</para>
1884 <ulink url=
"https://software.opensuse.org/distributions/tumbleweed">OpenSUSE Tumbleweed
</ulink>
1885 rolling distribution
</title>
1887 <programlisting># zypper --root=/var/lib/machines/tumbleweed ar -c \
1888 https://download.opensuse.org/tumbleweed/repo/oss tumbleweed
1889 # zypper --root=/var/lib/machines/tumbleweed refresh
1890 # zypper --root=/var/lib/machines/tumbleweed install --no-recommends \
1891 systemd shadow zypper openSUSE-release vim
1892 # systemd-nspawn -M tumbleweed passwd root
1893 # systemd-nspawn -M tumbleweed -b
</programlisting>
1897 <title>Boot into an ephemeral snapshot of the host system
</title>
1899 <programlisting># systemd-nspawn -D / -xb
</programlisting>
1901 <para>This runs a copy of the host system in a snapshot which is removed immediately when the container
1902 exits. All file system changes made during runtime will be lost on shutdown, hence.
</para>
1906 <title>Run a container with SELinux sandbox security contexts
</title>
1908 <programlisting># chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container
1909 # systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 \
1910 -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh
</programlisting>
1914 <title>Run a container with an OSTree deployment
</title>
1916 <programlisting># systemd-nspawn -b -i ~/image.raw \
1917 --pivot-root=/ostree/deploy/$OS/deploy/$CHECKSUM:/sysroot \
1918 --bind=+/sysroot/ostree/deploy/$OS/var:/var
</programlisting>
1923 <title>Exit status
</title>
1925 <para>The exit code of the program executed in the container is
1930 <title>See Also
</title>
1931 <para><simplelist type=
"inline">
1932 <member><citerefentry><refentrytitle>systemd
</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
1933 <member><citerefentry><refentrytitle>systemd.nspawn
</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
1934 <member><citerefentry project='man-pages'
><refentrytitle>chroot
</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
1935 <member><citerefentry project='mankier'
><refentrytitle>dnf
</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
1936 <member><citerefentry project='die-net'
><refentrytitle>debootstrap
</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
1937 <member><citerefentry project='archlinux'
><refentrytitle>pacman
</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
1938 <member><citerefentry project='mankier'
><refentrytitle>zypper
</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
1939 <member><citerefentry><refentrytitle>systemd.slice
</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
1940 <member><citerefentry><refentrytitle>machinectl
</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
1941 <member><citerefentry><refentrytitle>importctl
</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
1942 <member><citerefentry><refentrytitle>systemd-mountfsd.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
1943 <member><citerefentry><refentrytitle>systemd-nsresourced.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
1944 <member><citerefentry project='url'
><refentrytitle url='https://btrfs.readthedocs.io/en/latest/btrfs.html'
>btrfs
</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
1945 </simplelist></para>