Currently there are basically three types of mount points: storage backed
mount points, bind mounts and device mounts.
-.Storage backed mount points
+.Typical Container `rootfs` configuration
+----
+rootfs: thin1:base-100-disk-1,size=8G
+----
+
+
+Storage backed mount points
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
Storage backed mount points are managed by the {pve} storage subsystem and come
in three different flavors:
- Directories: passing `size=0` triggers a special case where instead of a raw
image a directory is created.
-.Bind mount points
+
+Bind mount points
+^^^^^^^^^^^^^^^^^
+
+Bind mounts allow you to access arbitrary directories from your Proxmox VE host
+inside a container. Some potential use cases are:
+
+- Accessing your home directory in the guest
+- Accessing an USB device directory in the guest
+- Accessing an NFS mount from the host in the guest
Bind mounts are considered to not be managed by the storage subsystem, so you
-cannot make snapshots or deal with quotas from inside the container, and with
+cannot make snapshots or deal with quotas from inside the container. With
unprivileged containers you might run into permission problems caused by the
-user mapping, and cannot use ACLs from inside an unprivileged container.
+user mapping and cannot use ACLs.
+
+NOTE: The contents of bind mount points are not backed up when using 'vzdump'.
WARNING: For security reasons, bind mounts should only be established
using source directories especially reserved for this purpose, e.g., a
directory hierarchy under `/mnt/bindmounts`. Never bind mount system
directories like `/`, `/var` or `/etc` into a container - this poses a
-great security risk. The bind mount source path must not contain any symlinks.
+great security risk.
+
+NOTE: The bind mount source path must not contain any symlinks.
+
+For example, to make the directory `/mnt/bindmounts/shared` accessible in the
+container with ID `100` under the path `/shared`, use a configuration line like
+'mp0: /mnt/bindmounts/shared,mp=/shared' in '/etc/pve/lxc/100.conf'.
+Alternatively, use 'pct set 100 -mp0 /mnt/bindmounts/shared,mp=/shared' to
+achieve the same result.
-.Device mount points
-Similar to bind mounts, device mounts are not managed by the storage, but for
-these the `quota` and `acl` options will be honored.
+Device mount points
+^^^^^^^^^^^^^^^^^^^
-.FUSE mounts
+Device mount points allow to mount block devices of the host directly into the
+container. Similar to bind mounts, device mounts are not managed by {PVE}'s
+storage subsystem, but the `quota` and `acl` options will be honored.
+
+NOTE: Device mount points should only be used under special circumstances. In
+most cases a storage backed mount point offers the same performance and a lot
+more features.
+
+NOTE: The contents of device mount points are not backed up when using 'vzdump'.
+
+
+FUSE mounts
+~~~~~~~~~~~
WARNING: Because of existing issues in the Linux kernel's freezer
subsystem the usage of FUSE mounts inside a container is strongly
technologies, it is possible to establish the FUSE mount on the Proxmox host
and use a bind mount point to make it accessible inside the container.
-.Typical Container `rootfs` configuration
-----
-rootfs: thin1:base-100-disk-1,size=8G
-----
-
Using quotas inside containers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are two basic restore modes, only differing by their handling of mount
points:
-."Simple" restore mode
+
+"Simple" restore mode
+^^^^^^^^^^^^^^^^^^^^^
If neither the `rootfs` parameter nor any of the optional `mpX` parameters
are explicitly set, the mount point configuration from the backed up
This simple mode is also used by the container restore operations in the web
interface.
-."Advanced" restore mode
+
+"Advanced" restore mode
+^^^^^^^^^^^^^^^^^^^^^^^
By setting the `rootfs` parameter (and optionally, any combination of `mpX`
parameters), the 'pct restore' command is automatically switched into an