2 <!DOCTYPE refentry PUBLIC
"-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
4 <!ENTITY fedora_latest_version
"32">
5 <!ENTITY fedora_cloud_release
"1.6">
7 <!-- SPDX-License-Identifier: LGPL-2.1+ -->
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 starting the 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> which is not the default in case
<command>systemd-nspawn
</command> is
88 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. 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>Options
</title>
124 <para>If option
<option>-b
</option> is specified, the arguments
125 are used as arguments for the init program. Otherwise,
126 <replaceable>COMMAND
</replaceable> specifies the program to launch
127 in the container, and the remaining arguments are used as
128 arguments for this program. If
<option>--boot
</option> is not used and
129 no arguments are specified, a shell is launched in the
132 <para>The following options are understood:
</para>
137 <term><option>-q
</option></term>
138 <term><option>--quiet
</option></term>
140 <listitem><para>Turns off any status output by the tool
141 itself. When this switch is used, the only output from nspawn
142 will be the console output of the container OS
143 itself.
</para></listitem>
147 <term><option>--settings=
</option><replaceable>MODE
</replaceable></term>
149 <listitem><para>Controls whether
150 <command>systemd-nspawn
</command> shall search for and use
151 additional per-container settings from
152 <filename>.nspawn
</filename> files. Takes a boolean or the
153 special values
<option>override
</option> or
154 <option>trusted
</option>.
</para>
156 <para>If enabled (the default), a settings file named after the
157 machine (as specified with the
<option>--machine=
</option>
158 setting, or derived from the directory or image file name)
159 with the suffix
<filename>.nspawn
</filename> is searched in
160 <filename>/etc/systemd/nspawn/
</filename> and
161 <filename>/run/systemd/nspawn/
</filename>. If it is found
162 there, its settings are read and used. If it is not found
163 there, it is subsequently searched in the same directory as the
164 image file or in the immediate parent of the root directory of
165 the container. In this case, if the file is found, its settings
166 will be also read and used, but potentially unsafe settings
167 are ignored. Note that in both these cases, settings on the
168 command line take precedence over the corresponding settings
169 from loaded
<filename>.nspawn
</filename> files, if both are
170 specified. Unsafe settings are considered all settings that
171 elevate the container's privileges or grant access to
172 additional resources such as files or directories of the
173 host. For details about the format and contents of
174 <filename>.nspawn
</filename> files, consult
175 <citerefentry><refentrytitle>systemd.nspawn
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
177 <para>If this option is set to
<option>override
</option>, the
178 file is searched, read and used the same way, however, the order of
179 precedence is reversed: settings read from the
180 <filename>.nspawn
</filename> file will take precedence over
181 the corresponding command line options, if both are
184 <para>If this option is set to
<option>trusted
</option>, the
185 file is searched, read and used the same way, but regardless
186 of being found in
<filename>/etc/systemd/nspawn/
</filename>,
187 <filename>/run/systemd/nspawn/
</filename> or next to the image
188 file or container root directory, all settings will take
189 effect, however, command line arguments still take precedence
190 over corresponding settings.
</para>
192 <para>If disabled, no
<filename>.nspawn
</filename> file is read
193 and no settings except the ones on the command line are in
194 effect.
</para></listitem>
200 <title>Image Options
</title>
205 <term><option>-D
</option></term>
206 <term><option>--directory=
</option></term>
208 <listitem><para>Directory to use as file system root for the
211 <para>If neither
<option>--directory=
</option>, nor
212 <option>--image=
</option> is specified the directory is
213 determined by searching for a directory named the same as the
214 machine name specified with
<option>--machine=
</option>. See
215 <citerefentry><refentrytitle>machinectl
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
216 section
"Files and Directories" for the precise search path.
</para>
218 <para>If neither
<option>--directory=
</option>,
219 <option>--image=
</option>, nor
<option>--machine=
</option>
220 are specified, the current directory will
221 be used. May not be specified together with
222 <option>--image=
</option>.
</para></listitem>
226 <term><option>--template=
</option></term>
228 <listitem><para>Directory or
<literal>btrfs
</literal> subvolume to use as template for the
229 container's root directory. If this is specified and the container's root directory (as configured by
230 <option>--directory=
</option>) does not yet exist it is created as
<literal>btrfs
</literal> snapshot
231 (if supported) or plain directory (otherwise) and populated from this template tree. Ideally, the
232 specified template path refers to the root of a
<literal>btrfs
</literal> subvolume, in which case a
233 simple copy-on-write snapshot is taken, and populating the root directory is instant. If the
234 specified template path does not refer to the root of a
<literal>btrfs
</literal> subvolume (or not
235 even to a
<literal>btrfs
</literal> file system at all), the tree is copied (though possibly in a
236 'reflink' copy-on-write scheme — if the file system supports that), which can be substantially more
237 time-consuming. Note that the snapshot taken is of the specified directory or subvolume, including
238 all subdirectories and subvolumes below it, but excluding any sub-mounts. May not be specified
239 together with
<option>--image=
</option> or
<option>--ephemeral
</option>.
</para>
241 <para>Note that this switch leaves hostname, machine ID and
242 all other settings that could identify the instance
243 unmodified.
</para></listitem>
247 <term><option>-x
</option></term>
248 <term><option>--ephemeral
</option></term>
250 <listitem><para>If specified, the container is run with a temporary snapshot of its file system that is removed
251 immediately when the container terminates. May not be specified together with
252 <option>--template=
</option>.
</para>
253 <para>Note that this switch leaves hostname, machine ID and all other settings that could identify
254 the instance unmodified. Please note that — as with
<option>--template=
</option> — taking the
255 temporary snapshot is more efficient on file systems that support subvolume snapshots or 'reflinks'
256 natively (
<literal>btrfs
</literal> or new
<literal>xfs
</literal>) than on more traditional file
257 systems that do not (
<literal>ext4
</literal>). Note that the snapshot taken is of the specified
258 directory or subvolume, including all subdirectories and subvolumes below it, but excluding any
261 <para>With this option no modifications of the container image are retained. Use
262 <option>--volatile=
</option> (described below) for other mechanisms to restrict persistency of
263 container images during runtime.
</para>
268 <term><option>-i
</option></term>
269 <term><option>--image=
</option></term>
271 <listitem><para>Disk image to mount the root directory for the
272 container from. Takes a path to a regular file or to a block
273 device node. The file or block device must contain
277 <listitem><para>An MBR partition table with a single
278 partition of type
0x83 that is marked
279 bootable.
</para></listitem>
281 <listitem><para>A GUID partition table (GPT) with a single
283 0fc63daf-
8483-
4772-
8e79-
3d69d8477de4.
</para></listitem>
285 <listitem><para>A GUID partition table (GPT) with a marked
286 root partition which is mounted as the root directory of the
287 container. Optionally, GPT images may contain a home and/or
288 a server data partition which are mounted to the appropriate
289 places in the container. All these partitions must be
290 identified by the partition types defined by the
<ulink
291 url=
"https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable
292 Partitions Specification
</ulink>.
</para></listitem>
294 <listitem><para>No partition table, and a single file system spanning the whole image.
</para></listitem>
297 <para>On GPT images, if an EFI System Partition (ESP) is discovered, it is automatically mounted to
298 <filename>/efi
</filename> (or
<filename>/boot
</filename> as fallback) in case a directory by this name exists
301 <para>Partitions encrypted with LUKS are automatically decrypted. Also, on GPT images dm-verity data integrity
302 hash partitions are set up if the root hash for them is specified using the
<option>--root-hash=
</option>
305 <para>Single file system images (i.e. file systems without a surrounding partition table) can be opened using
306 dm-verity if the integrity data is passed using the
<option>--root-hash=
</option> and
307 <option>--verity-data=
</option> (and optionally
<option>--root-hash-sig=
</option>) options.
</para>
309 <para>Any other partitions, such as foreign partitions or swap partitions are not mounted. May not be specified
310 together with
<option>--directory=
</option>,
<option>--template=
</option>.
</para></listitem>
314 <term><option>--oci-bundle=
</option></term>
316 <listitem><para>Takes the path to an OCI runtime bundle to invoke, as specified in the
<ulink
317 url=
"https://github.com/opencontainers/runtime-spec/blob/master/spec.md">OCI Runtime Specification
</ulink>. In
318 this case no
<filename>.nspawn
</filename> file is loaded, and the root directory and various settings are read
319 from the OCI runtime JSON data (but data passed on the command line takes precedence).
</para></listitem>
323 <term><option>--read-only
</option></term>
325 <listitem><para>Mount the container's root file system (and any other file systems container in the container
326 image) read-only. This has no effect on additional mounts made with
<option>--bind=
</option>,
327 <option>--tmpfs=
</option> and similar options. This mode is implied if the container image file or directory is
328 marked read-only itself. It is also implied if
<option>--volatile=
</option> is used. In this case the container
329 image on disk is strictly read-only, while changes are permitted but kept non-persistently in memory only. For
330 further details, see below.
</para></listitem>
334 <term><option>--volatile
</option></term>
335 <term><option>--volatile=
</option><replaceable>MODE
</replaceable></term>
337 <listitem><para>Boots the container in volatile mode. When no mode parameter is passed or when mode is
338 specified as
<option>yes
</option>, full volatile mode is enabled. This means the root directory is mounted as a
339 mostly unpopulated
<literal>tmpfs
</literal> instance, and
<filename>/usr/
</filename> from the OS tree is
340 mounted into it in read-only mode (the system thus starts up with read-only OS image, but pristine state and
341 configuration, any changes are lost on shutdown). When the mode parameter is specified as
342 <option>state
</option>, the OS tree is mounted read-only, but
<filename>/var/
</filename> is mounted as a
343 writable
<literal>tmpfs
</literal> instance into it (the system thus starts up with read-only OS resources and
344 configuration, but pristine state, and any changes to the latter are lost on shutdown). When the mode parameter
345 is specified as
<option>overlay
</option> the read-only root file system is combined with a writable
346 <filename>tmpfs
</filename> instance through
<literal>overlayfs
</literal>, so that it appears at it normally
347 would, but any changes are applied to the temporary file system only and lost when the container is
348 terminated. When the mode parameter is specified as
<option>no
</option> (the default), the whole OS tree is
349 made available writable (unless
<option>--read-only
</option> is specified, see above).
</para>
351 <para>Note that if one of the volatile modes is chosen, its effect is limited to the root file system (or
352 <filename>/var/
</filename> in case of
<option>state
</option>), and any other mounts placed in the hierarchy are
353 unaffected — regardless if they are established automatically (e.g. the EFI system partition that might be
354 mounted to
<filename>/efi/
</filename> or
<filename>/boot/
</filename>) or explicitly (e.g. through an additional
355 command line option such as
<option>--bind=
</option>, see below). This means, even if
356 <option>--volatile=overlay
</option> is used changes to
<filename>/efi/
</filename> or
357 <filename>/boot/
</filename> are prohibited in case such a partition exists in the container image operated on,
358 and even if
<option>--volatile=state
</option> is used the hypothetical file
<filename>/etc/foobar
</filename> is
359 potentially writable if
<option>--bind=/etc/foobar
</option> if used to mount it from outside the read-only
360 container
<filename>/etc
</filename> directory.
</para>
362 <para>The
<option>--ephemeral
</option> option is closely related to this setting, and provides similar
363 behaviour by making a temporary, ephemeral copy of the whole OS image and executing that. For further details,
366 <para>The
<option>--tmpfs=
</option> and
<option>--overlay=
</option> options provide similar functionality, but
367 for specific sub-directories of the OS image only. For details, see below.
</para>
369 <para>This option provides similar functionality for containers as the
<literal>systemd.volatile=
</literal>
370 kernel command line switch provides for host systems. See
371 <citerefentry><refentrytitle>kernel-command-line
</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
374 <para>Note that setting this option to
<option>yes
</option> or
<option>state
</option> will only work
375 correctly with operating systems in the container that can boot up with only
376 <filename>/usr/
</filename> mounted, and are able to automatically populate
<filename>/var/
</filename>
377 (and
<filename>/etc/
</filename> in case of
<literal>--volatile=yes
</literal>). Specifically, this
378 means that operating systems that follow the historic split of
<filename>/bin/
</filename> and
379 <filename>/lib/
</filename> (and related directories) from
<filename>/usr/
</filename> (i.e. where the
380 former are not symlinks into the latter) are not supported by
<literal>--volatile=yes
</literal> as
381 container payload. The
<option>overlay
</option> option does not require any particular preparations
382 in the OS, but do note that
<literal>overlayfs
</literal> behaviour differs from regular file systems
383 in a number of ways, and hence compatibility is limited.
</para></listitem>
387 <term><option>--root-hash=
</option></term>
389 <listitem><para>Takes a data integrity (dm-verity) root hash specified in hexadecimal. This option enables data
390 integrity checks using dm-verity, if the used image contains the appropriate integrity data (see above). The
391 specified hash must match the root hash of integrity data, and is usually at least
256 bits (and hence
64
392 formatted hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but
393 the image file carries the
<literal>user.verity.roothash
</literal> extended file attribute (see
<citerefentry
394 project='man-pages'
><refentrytitle>xattr
</refentrytitle><manvolnum>7</manvolnum></citerefentry>), then the root
395 hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found (or
396 is not supported by the underlying file system), but a file with the
<filename>.roothash
</filename> suffix is
397 found next to the image file, bearing otherwise the same name (except if the image has the
398 <filename>.raw
</filename> suffix, in which case the root hash file must not have it in its name), the root hash
399 is read from it and automatically used, also as formatted hexadecimal characters.
</para></listitem>
403 <term><option>--root-hash-sig=
</option></term>
405 <listitem><para>Takes a PKCS7 formatted binary signature of the
<option>--root-hash=
</option> option as a path
406 to a DER encoded signature file or as an ASCII base64 string encoding of the DER encoded signature, prefixed
407 by
<literal>base64:
</literal>. The dm-verity volume will only be opened if the signature of the root hash hex
408 string is valid and done by a public key present in the kernel keyring. If this option is not specified, but a
409 file with the
<filename>.roothash.p7s
</filename> suffix is found next to the image file, bearing otherwise the
410 same name (except if the image has the
<filename>.raw
</filename> suffix, in which case the signature file must
411 not have it in its name), the signature is read from it and automatically used.
</para></listitem>
415 <term><option>--verity-data=
</option></term>
417 <listitem><para>Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks
418 using dm-verity, if a root-hash is passed and if the used image itself does not contains the integrity data.
419 The integrity data must be matched by the root hash. If this option is not specified, but a file with the
420 <filename>.verity
</filename> suffix is found next to the image file, bearing otherwise the same name (except if
421 the image has the
<filename>.raw
</filename> suffix, in which case the verity data file must not have it in its name),
422 the verity data is read from it and automatically used.
</para></listitem>
426 <term><option>--pivot-root=
</option></term>
428 <listitem><para>Pivot the specified directory to
<filename>/
</filename> inside the container, and either unmount the
429 container's old root, or pivot it to another specified directory. Takes one of: a path argument — in which case the
430 specified path will be pivoted to
<filename>/
</filename> and the old root will be unmounted; or a colon-separated pair
431 of new root path and pivot destination for the old root. The new root path will be pivoted to
<filename>/
</filename>,
432 and the old
<filename>/
</filename> will be pivoted to the other directory. Both paths must be absolute, and are resolved
433 in the container's file system namespace.
</para>
435 <para>This is for containers which have several bootable directories in them; for example, several
436 <ulink url=
"https://ostree.readthedocs.io/en/latest/">OSTree
</ulink> deployments. It emulates the behavior of
437 the boot loader and initial RAM disk which normally select which directory to mount as the root and start the
438 container's PID
1 in.
</para></listitem>
442 </refsect2><refsect2>
443 <title>Execution Options
</title>
447 <term><option>-a
</option></term>
448 <term><option>--as-pid2
</option></term>
450 <listitem><para>Invoke the shell or specified program as process ID (PID)
2 instead of PID
1 (init). By
451 default, if neither this option nor
<option>--boot
</option> is used, the selected program is run as the process
452 with PID
1, a mode only suitable for programs that are aware of the special semantics that the process with
453 PID
1 has on UNIX. For example, it needs to reap all processes reparented to it, and should implement
454 <command>sysvinit
</command> compatible signal handling (specifically: it needs to reboot on SIGINT, reexecute
455 on SIGTERM, reload configuration on SIGHUP, and so on). With
<option>--as-pid2
</option> a minimal stub init
456 process is run as PID
1 and the selected program is executed as PID
2 (and hence does not need to implement any
457 special semantics). The stub init process will reap processes as necessary and react appropriately to
458 signals. It is recommended to use this mode to invoke arbitrary commands in containers, unless they have been
459 modified to run correctly as PID
1. Or in other words: this switch should be used for pretty much all commands,
460 except when the command refers to an init or shell implementation, as these are generally capable of running
461 correctly as PID
1. This option may not be combined with
<option>--boot
</option>.
</para>
466 <term><option>-b
</option></term>
467 <term><option>--boot
</option></term>
469 <listitem><para>Automatically search for an init program and invoke it as PID
1, instead of a shell or a user
470 supplied program. If this option is used, arguments specified on the command line are used as arguments for the
471 init program. This option may not be combined with
<option>--as-pid2
</option>.
</para>
473 <para>The following table explains the different modes of invocation and relationship to
474 <option>--as-pid2
</option> (see above):
</para>
477 <title>Invocation Mode
</title>
478 <tgroup cols='
2' align='left' colsep='
1' rowsep='
1'
>
479 <colspec colname=
"switch" />
480 <colspec colname=
"explanation" />
483 <entry>Switch
</entry>
484 <entry>Explanation
</entry>
489 <entry>Neither
<option>--as-pid2
</option> nor
<option>--boot
</option> specified
</entry>
490 <entry>The passed parameters are interpreted as the command line, which is executed as PID
1 in the container.
</entry>
494 <entry><option>--as-pid2
</option> specified
</entry>
495 <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>
499 <entry><option>--boot
</option> specified
</entry>
500 <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>
507 <para>Note that
<option>--boot
</option> is the default mode of operation if the
508 <filename>systemd-nspawn@.service
</filename> template unit file is used.
</para>
513 <term><option>--chdir=
</option></term>
515 <listitem><para>Change to the specified working directory before invoking the process in the container. Expects
516 an absolute path in the container's file system namespace.
</para></listitem>
520 <term><option>-E
<replaceable>NAME
</replaceable>=
<replaceable>VALUE
</replaceable></option></term>
521 <term><option>--setenv=
<replaceable>NAME
</replaceable>=
<replaceable>VALUE
</replaceable></option></term>
523 <listitem><para>Specifies an environment variable assignment
524 to pass to the init process in the container, in the format
525 <literal>NAME=VALUE
</literal>. This may be used to override
526 the default variables or to set additional variables. This
527 parameter may be used more than once.
</para></listitem>
531 <term><option>-u
</option></term>
532 <term><option>--user=
</option></term>
534 <listitem><para>After transitioning into the container, change to the specified user defined in the
535 container's user database. Like all other systemd-nspawn features, this is not a security feature and
536 provides protection against accidental destructive operations only.
</para></listitem>
540 <term><option>--kill-signal=
</option></term>
542 <listitem><para>Specify the process signal to send to the container's PID
1 when nspawn itself receives
543 <constant>SIGTERM
</constant>, in order to trigger an orderly shutdown of the container. Defaults to
544 <constant>SIGRTMIN+
3</constant> if
<option>--boot
</option> is used (on systemd-compatible init systems
545 <constant>SIGRTMIN+
3</constant> triggers an orderly shutdown). If
<option>--boot
</option> is not used and this
546 option is not specified the container's processes are terminated abruptly via
<constant>SIGKILL
</constant>. For
547 a list of valid signals, see
<citerefentry
548 project='man-pages'
><refentrytitle>signal
</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
</para></listitem>
552 <term><option>--notify-ready=
</option></term>
554 <listitem><para>Configures support for notifications from the container's init process.
555 <option>--notify-ready=
</option> takes a boolean (
<option>no
</option> and
<option>yes
</option>).
556 With option
<option>no
</option> systemd-nspawn notifies systemd
557 with a
<literal>READY=
1</literal> message when the init process is created.
558 With option
<option>yes
</option> systemd-nspawn waits for the
559 <literal>READY=
1</literal> message from the init process in the container
560 before sending its own to systemd. For more details about notifications
561 see
<citerefentry><refentrytitle>sd_notify
</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
</para></listitem>
565 </refsect2><refsect2>
566 <title>System Identity Options
</title>
570 <term><option>-M
</option></term>
571 <term><option>--machine=
</option></term>
573 <listitem><para>Sets the machine name for this container. This
574 name may be used to identify this container during its runtime
575 (for example in tools like
576 <citerefentry><refentrytitle>machinectl
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
577 and similar), and is used to initialize the container's
578 hostname (which the container can choose to override,
579 however). If not specified, the last component of the root
580 directory path of the container is used, possibly suffixed
581 with a random identifier in case
<option>--ephemeral
</option>
582 mode is selected. If the root directory selected is the host's
583 root directory the host's hostname is used as default
584 instead.
</para></listitem>
588 <term><option>--hostname=
</option></term>
590 <listitem><para>Controls the hostname to set within the container, if different from the machine name. Expects
591 a valid hostname as argument. If this option is used, the kernel hostname of the container will be set to this
592 value, otherwise it will be initialized to the machine name as controlled by the
<option>--machine=
</option>
593 option described above. The machine name is used for various aspect of identification of the container from the
594 outside, the kernel hostname configurable with this option is useful for the container to identify itself from
595 the inside. It is usually a good idea to keep both forms of identification synchronized, in order to avoid
596 confusion. It is hence recommended to avoid usage of this option, and use
<option>--machine=
</option>
597 exclusively. Note that regardless whether the container's hostname is initialized from the name set with
598 <option>--hostname=
</option> or the one set with
<option>--machine=
</option>, the container can later override
599 its kernel hostname freely on its own as well.
</para>
604 <term><option>--uuid=
</option></term>
606 <listitem><para>Set the specified UUID for the container. The
607 init system will initialize
608 <filename>/etc/machine-id
</filename> from this if this file is
609 not set yet. Note that this option takes effect only if
610 <filename>/etc/machine-id
</filename> in the container is
611 unpopulated.
</para></listitem>
615 </refsect2><refsect2>
616 <title>Property Options
</title>
620 <term><option>-S
</option></term>
621 <term><option>--slice=
</option></term>
623 <listitem><para>Make the container part of the specified slice, instead of the default
624 <filename>machine.slice
</filename>. This applies only if the machine is run in its own scope unit, i.e. if
625 <option>--keep-unit
</option> isn't used.
</para>
630 <term><option>--property=
</option></term>
632 <listitem><para>Set a unit property on the scope unit to register for the machine. This applies only if the
633 machine is run in its own scope unit, i.e. if
<option>--keep-unit
</option> isn't used. Takes unit property
634 assignments in the same format as
<command>systemctl set-property
</command>. This is useful to set memory
635 limits and similar for container.
</para>
640 <term><option>--register=
</option></term>
642 <listitem><para>Controls whether the container is registered with
643 <citerefentry><refentrytitle>systemd-machined
</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Takes a
644 boolean argument, which defaults to
<literal>yes
</literal>. This option should be enabled when the container
645 runs a full Operating System (more specifically: a system and service manager as PID
1), and is useful to
646 ensure that the container is accessible via
647 <citerefentry><refentrytitle>machinectl
</refentrytitle><manvolnum>1</manvolnum></citerefentry> and shown by
648 tools such as
<citerefentry
649 project='man-pages'
><refentrytitle>ps
</refentrytitle><manvolnum>1</manvolnum></citerefentry>. If the container
650 does not run a service manager, it is recommended to set this option to
651 <literal>no
</literal>.
</para></listitem>
655 <term><option>--keep-unit
</option></term>
657 <listitem><para>Instead of creating a transient scope unit to run the container in, simply use the service or
658 scope unit
<command>systemd-nspawn
</command> has been invoked in. If
<option>--register=yes
</option> is set
659 this unit is registered with
660 <citerefentry><refentrytitle>systemd-machined
</refentrytitle><manvolnum>8</manvolnum></citerefentry>. This
661 switch should be used if
<command>systemd-nspawn
</command> is invoked from within a service unit, and the
662 service unit's sole purpose is to run a single
<command>systemd-nspawn
</command> container. This option is not
663 available if run from a user session.
</para>
664 <para>Note that passing
<option>--keep-unit
</option> disables the effect of
<option>--slice=
</option> and
665 <option>--property=
</option>. Use
<option>--keep-unit
</option> and
<option>--register=no
</option> in
666 combination to disable any kind of unit allocation or registration with
667 <command>systemd-machined
</command>.
</para></listitem>
671 </refsect2><refsect2>
672 <title>User Namespacing Options
</title>
676 <term><option>--private-users=
</option></term>
678 <listitem><para>Controls user namespacing. If enabled, the container will run with its own private set of UNIX
679 user and group ids (UIDs and GIDs). This involves mapping the private UIDs/GIDs used in the container (starting
680 with the container's root user
0 and up) to a range of UIDs/GIDs on the host that are not used for other
681 purposes (usually in the range beyond the host's UID/GID
65536). The parameter may be specified as follows:
</para>
684 <listitem><para>If one or two colon-separated numbers are specified, user namespacing is turned on. The first
685 parameter specifies the first host UID/GID to assign to the container, the second parameter specifies the
686 number of host UIDs/GIDs to assign to the container. If the second parameter is omitted,
65536 UIDs/GIDs are
687 assigned.
</para></listitem>
689 <listitem><para>If the parameter is omitted, or true, user namespacing is turned on. The UID/GID range to
690 use is determined automatically from the file ownership of the root directory of the container's directory
691 tree. To use this option, make sure to prepare the directory tree in advance, and ensure that all files and
692 directories in it are owned by UIDs/GIDs in the range you'd like to use. Also, make sure that used file ACLs
693 exclusively reference UIDs/GIDs in the appropriate range. If this mode is used the number of UIDs/GIDs
694 assigned to the container for use is
65536, and the UID/GID of the root directory must be a multiple of
695 65536.
</para></listitem>
697 <listitem><para>If the parameter is false, user namespacing is turned off. This is the default.
</para>
700 <listitem><para>The special value
<literal>pick
</literal> turns on user namespacing. In this case the UID/GID
701 range is automatically chosen. As first step, the file owner of the root directory of the container's
702 directory tree is read, and it is checked that it is currently not used by the system otherwise (in
703 particular, that no other container is using it). If this check is successful, the UID/GID range determined
704 this way is used, similar to the behavior if
"yes" is specified. If the check is not successful (and thus
705 the UID/GID range indicated in the root directory's file owner is already used elsewhere) a new – currently
706 unused – UID/GID range of
65536 UIDs/GIDs is randomly chosen between the host UID/GIDs of
524288 and
707 1878982656, always starting at a multiple of
65536. This setting implies
708 <option>--private-users-chown
</option> (see below), which has the effect that the files and directories in
709 the container's directory tree will be owned by the appropriate users of the range picked. Using this option
710 makes user namespace behavior fully automatic. Note that the first invocation of a previously unused
711 container image might result in picking a new UID/GID range for it, and thus in the (possibly expensive) file
712 ownership adjustment operation. However, subsequent invocations of the container will be cheap (unless of
713 course the picked UID/GID range is assigned to a different use by then).
</para></listitem>
716 <para>It is recommended to assign at least
65536 UIDs/GIDs to each container, so that the usable UID/GID range in the
717 container covers
16 bit. For best security, do not assign overlapping UID/GID ranges to multiple containers. It is
718 hence a good idea to use the upper
16 bit of the host
32-bit UIDs/GIDs as container identifier, while the lower
16
719 bit encode the container UID/GID used. This is in fact the behavior enforced by the
720 <option>--private-users=pick
</option> option.
</para>
722 <para>When user namespaces are used, the GID range assigned to each container is always chosen identical to the
725 <para>In most cases, using
<option>--private-users=pick
</option> is the recommended option as it enhances
726 container security massively and operates fully automatically in most cases.
</para>
728 <para>Note that the picked UID/GID range is not written to
<filename>/etc/passwd
</filename> or
729 <filename>/etc/group
</filename>. In fact, the allocation of the range is not stored persistently anywhere,
730 except in the file ownership of the files and directories of the container.
</para>
732 <para>Note that when user namespacing is used file ownership on disk reflects this, and all of the container's
733 files and directories are owned by the container's effective user and group IDs. This means that copying files
734 from and to the container image requires correction of the numeric UID/GID values, according to the UID/GID
735 shift applied.
</para></listitem>
739 <term><option>--private-users-chown
</option></term>
741 <listitem><para>If specified, all files and directories in the container's directory tree will be
742 adjusted so that they are owned by the appropriate UIDs/GIDs selected for the container (see above).
743 This operation is potentially expensive, as it involves iterating through the full directory tree of
744 the container. Besides actual file ownership, file ACLs are adjusted as well.
</para>
746 <para>This option is implied if
<option>--private-users=pick
</option> is used. This option has no effect if
747 user namespacing is not used.
</para></listitem>
751 <term><option>-U
</option></term>
753 <listitem><para>If the kernel supports the user namespaces feature, equivalent to
754 <option>--private-users=pick --private-users-chown
</option>, otherwise equivalent to
755 <option>--private-users=no
</option>.
</para>
757 <para>Note that
<option>-U
</option> is the default if the
758 <filename>systemd-nspawn@.service
</filename> template unit file is used.
</para>
760 <para>Note: it is possible to undo the effect of
<option>--private-users-chown
</option> (or
761 <option>-U
</option>) on the file system by redoing the operation with the first UID of
0:
</para>
763 <programlisting>systemd-nspawn … --private-users=
0 --private-users-chown
</programlisting>
769 </refsect2><refsect2>
770 <title>Networking Options
</title>
775 <term><option>--private-network
</option></term>
777 <listitem><para>Disconnect networking of the container from
778 the host. This makes all network interfaces unavailable in the
779 container, with the exception of the loopback device and those
780 specified with
<option>--network-interface=
</option> and
781 configured with
<option>--network-veth
</option>. If this
782 option is specified, the
<constant>CAP_NET_ADMIN
</constant> capability will be
783 added to the set of capabilities the container retains. The
784 latter may be disabled by using
<option>--drop-capability=
</option>.
785 If this option is not specified (or implied by one of the options
786 listed below), the container will have full access to the host network.
791 <term><option>--network-interface=
</option></term>
793 <listitem><para>Assign the specified network interface to the
794 container. This will remove the specified interface from the
795 calling namespace and place it in the container. When the
796 container terminates, it is moved back to the host namespace.
797 Note that
<option>--network-interface=
</option> implies
798 <option>--private-network
</option>. This option may be used
799 more than once to add multiple network interfaces to the
800 container.
</para></listitem>
804 <term><option>--network-macvlan=
</option></term>
806 <listitem><para>Create a
<literal>macvlan
</literal> interface
807 of the specified Ethernet network interface and add it to the
808 container. A
<literal>macvlan
</literal> interface is a virtual
809 interface that adds a second MAC address to an existing
810 physical Ethernet link. The interface in the container will be
811 named after the interface on the host, prefixed with
812 <literal>mv-
</literal>. Note that
813 <option>--network-macvlan=
</option> implies
814 <option>--private-network
</option>. This option may be used
815 more than once to add multiple network interfaces to the
816 container.
</para></listitem>
820 <term><option>--network-ipvlan=
</option></term>
822 <listitem><para>Create an
<literal>ipvlan
</literal> interface
823 of the specified Ethernet network interface and add it to the
824 container. An
<literal>ipvlan
</literal> interface is a virtual
825 interface, similar to a
<literal>macvlan
</literal> interface,
826 which uses the same MAC address as the underlying interface.
827 The interface in the container will be named after the
828 interface on the host, prefixed with
<literal>iv-
</literal>.
829 Note that
<option>--network-ipvlan=
</option> implies
830 <option>--private-network
</option>. This option may be used
831 more than once to add multiple network interfaces to the
832 container.
</para></listitem>
836 <term><option>-n
</option></term>
837 <term><option>--network-veth
</option></term>
839 <listitem><para>Create a virtual Ethernet link (
<literal>veth
</literal>) between host and container. The host
840 side of the Ethernet link will be available as a network interface named after the container's name (as
841 specified with
<option>--machine=
</option>), prefixed with
<literal>ve-
</literal>. The container side of the
842 Ethernet link will be named
<literal>host0
</literal>. The
<option>--network-veth
</option> option implies
843 <option>--private-network
</option>.
</para>
846 <citerefentry><refentrytitle>systemd-networkd.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry>
847 includes by default a network file
<filename>/usr/lib/systemd/network/
80-container-ve.network
</filename>
848 matching the host-side interfaces created this way, which contains settings to enable automatic address
849 provisioning on the created virtual link via DHCP, as well as automatic IP routing onto the host's external
850 network interfaces. It also contains
<filename>/usr/lib/systemd/network/
80-container-host0.network
</filename>
851 matching the container-side interface created this way, containing settings to enable client side address
852 assignment via DHCP. In case
<filename>systemd-networkd
</filename> is running on both the host and inside the
853 container, automatic IP communication from the container to the host is thus available, with further
854 connectivity to the external network.
</para>
856 <para>Note that
<option>--network-veth
</option> is the default if the
857 <filename>systemd-nspawn@.service
</filename> template unit file is used.
</para>
859 <para>Note that on Linux network interface names may have a length of
15 characters at maximum, while
860 container names may have a length up to
64 characters. As this option derives the host-side interface
861 name from the container name the name is possibly truncated. Thus, care needs to be taken to ensure
862 that interface names remain unique in this case, or even better container names are generally not
863 chosen longer than
12 characters, to avoid the truncation. If the name is truncated,
864 <command>systemd-nspawn
</command> will automatically append a
4-digit hash value to the name to
865 reduce the chance of collisions. However, the hash algorithm is not collision-free. (See
866 <citerefentry><refentrytitle>systemd.net-naming-scheme
</refentrytitle><manvolnum>7</manvolnum></citerefentry>
867 for details on older naming algorithms for this interface). Alternatively, the
868 <option>--network-veth-extra=
</option> option may be used, which allows free configuration of the
869 host-side interface name independently of the container name — but might require a bit more
870 additional configuration in case bridging in a fashion similar to
<option>--network-bridge=
</option>
876 <term><option>--network-veth-extra=
</option></term>
878 <listitem><para>Adds an additional virtual Ethernet link
879 between host and container. Takes a colon-separated pair of
880 host interface name and container interface name. The latter
881 may be omitted in which case the container and host sides will
882 be assigned the same name. This switch is independent of
883 <option>--network-veth
</option>, and — in contrast — may be
884 used multiple times, and allows configuration of the network
885 interface names. Note that
<option>--network-bridge=
</option>
886 has no effect on interfaces created with
887 <option>--network-veth-extra=
</option>.
</para></listitem>
891 <term><option>--network-bridge=
</option></term>
893 <listitem><para>Adds the host side of the Ethernet link created with
<option>--network-veth
</option>
894 to the specified Ethernet bridge interface. Expects a valid network interface name of a bridge device
895 as argument. Note that
<option>--network-bridge=
</option> implies
<option>--network-veth
</option>. If
896 this option is used, the host side of the Ethernet link will use the
<literal>vb-
</literal> prefix
897 instead of
<literal>ve-
</literal>. Regardless of the used naming prefix the same network interface
898 name length limits imposed by Linux apply, along with the complications this creates (for details see
899 above).
</para></listitem>
903 <term><option>--network-zone=
</option></term>
905 <listitem><para>Creates a virtual Ethernet link (
<literal>veth
</literal>) to the container and adds it to an
906 automatically managed Ethernet bridge interface. The bridge interface is named after the passed argument,
907 prefixed with
<literal>vz-
</literal>. The bridge interface is automatically created when the first container
908 configured for its name is started, and is automatically removed when the last container configured for its
909 name exits. Hence, each bridge interface configured this way exists only as long as there's at least one
910 container referencing it running. This option is very similar to
<option>--network-bridge=
</option>, besides
911 this automatic creation/removal of the bridge device.
</para>
913 <para>This setting makes it easy to place multiple related containers on a common, virtual Ethernet-based
914 broadcast domain, here called a
"zone". Each container may only be part of one zone, but each zone may contain
915 any number of containers. Each zone is referenced by its name. Names may be chosen freely (as long as they form
916 valid network interface names when prefixed with
<literal>vz-
</literal>), and it is sufficient to pass the same
917 name to the
<option>--network-zone=
</option> switch of the various concurrently running containers to join
918 them in one zone.
</para>
921 <citerefentry><refentrytitle>systemd-networkd.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry>
922 includes by default a network file
<filename>/usr/lib/systemd/network/
80-container-vz.network
</filename>
923 matching the bridge interfaces created this way, which contains settings to enable automatic address
924 provisioning on the created virtual network via DHCP, as well as automatic IP routing onto the host's external
925 network interfaces. Using
<option>--network-zone=
</option> is hence in most cases fully automatic and
926 sufficient to connect multiple local containers in a joined broadcast domain to the host, with further
927 connectivity to the external network.
</para>
932 <term><option>--network-namespace-path=
</option></term>
934 <listitem><para>Takes the path to a file representing a kernel
935 network namespace that the container shall run in. The specified path
936 should refer to a (possibly bind-mounted) network namespace file, as
937 exposed by the kernel below
<filename>/proc/$PID/ns/net
</filename>.
938 This makes the container enter the given network namespace. One of the
939 typical use cases is to give a network namespace under
940 <filename>/run/netns
</filename> created by
<citerefentry
941 project='man-pages'
><refentrytitle>ip-netns
</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
942 for example,
<option>--network-namespace-path=/run/netns/foo
</option>.
943 Note that this option cannot be used together with other
944 network-related options, such as
<option>--private-network
</option>
945 or
<option>--network-interface=
</option>.
</para></listitem>
949 <term><option>-p
</option></term>
950 <term><option>--port=
</option></term>
952 <listitem><para>If private networking is enabled, maps an IP
953 port on the host onto an IP port on the container. Takes a
954 protocol specifier (either
<literal>tcp
</literal> or
955 <literal>udp
</literal>), separated by a colon from a host port
956 number in the range
1 to
65535, separated by a colon from a
957 container port number in the range from
1 to
65535. The
958 protocol specifier and its separating colon may be omitted, in
959 which case
<literal>tcp
</literal> is assumed. The container
960 port number and its colon may be omitted, in which case the
961 same port as the host port is implied. This option is only
962 supported if private networking is used, such as with
963 <option>--network-veth
</option>,
<option>--network-zone=
</option>
964 <option>--network-bridge=
</option>.
</para></listitem>
968 </refsect2><refsect2>
969 <title>Security Options
</title>
973 <term><option>--capability=
</option></term>
975 <listitem><para>List one or more additional capabilities to grant the container. Takes a
976 comma-separated list of capability names, see
<citerefentry
977 project='man-pages'
><refentrytitle>capabilities
</refentrytitle><manvolnum>7</manvolnum></citerefentry>
978 for more information. Note that the following capabilities will be granted in any way:
979 <constant>CAP_AUDIT_CONTROL
</constant>,
<constant>CAP_AUDIT_WRITE
</constant>,
980 <constant>CAP_CHOWN
</constant>,
<constant>CAP_DAC_OVERRIDE
</constant>,
981 <constant>CAP_DAC_READ_SEARCH
</constant>,
<constant>CAP_FOWNER
</constant>,
982 <constant>CAP_FSETID
</constant>,
<constant>CAP_IPC_OWNER
</constant>,
<constant>CAP_KILL
</constant>,
983 <constant>CAP_LEASE
</constant>,
<constant>CAP_LINUX_IMMUTABLE
</constant>,
984 <constant>CAP_MKNOD
</constant>,
<constant>CAP_NET_BIND_SERVICE
</constant>,
985 <constant>CAP_NET_BROADCAST
</constant>,
<constant>CAP_NET_RAW
</constant>,
986 <constant>CAP_SETFCAP
</constant>,
<constant>CAP_SETGID
</constant>,
<constant>CAP_SETPCAP
</constant>,
987 <constant>CAP_SETUID
</constant>,
<constant>CAP_SYS_ADMIN
</constant>,
988 <constant>CAP_SYS_BOOT
</constant>,
<constant>CAP_SYS_CHROOT
</constant>,
989 <constant>CAP_SYS_NICE
</constant>,
<constant>CAP_SYS_PTRACE
</constant>,
990 <constant>CAP_SYS_RESOURCE
</constant>,
<constant>CAP_SYS_TTY_CONFIG
</constant>. Also
991 <constant>CAP_NET_ADMIN
</constant> is retained if
<option>--private-network
</option> is specified.
992 If the special value
<literal>all
</literal> is passed, all capabilities are retained.
</para>
994 <para>If the special value of
<literal>help
</literal> is passed, the program will print known
995 capability names and exit.
</para></listitem>
999 <term><option>--drop-capability=
</option></term>
1001 <listitem><para>Specify one or more additional capabilities to
1002 drop for the container. This allows running the container with
1003 fewer capabilities than the default (see
1006 <para>If the special value of
<literal>help
</literal> is passed, the program will print known
1007 capability names and exit.
</para></listitem>
1011 <term><option>--no-new-privileges=
</option></term>
1013 <listitem><para>Takes a boolean argument. Specifies the value of the
1014 <constant>PR_SET_NO_NEW_PRIVS
</constant> flag for the container payload. Defaults to off. When turned
1015 on the payload code of the container cannot acquire new privileges, i.e. the
"setuid" file bit as
1016 well as file system capabilities will not have an effect anymore. See
<citerefentry
1017 project='man-pages'
><refentrytitle>prctl
</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
1018 details about this flag.
</para></listitem>
1022 <term><option>--system-call-filter=
</option></term> <listitem><para>Alter the system call filter
1023 applied to containers. Takes a space-separated list of system call names or group names (the latter
1024 prefixed with
<literal>@
</literal>, as listed by the
<command>syscall-filter
</command> command of
1025 <citerefentry><refentrytitle>systemd-analyze
</refentrytitle><manvolnum>1</manvolnum></citerefentry>). Passed
1026 system calls will be permitted. The list may optionally be prefixed by
<literal>~
</literal>, in which
1027 case all listed system calls are prohibited. If this command line option is used multiple times the
1028 configured lists are combined. If both a positive and a negative list (that is one system call list
1029 without and one with the
<literal>~
</literal> prefix) are configured, the negative list takes
1030 precedence over the positive list. Note that
<command>systemd-nspawn
</command> always implements a
1031 system call allow list (as opposed to a deny list!), and this command line option hence adds or
1032 removes entries from the default allow list, depending on the
<literal>~
</literal> prefix. Note that
1033 the applied system call filter is also altered implicitly if additional capabilities are passed using
1034 the
<command>--capabilities=
</command>.
</para></listitem>
1038 <term><option>-Z
</option></term>
1039 <term><option>--selinux-context=
</option></term>
1041 <listitem><para>Sets the SELinux security context to be used
1042 to label processes in the container.
</para>
1047 <term><option>-L
</option></term>
1048 <term><option>--selinux-apifs-context=
</option></term>
1050 <listitem><para>Sets the SELinux security context to be used
1051 to label files in the virtual API file systems in the
1057 </refsect2><refsect2>
1058 <title>Resource Options
</title>
1063 <term><option>--rlimit=
</option></term>
1065 <listitem><para>Sets the specified POSIX resource limit for the container payload. Expects an assignment of the
1067 <literal><replaceable>LIMIT
</replaceable>=
<replaceable>SOFT
</replaceable>:
<replaceable>HARD
</replaceable></literal>
1068 or
<literal><replaceable>LIMIT
</replaceable>=
<replaceable>VALUE
</replaceable></literal>, where
1069 <replaceable>LIMIT
</replaceable> should refer to a resource limit type, such as
1070 <constant>RLIMIT_NOFILE
</constant> or
<constant>RLIMIT_NICE
</constant>. The
<replaceable>SOFT
</replaceable> and
1071 <replaceable>HARD
</replaceable> fields should refer to the numeric soft and hard resource limit values. If the
1072 second form is used,
<replaceable>VALUE
</replaceable> may specify a value that is used both as soft and hard
1073 limit. In place of a numeric value the special string
<literal>infinity
</literal> may be used to turn off
1074 resource limiting for the specific type of resource. This command line option may be used multiple times to
1075 control limits on multiple limit types. If used multiple times for the same limit type, the last use
1076 wins. For details about resource limits see
<citerefentry
1077 project='man-pages'
><refentrytitle>setrlimit
</refentrytitle><manvolnum>2</manvolnum></citerefentry>. By default
1078 resource limits for the container's init process (PID
1) are set to the same values the Linux kernel originally
1079 passed to the host init system. Note that some resource limits are enforced on resources counted per user, in
1080 particular
<constant>RLIMIT_NPROC
</constant>. This means that unless user namespacing is deployed
1081 (i.e.
<option>--private-users=
</option> is used, see above), any limits set will be applied to the resource
1082 usage of the same user on all local containers as well as the host. This means particular care needs to be
1083 taken with these limits as they might be triggered by possibly less trusted code. Example:
1084 <literal>--rlimit=RLIMIT_NOFILE=
8192:
16384</literal>.
</para></listitem>
1088 <term><option>--oom-score-adjust=
</option></term>
1090 <listitem><para>Changes the OOM (
"Out Of Memory") score adjustment value for the container payload. This controls
1091 <filename>/proc/self/oom_score_adj
</filename> which influences the preference with which this container is
1092 terminated when memory becomes scarce. For details see
<citerefentry
1093 project='man-pages'
><refentrytitle>proc
</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Takes an
1094 integer in the range -
1000…
1000.
</para></listitem>
1098 <term><option>--cpu-affinity=
</option></term>
1100 <listitem><para>Controls the CPU affinity of the container payload. Takes a comma separated list of CPU numbers
1101 or number ranges (the latter's start and end value separated by dashes). See
<citerefentry
1102 project='man-pages'
><refentrytitle>sched_setaffinity
</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
1103 details.
</para></listitem>
1107 <term><option>--personality=
</option></term>
1109 <listitem><para>Control the architecture (
"personality")
1111 <citerefentry project='man-pages'
><refentrytitle>uname
</refentrytitle><manvolnum>2</manvolnum></citerefentry>
1112 in the container. Currently, only
<literal>x86
</literal> and
1113 <literal>x86-
64</literal> are supported. This is useful when
1114 running a
32-bit container on a
64-bit host. If this setting
1115 is not used, the personality reported in the container is the
1116 same as the one reported on the host.
</para></listitem>
1120 </refsect2><refsect2>
1121 <title>Integration Options
</title>
1125 <term><option>--resolv-conf=
</option></term>
1127 <listitem><para>Configures how
<filename>/etc/resolv.conf
</filename> inside of the container shall be
1128 handled (i.e. DNS configuration synchronization from host to container). Takes one of
1129 <literal>off
</literal>,
<literal>copy-host
</literal>,
<literal>copy-static
</literal>,
1130 <literal>copy-uplink
</literal>,
<literal>copy-stub
</literal>,
<literal>replace-host
</literal>,
1131 <literal>replace-static
</literal>,
<literal>replace-uplink
</literal>,
1132 <literal>replace-stub
</literal>,
<literal>bind-host
</literal>,
<literal>bind-static
</literal>,
1133 <literal>bind-uplink
</literal>,
<literal>bind-stub
</literal>,
<literal>delete
</literal> or
1134 <literal>auto
</literal>.
</para>
1136 <para>If set to
<literal>off
</literal> the
<filename>/etc/resolv.conf
</filename> file in the
1137 container is left as it is included in the image, and neither modified nor bind mounted over.
</para>
1139 <para>If set to
<literal>copy-host
</literal>, the
<filename>/etc/resolv.conf
</filename> file from the
1140 host is copied into the container, unless the file exists already and is not a regular file (e.g. a
1141 symlink). Similar, if
<literal>replace-host
</literal> is used the file is copied, replacing any
1142 existing inode, including symlinks. Similar, if
<literal>bind-host
</literal> is used, the file is
1143 bind mounted from the host into the container.
</para>
1145 <para>If set to
<literal>copy-static
</literal>,
<literal>replace-static
</literal> or
1146 <literal>bind-static
</literal> the static
<filename>resolv.conf
</filename> file supplied with
1147 <citerefentry><refentrytitle>systemd-resolved.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry>
1148 (specifically:
<filename>/usr/lib/systemd/resolv.conf
</filename>) is copied or bind mounted into the
1151 <para>If set to
<literal>copy-uplink
</literal>,
<literal>replace-uplink
</literal> or
1152 <literal>bind-uplink
</literal> the uplink
<filename>resolv.conf
</filename> file managed by
1153 <filename>systemd-resolved.service
</filename> (specifically:
1154 <filename>/run/systemd/resolve/resolv.conf
</filename>) is copied or bind mounted into the
1157 <para>If set to
<literal>copy-stub
</literal>,
<literal>replace-stub
</literal> or
1158 <literal>bind-stub
</literal> the stub
<filename>resolv.conf
</filename> file managed by
1159 <filename>systemd-resolved.service
</filename> (specifically:
1160 <filename>/run/systemd/resolve/stub-resolv.conf
</filename>) is copied or bind mounted into the
1163 <para>If set to
<literal>delete
</literal> the
<filename>/etc/resolv.conf
</filename> file in the
1164 container is deleted if it exists.
</para>
1166 <para>Finally, if set to
<literal>auto
</literal> the file is left as it is if private networking is
1167 turned on (see
<option>--private-network
</option>). Otherwise, if
1168 <filename>systemd-resolved.service
</filename> is running its stub
<filename>resolv.conf
</filename>
1169 file is used, and if not the host's
<filename>/etc/resolv.conf
</filename> file. In the latter cases
1170 the file is copied if the image is writable, and bind mounted otherwise.
</para>
1172 <para>It's recommended to use
<literal>copy-…
</literal> or
<literal>replace-…
</literal> if the
1173 container shall be able to make changes to the DNS configuration on its own, deviating from the
1174 host's settings. Otherwise
<literal>bind
</literal> is preferable, as it means direct changes to
1175 <filename>/etc/resolv.conf
</filename> in the container are not allowed, as it is a read-only bind
1176 mount (but note that if the container has enough privileges, it might simply go ahead and unmount the
1177 bind mount anyway). Note that both if the file is bind mounted and if it is copied no further
1178 propagation of configuration is generally done after the one-time early initialization (this is
1179 because the file is usually updated through copying and renaming). Defaults to
1180 <literal>auto
</literal>.
</para></listitem>
1184 <term><option>--timezone=
</option></term>
1186 <listitem><para>Configures how
<filename>/etc/localtime
</filename> inside of the container
1187 (i.e. local timezone synchronization from host to container) shall be handled. Takes one of
1188 <literal>off
</literal>,
<literal>copy
</literal>,
<literal>bind
</literal>,
<literal>symlink
</literal>,
1189 <literal>delete
</literal> or
<literal>auto
</literal>. If set to
<literal>off
</literal> the
1190 <filename>/etc/localtime
</filename> file in the container is left as it is included in the image, and
1191 neither modified nor bind mounted over. If set to
<literal>copy
</literal> the
1192 <filename>/etc/localtime
</filename> file of the host is copied into the container. Similarly, if
1193 <literal>bind
</literal> is used, the file is bind mounted from the host into the container. If set to
1194 <literal>symlink
</literal>, a symlink is created pointing from
<filename>/etc/localtime
</filename> in
1195 the container to the timezone file in the container that matches the timezone setting on the host. If
1196 set to
<literal>delete
</literal>, the file in the container is deleted, should it exist. If set to
1197 <literal>auto
</literal> and the
<filename>/etc/localtime
</filename> file of the host is a symlink,
1198 then
<literal>symlink
</literal> mode is used, and
<literal>copy
</literal> otherwise, except if the
1199 image is read-only in which case
<literal>bind
</literal> is used instead. Defaults to
1200 <literal>auto
</literal>.
</para></listitem>
1204 <term><option>--link-journal=
</option></term>
1206 <listitem><para>Control whether the container's journal shall
1207 be made visible to the host system. If enabled, allows viewing
1208 the container's journal files from the host (but not vice
1209 versa). Takes one of
<literal>no
</literal>,
1210 <literal>host
</literal>,
<literal>try-host
</literal>,
1211 <literal>guest
</literal>,
<literal>try-guest
</literal>,
1212 <literal>auto
</literal>. If
<literal>no
</literal>, the journal
1213 is not linked. If
<literal>host
</literal>, the journal files
1214 are stored on the host file system (beneath
1215 <filename>/var/log/journal/
<replaceable>machine-id
</replaceable></filename>)
1216 and the subdirectory is bind-mounted into the container at the
1217 same location. If
<literal>guest
</literal>, the journal files
1218 are stored on the guest file system (beneath
1219 <filename>/var/log/journal/
<replaceable>machine-id
</replaceable></filename>)
1220 and the subdirectory is symlinked into the host at the same
1221 location.
<literal>try-host
</literal> and
1222 <literal>try-guest
</literal> do the same but do not fail if
1223 the host does not have persistent journaling enabled. If
1224 <literal>auto
</literal> (the default), and the right
1225 subdirectory of
<filename>/var/log/journal
</filename> exists,
1226 it will be bind mounted into the container. If the
1227 subdirectory does not exist, no linking is performed.
1228 Effectively, booting a container once with
1229 <literal>guest
</literal> or
<literal>host
</literal> will link
1230 the journal persistently if further on the default of
1231 <literal>auto
</literal> is used.
</para>
1233 <para>Note that
<option>--link-journal=try-guest
</option> is the default if the
1234 <filename>systemd-nspawn@.service
</filename> template unit file is used.
</para></listitem>
1238 <term><option>-j
</option></term>
1240 <listitem><para>Equivalent to
1241 <option>--link-journal=try-guest
</option>.
</para></listitem>
1246 </refsect2><refsect2>
1247 <title>Mount Options
</title>
1252 <term><option>--bind=
</option></term>
1253 <term><option>--bind-ro=
</option></term>
1255 <listitem><para>Bind mount a file or directory from the host into the container. Takes one of: a path
1256 argument — in which case the specified path will be mounted from the host to the same path in the container, or
1257 a colon-separated pair of paths — in which case the first specified path is the source in the host, and the
1258 second path is the destination in the container, or a colon-separated triple of source path, destination path
1259 and mount options. The source path may optionally be prefixed with a
<literal>+
</literal> character. If so, the
1260 source path is taken relative to the image's root directory. This permits setting up bind mounts within the
1261 container image. The source path may be specified as empty string, in which case a temporary directory below
1262 the host's
<filename>/var/tmp
</filename> directory is used. It is automatically removed when the container is
1263 shut down. Mount options are comma-separated and currently, only
<option>rbind
</option> and
1264 <option>norbind
</option> are allowed, controlling whether to create a recursive or a regular bind
1265 mount. Defaults to
"rbind". Backslash escapes are interpreted, so
<literal>\:
</literal> may be used to embed
1266 colons in either path. This option may be specified multiple times for creating multiple independent bind
1267 mount points. The
<option>--bind-ro=
</option> option creates read-only bind mounts.
</para>
1269 <para>Note that when this option is used in combination with
<option>--private-users
</option>, the resulting
1270 mount points will be owned by the
<constant>nobody
</constant> user. That's because the mount and its files and
1271 directories continue to be owned by the relevant host users and groups, which do not exist in the container,
1272 and thus show up under the wildcard UID
65534 (nobody). If such bind mounts are created, it is recommended to
1273 make them read-only, using
<option>--bind-ro=
</option>.
</para></listitem>
1277 <term><option>--inaccessible=
</option></term>
1279 <listitem><para>Make the specified path inaccessible in the container. This over-mounts the specified path
1280 (which must exist in the container) with a file node of the same type that is empty and has the most
1281 restrictive access mode supported. This is an effective way to mask files, directories and other file system
1282 objects from the container payload. This option may be used more than once in case all specified paths are
1283 masked.
</para></listitem>
1287 <term><option>--tmpfs=
</option></term>
1289 <listitem><para>Mount a tmpfs file system into the container. Takes a single absolute path argument that
1290 specifies where to mount the tmpfs instance to (in which case the directory access mode will be chosen as
0755,
1291 owned by root/root), or optionally a colon-separated pair of path and mount option string that is used for
1292 mounting (in which case the kernel default for access mode and owner will be chosen, unless otherwise
1293 specified). Backslash escapes are interpreted in the path, so
<literal>\:
</literal> may be used to embed colons
1296 <para>Note that this option cannot be used to replace the root file system of the container with a temporary
1297 file system. However, the
<option>--volatile=
</option> option described below provides similar
1298 functionality, with a focus on implementing stateless operating system images.
</para></listitem>
1302 <term><option>--overlay=
</option></term>
1303 <term><option>--overlay-ro=
</option></term>
1305 <listitem><para>Combine multiple directory trees into one
1306 overlay file system and mount it into the container. Takes a
1307 list of colon-separated paths to the directory trees to
1308 combine and the destination mount point.
</para>
1310 <para>Backslash escapes are interpreted in the paths, so
1311 <literal>\:
</literal> may be used to embed colons in the paths.
1314 <para>If three or more paths are specified, then the last
1315 specified path is the destination mount point in the
1316 container, all paths specified before refer to directory trees
1317 on the host and are combined in the specified order into one
1318 overlay file system. The left-most path is hence the lowest
1319 directory tree, the second-to-last path the highest directory
1320 tree in the stacking order. If
<option>--overlay-ro=
</option>
1321 is used instead of
<option>--overlay=
</option>, a read-only
1322 overlay file system is created. If a writable overlay file
1323 system is created, all changes made to it are written to the
1324 highest directory tree in the stacking order, i.e. the
1325 second-to-last specified.
</para>
1327 <para>If only two paths are specified, then the second
1328 specified path is used both as the top-level directory tree in
1329 the stacking order as seen from the host, as well as the mount
1330 point for the overlay file system in the container. At least
1331 two paths have to be specified.
</para>
1333 <para>The source paths may optionally be prefixed with
<literal>+
</literal> character. If so they are taken
1334 relative to the image's root directory. The uppermost source path may also be specified as empty string, in
1335 which case a temporary directory below the host's
<filename>/var/tmp
</filename> is used. The directory is
1336 removed automatically when the container is shut down. This behaviour is useful in order to make read-only
1337 container directories writable while the container is running. For example, use the
1338 <literal>--overlay=+/var::/var
</literal> option in order to automatically overlay a writable temporary
1339 directory on a read-only
<filename>/var
</filename> directory.
</para>
1341 <para>For details about overlay file systems, see
<ulink
1342 url=
"https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt">overlayfs.txt
</ulink>. Note
1343 that the semantics of overlay file systems are substantially
1344 different from normal file systems, in particular regarding
1345 reported device and inode information. Device and inode
1346 information may change for a file while it is being written
1347 to, and processes might see out-of-date versions of files at
1348 times. Note that this switch automatically derives the
1349 <literal>workdir=
</literal> mount option for the overlay file
1350 system from the top-level directory tree, making it a sibling
1351 of it. It is hence essential that the top-level directory tree
1352 is not a mount point itself (since the working directory must
1353 be on the same file system as the top-most directory
1354 tree). Also note that the
<literal>lowerdir=
</literal> mount
1355 option receives the paths to stack in the opposite order of
1358 <para>Note that this option cannot be used to replace the root file system of the container with an overlay
1359 file system. However, the
<option>--volatile=
</option> option described above provides similar functionality,
1360 with a focus on implementing stateless operating system images.
</para></listitem>
1364 </refsect2><refsect2>
1365 <title>Input/Output Options
</title>
1369 <term><option>--console=
</option><replaceable>MODE
</replaceable></term>
1371 <listitem><para>Configures how to set up standard input, output and error output for the container
1372 payload, as well as the
<filename>/dev/console
</filename> device for the container. Takes one of
1373 <option>interactive
</option>,
<option>read-only
</option>,
<option>passive
</option>, or
1374 <option>pipe
</option>. If
<option>interactive
</option>, a pseudo-TTY is allocated and made available
1375 as
<filename>/dev/console
</filename> in the container. It is then bi-directionally connected to the
1376 standard input and output passed to
<command>systemd-nspawn
</command>.
<option>read-only
</option> is
1377 similar but only the output of the container is propagated and no input from the caller is read. If
1378 <option>passive
</option>, a pseudo TTY is allocated, but it is not connected anywhere. Finally, in
1379 <option>pipe
</option> mode no pseudo TTY is allocated, but the standard input, output and error
1380 output file descriptors passed to
<command>systemd-nspawn
</command> are passed on — as they are — to
1381 the container payload, see the following paragraph. Defaults to
<option>interactive
</option> if
1382 <command>systemd-nspawn
</command> is invoked from a terminal, and
<option>read-only
</option>
1385 <para>In
<option>pipe
</option> mode,
<filename>/dev/console
</filename> will not exist in the
1386 container. This means that the container payload generally cannot be a full init system as init
1387 systems tend to require
<filename>/dev/console
</filename> to be available. On the other hand, in this
1388 mode container invocations can be used within shell pipelines. This is because intermediary pseudo
1389 TTYs do not permit independent bidirectional propagation of the end-of-file (EOF) condition, which is
1390 necessary for shell pipelines to work correctly.
<emphasis>Note that the
<option>pipe
</option> mode
1391 should be used carefully
</emphasis>, as passing arbitrary file descriptors to less trusted container
1392 payloads might open up unwanted interfaces for access by the container payload. For example, if a
1393 passed file descriptor refers to a TTY of some form, APIs such as
<constant>TIOCSTI
</constant> may be
1394 used to synthesize input that might be used for escaping the container. Hence
<option>pipe
</option>
1395 mode should only be used if the payload is sufficiently trusted or when the standard
1396 input/output/error output file descriptors are known safe, for example pipes.
</para></listitem>
1400 <term><option>--pipe
</option></term>
1401 <term><option>-P
</option></term>
1403 <listitem><para>Equivalent to
<option>--console=pipe
</option>.
</para></listitem>
1406 <xi:include href=
"standard-options.xml" xpointer=
"no-pager" />
1407 <xi:include href=
"standard-options.xml" xpointer=
"help" />
1408 <xi:include href=
"standard-options.xml" xpointer=
"version" />
1413 <xi:include href=
"less-variables.xml" />
1416 <title>Examples
</title>
1420 <ulink url=
"https://getfedora.org">Fedora
</ulink> image and start a shell in it
</title>
1422 <programlisting># machinectl pull-raw --verify=no \
1423 https://download.fedoraproject.org/pub/fedora/linux/releases/
&fedora_latest_version;/Cloud/x86_64/images/Fedora-Cloud-Base-
&fedora_latest_version;-
&fedora_cloud_release;.x86_64.raw.xz \
1424 Fedora-Cloud-Base-
&fedora_latest_version;-
&fedora_cloud_release;.x86-
64
1425 # systemd-nspawn -M Fedora-Cloud-Base-
&fedora_latest_version;-
&fedora_cloud_release;.x86-
64</programlisting>
1427 <para>This downloads an image using
1428 <citerefentry><refentrytitle>machinectl
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1429 and opens a shell in it.
</para>
1433 <title>Build and boot a minimal Fedora distribution in a container
</title>
1435 <programlisting># dnf -y --releasever=
&fedora_latest_version; --installroot=/var/lib/machines/f
&fedora_latest_version; \
1436 --disablerepo='*' --enablerepo=fedora --enablerepo=updates install \
1437 systemd passwd dnf fedora-release vim-minimal glibc-minimal-langpack
1438 # systemd-nspawn -bD /var/lib/machines/f
&fedora_latest_version;</programlisting>
1440 <para>This installs a minimal Fedora distribution into the
1441 directory
<filename index=
"false">/var/lib/machines/f
&fedora_latest_version;</filename>
1442 and then boots that OS in a namespace container. Because the installation
1443 is located underneath the standard
<filename>/var/lib/machines/
</filename>
1444 directory, it is also possible to start the machine using
1445 <command>systemd-nspawn -M f
&fedora_latest_version;</command>.
</para>
1449 <title>Spawn a shell in a container of a minimal Debian unstable distribution
</title>
1451 <programlisting># debootstrap unstable ~/debian-tree/
1452 # systemd-nspawn -D ~/debian-tree/
</programlisting>
1454 <para>This installs a minimal Debian unstable distribution into
1455 the directory
<filename>~/debian-tree/
</filename> and then
1456 spawns a shell from this image in a namespace container.
</para>
1458 <para><command>debootstrap
</command> supports
1459 <ulink url=
"https://www.debian.org">Debian
</ulink>,
1460 <ulink url=
"https://www.ubuntu.com">Ubuntu
</ulink>,
1461 and
<ulink url=
"https://www.tanglu.org">Tanglu
</ulink>
1462 out of the box, so the same command can be used to install any of those. For other
1463 distributions from the Debian family, a mirror has to be specified, see
1464 <citerefentry project='die-net'
><refentrytitle>debootstrap
</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
1469 <title>Boot a minimal
1470 <ulink url=
"https://www.archlinux.org">Arch Linux
</ulink> distribution in a container
</title>
1472 <programlisting># pacstrap -c ~/arch-tree/ base
1473 # systemd-nspawn -bD ~/arch-tree/
</programlisting>
1475 <para>This installs a minimal Arch Linux distribution into the
1476 directory
<filename>~/arch-tree/
</filename> and then boots an OS
1477 in a namespace container in it.
</para>
1482 <ulink url=
"https://software.opensuse.org/distributions/tumbleweed">OpenSUSE Tumbleweed
</ulink>
1483 rolling distribution
</title>
1485 <programlisting># zypper --root=/var/lib/machines/tumbleweed ar -c \
1486 https://download.opensuse.org/tumbleweed/repo/oss tumbleweed
1487 # zypper --root=/var/lib/machines/tumbleweed refresh
1488 # zypper --root=/var/lib/machines/tumbleweed install --no-recommends \
1489 systemd shadow zypper openSUSE-release vim
1490 # systemd-nspawn -M tumbleweed passwd root
1491 # systemd-nspawn -M tumbleweed -b
</programlisting>
1495 <title>Boot into an ephemeral snapshot of the host system
</title>
1497 <programlisting># systemd-nspawn -D / -xb
</programlisting>
1499 <para>This runs a copy of the host system in a snapshot which is removed immediately when the container
1500 exits. All file system changes made during runtime will be lost on shutdown, hence.
</para>
1504 <title>Run a container with SELinux sandbox security contexts
</title>
1506 <programlisting># chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container
1507 # systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 \
1508 -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh
</programlisting>
1512 <title>Run a container with an OSTree deployment
</title>
1514 <programlisting># systemd-nspawn -b -i ~/image.raw \
1515 --pivot-root=/ostree/deploy/$OS/deploy/$CHECKSUM:/sysroot \
1516 --bind=+/sysroot/ostree/deploy/$OS/var:/var
</programlisting>
1521 <title>Exit status
</title>
1523 <para>The exit code of the program executed in the container is
1528 <title>See Also
</title>
1530 <citerefentry><refentrytitle>systemd
</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1531 <citerefentry><refentrytitle>systemd.nspawn
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1532 <citerefentry project='man-pages'
><refentrytitle>chroot
</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1533 <citerefentry project='mankier'
><refentrytitle>dnf
</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1534 <citerefentry project='die-net'
><refentrytitle>debootstrap
</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1535 <citerefentry project='archlinux'
><refentrytitle>pacman
</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1536 <citerefentry project='mankier'
><refentrytitle>zypper
</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1537 <citerefentry><refentrytitle>systemd.slice
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1538 <citerefentry><refentrytitle>machinectl
</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1539 <citerefentry project='man-pages'
><refentrytitle>btrfs
</refentrytitle><manvolnum>8</manvolnum></citerefentry>
projects / thirdparty / systemd.git / blob