Add section about pveproxy certificates

[pve-docs.git] / pct.adoc

diff --git a/pct.adoc b/pct.adoc
index e5107958a1a9d3763ba07d5b2a55e18ea8b2332f..e9f399e3196a0bea7b9ad6c06df7a96cd281e7df 100644 (file)
--- a/pct.adoc
+++ b/pct.adoc
@@ -101,11 +101,13 @@ unprivileged containers are safe by design.
 Configuration
 -------------
 
-The '/etc/pve/lxc/<CTID>.conf' files stores container configuration,
-where '<CTID>' is the numeric ID of the given container. Note that
-CTIDs < 100 are reserved for internal purposes, and CTIDs need to be
-unique cluster wide. Files are stored inside '/etc/pve/', so they get
-automatically replicated to all other cluster nodes.
+The '/etc/pve/lxc/<CTID>.conf' file stores container configuration,
+where '<CTID>' is the numeric ID of the given container. Like all
+other files stored inside '/etc/pve/', they get automatically
+replicated to all other cluster nodes.
+
+NOTE: CTIDs < 100 are reserved for internal purposes, and CTIDs need to be
+unique cluster wide.
 
 .Example Container Configuration
 ----
@@ -372,6 +374,62 @@ Files
 Configuration file for the container '<CTID>'.
 
 
+Container Mountpoints
+---------------------
+
+Beside the root directory the container can also have additional mountpoints.
+Currently there are basically three types of mountpoints: storage backed
+mountpoints, bind mounts and device mounts.
+
+Storage backed mountpoints are managed by the {pve} storage subsystem and come
+in three different flavors:
+
+- Image based: These are raw images containing a single ext4 formatted file
+  system.
+- ZFS Subvolumes: These are technically bind mounts, but with managed storage,
+  and thus allow resizing and snapshotting.
+- Directories: passing `size=0` triggers a special case where instead of a raw
+  image a directory is created.
+
+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
+unprivileged containers you might run into permission problems caused by the
+user mapping, and cannot use ACLs from inside an unprivileged container.
+
+Similarly device mounts are not managed by the storage, but for these the
+`quota` and `acl` options will be honored.
+
+
+Using quotas inside containers
+------------------------------
+
+Quotas allow to set limits inside a container for the amount of disk space
+that each user can use.
+This only works on ext4 image based storage types and currently does not work
+with unprivileged containers.
+
+Activating the `quota` option causes the following mount options to be used for
+a mountpoint: `usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0`
+
+This allows quotas to be used like you would on any other system. You can
+initialize the `/aquota.user` and `/aquota.group` files by running
+
+ quotacheck -cmug /
+ quotaon /
+
+and edit the quotas via the `edquota` command. Refer to the documentation
+of the distribution running inside the container for details.
+
+NOTE: You need to run the above commands for every mountpoint by passing
+the mountpoint's path instead of just `/`.
+
+Using ACLs inside containers
+----------------------------
+
+The standard Posix Access Control Lists are also available inside containers. 
+ACLs allow you to set more detailed file ownership than the traditional user/
+group/others model.
+
 Container Advantages
 --------------------