container. In many ways it is similar to
<citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
but more powerful since it fully virtualizes the file
- system hierachy, as well as the process tree, the
+ system hierarchy, as well as the process tree, the
various IPC subsystems and the host and domain
name.</para>
<para>Note that <command>systemd-nspawn</command> will
mount file systems private to the container to
<filename>/dev</filename>,
- <filename>/dev/.run</filename> and similar. These will
+ <filename>/run</filename> and similar. These will
not be visible outside of the container, and their
contents will be lost when the container exits.</para>
<para>Note that running two
<command>systemd-nspawn</command> containers from the
same directory tree will not make processes in them
- see each other. The PID namespace seperation of the
+ see each other. The PID namespace separation of the
two containers is complete and the containers will
share very few runtime objects except for the
underlying file system.</para>
used.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><option>--user=</option></term>
+ <term><option>--u</option></term>
+
+ <listitem><para>Run the command
+ under specified user, create home
+ directory and cd into it. As rest
+ of systemd-nspawn, this is not
+ the security feature and limits
+ against accidental changes only.
+ </para></listitem>
+ </varlistentry>
+
</variablelist>
</refsect1>