Differences

This shows you the differences between two versions of the page.

--- omv7:docker_in_omv [2025/12/08 15:00] – [2.3 CONFIGURATION] chente
+++ omv7:docker_in_omv [2025/12/08 15:15] (current) – chente
@@ Line 161: / Line 161: @@
 \\
 \\
-==== 1. Installation ====
+=== 1. Installation ===
 {{ :omv7:dockeromv7-7.jpg?direct&1200 |Expand image -> Installation}}
-In OMV8's GUI:\\
+In OMV7's GUI:\\
-Under **SYSTEM > OMV-EXTRAS**, click the **DOCKER REPO** button and then click **SAVE**. This activates the Docker repository so you can install Docker and the Compose plugin.\\
+Under SYSTEM > OMV-EXTRAS Click on the DOCKER REPO button and click on the SAVE button. Now the docker repository is activated and you can install the compose plugin and docker.\\
-Next, go to **SYSTEM > PLUGINS**, find and select **openmediavault-compose 8.X**, and click **INSTALL**.
+Under SYSTEM > PLUGINS find and highlight **openmediavault-compose 7.X**, and click the INSTALL button.
   * Installing the openmediavault-compose plugin will also install the openmediavault-sharerootfs plugin as a dependency.
 \\
@@ Line 172: / Line 172: @@
 Warning
 </span></strong></td></tr><tr><td style="background-color:#FFE4A6;height:25px;width:380px;">
-Do not uninstall the openmediavault-sharerootfs plugin. It is a dependency of the openmediavault-compose. Uninstalling openmediavault-sharerootfs while openmediavault-compose is installed will also remove the openmediavault-compose plugin.
+Do not uninstall the openmediavault-sharerootfs plugin. It is a dependency of the openmediavault-compose plugin. Uninstalling openmediavault-sharerootfs when the openmediavault-compose plugin is installed will cause the openmediavault-compose plugin to be uninstalled.
 </tr></table></body></html>
 ----
-==== 2. Plugin Settings ====
+=== 2. Plugin Settings ===
-The first step is to define the folders where the different data is stored.
+The first step is to define some folders where the different data is stored. To do this, we go to the SERVICES > COMPOSE > SETTINGS tab.
-To do this, we go to **SERVICES > COMPOSE > SETTINGS**.
+There are many possible configurations on a NAS. First we will see a simple configuration and then we will see a somewhat more advanced configuration.
-There are many possible NAS layouts.
-First we will look a simple setup, and then a more advanced configuration.
-<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Beginners Info
-</span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;">
-Installing OMV on a USB flash drive may seem unusual to newcomers, but you may be surprised to learn that many professional-grade servers boot directly from USB devices.<br>
-This approach provides several advantages and no drawbacks:<br>
-<ul>
-  <li><b>System performance is unaffected</b>, since almost all operations run in RAM.</li>
-  <li>The <b>openmediavault-writecache plugin</b> protects the USB drive by minimizing unnecessary write operations, greatly extending its lifespan.</li>
-  <li><b>Backups become extremely simple</b>: just create an image of the USB drive using <i>usbimager</i> on your PC.</li>
-  <li><b>Restoring the system is even easier</b>: clone the image onto a new USB drive in minutes.</li>
-  <li><b>Docker benefits</b> because the SSD/NVMe storage remains free for containers, where high speed actually matters.</li>
-  <li>Using a USB drive also frees valuable <b>SATA or NVMe ports</b> on the motherboard.</li>
-</ul>
-If your system is already installed on a disk, you can easily migrate OMV to a USB flash drive using <b>omv-regen</b>.
-</tr></table></body></html>
 ----
-=== 2.1  SIMPLE OMV NAS SYSTEM ===
+== 2.1  SIMPLE OMV NAS SYSTEM ==
-In this simple setup, the OMV operating system runs from a USB stick, and there is a single data drive that stores all NAS data. On this drive we will configure Docker and all related folders.
+In the simple configuration we have the OMV operating system on a pendrive. We also have a drive that stores all the NAS data. In this unit we will configure docker and everything necessary.
-The following diagram shows a schematic example of this layout:
+The following image shows a schematic of this type of configuration.
 {{ :omv7:dockeromv7-28.jpg?direct&1200 |Expand image -> Docker folders - Simple NAS}}
-In this case, all required folders are located on the same drive, which makes the configuration very straightforward.
+In this case all the necessary folders are on the same drive so everything will be very simple. All of them will be inside the mount folder of that drive, something like ''/srv/dev-disk-by-uuid.../appdata'' for example.
-All folders will live under the mount point of that drive, for example: ''/srv/dev-disk-by-uuid.../appdata''
-Create these shared folders from the OMV GUI, then follow the explanations in section 2.3.
+Create those shared folders in the OMV GUI and follow the explanations in point 2.3. Just keep in mind that all paths in this case will be in the same mount folder of type ''/srv/disk-by-uuid-.../docker'' or ''/srv/disk-by-uuid-.../backup_compose'' since there is only one unit.
-Just keep in mind that, in this simple scenario, all paths will be inside the same mount folder—for example:
-  * ''/srv/dev-disk-by-uuid-…/docker''
-  * ''/srv/dev-disk-by-uuid-…/backup_compose''
-  * ...
-Since there is only one data drive, everything lives under the same location.
 ----
-=== 2.2 ADVANCED OMV NAS SYSTEM ===
+== 2.2 ADVANCED OMV NAS SYSTEM ==
-In more advanced setups, your system may look similar to the following example.
+In a more advanced configuration than the previous one we can find something like the following.
-The diagram below represents a typical OMV NAS layout. From this point onward, all explanations in the document will be based on this example system. Your own system will probably differ — simply adapt the configuration logic to match your real setup.
+The image below shows an example schematic that may be typical of any OMV NAS. The explanations in this document from now on will be based on this example system. Your system will probably be different, adapt the explanations to your real system.
-  * The OMV operating system is installed on a USB flash drive.
+  * The OMV operating system is installed on a pendrive.
-  * A mergerfs pool composed of three hard drives stores users’ large NAS data.
+  * A mergerfs pool has been configured with three drives where massive data of NAS users is stored.
-  * A separate hard drive stores NAS backup data.
+  * There is another hard drive where backups are made.
-  * A high-speed NVMe drive is used for Docker data.
+  * A high access speed NVMe drive stores Docker data.
+<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Beginners Info
+</span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;">
+Installing OMV on a pendrive may seem strange to a beginner, but you will also be surprised to know that a large part of professional-level servers boot from a pendrive.<br>
+Doing this has many advantages and no disadvantages. The speed of the system does not suffer at all since practically everything is done in RAM.<br>
+The longevity of the pendrive is guaranteed by the openmediavault-flashmemory plugin, which is responsible for avoiding excessive writing that could degrade it.<br>
+In addition to all this, it will be very easy to make backup copies, you will only have to make an image of that pendrive with usbimager on your PC. And even more important, restoring the system is extremely easy, cloning a pendrive from an image is very simple and fast.<br>
+And finally, from a docker point of view, installing OMV on a pendrive will make it easier for us to separate the operating system and docker, using that fast SSD or NVMe drive where it is really necessary, in the docker storage. The OMV pendrive will not occupy a SATA port or the NVMe port on the motherboard.<br>
+If your system is already installed and configured <b>you can easily move the OMV configuration to a pendrive with omv-regen</b>.
+</tr></table></body></html>
-On the right side, you can see how the plugin’s SETTINGS tab may look after applying this configuration. If your system is simpler or more complex, adjust the folder paths accordingly.
+On the right you can see how the plugin's SETTINGS tab could be configured following this diagram. If your system is simpler or more complicated, adapt it accordingly. A simpler system could be one drive for OMV and another drive for data, in which case just create all the necessary folders on the data drive.
 {{ :omv7:dockeromv7-6.png?direct&1400 |Expand image -> Docker folders - Typical NAS}}
 ----
-=== 2.3  CONFIGURATION ===
+== 2.3  CONFIGURATION ==
-In any case, the main recommendation here is to **keep Docker data separate from the OMV operating system**.
+In any case, the main recommendation here is to **keep docker data and the OMV operating system separate**.
+<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Beginners Info
+</span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;">
+<b>Separating Docker from the operating system unit offers several advantages</b> (this may surprise a user new to Linux, but things work differently on Linux than on Windows):<br>
+- If Docker is installed along with the operating system, Docker data will be lost if you need to reinstall OMV for any reason. For a possible reinstall of OMV, having the docker data on a separate drive only requires mounting that drive and everything is back up and running in a matter of minutes.<br>
+- Avoid rootfs filling problems. Depending on the number and type of containers, it is very possible to exhaust rootfs storage if docker is located next to the operating system, this causes a lot of problems.<br>
+- Allows you to place docker on a higher speed drive. The OMV operating system does not need to be on fast storage, it can live perfectly on a pendrive (just remember to install openmediavault-flashmemory to ensure the longevity of the pendrive). However, Docker containers will benefit from increased execution speed if docker is installed on a high-access speed drive, such as an SSD or NVMe.<br>
+- Installing OMV on a USB flash drive is a good idea. But installing docker also on that pendrive is detrimental to the pendrive because docker will perform continuous writes, penalizing the longevity of the pendrive despite openmediavault-flashmemory.<br>
+- If you don't have a fast drive you can install docker on one of the data drives. The applications won't go as fast but at least they will be separated from rootfs.
+</tr></table></body></html>
+<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Beginners Info
+</span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;">
+<b>Capacity of the disk drive dedicated to docker</b><br>
+This capacity depends on the number and type of containers you are going to configure. A minimum of 60GB or 100GB would be recommended.
+If you are going to use database containers like Jellyfin or Plex with very large libraries you may need more, perhaps 250GB or 500GB. Nextcloud can also take up a lot of space depending on how you use it.<br>
+</tr></table></body></html>
+**You can call these folders whatever you prefer**. In this document, the names that reflect the previous images have been adopted for illustrative purposes, but you can decide what you want to call them and how to locate them. Following this scheme, the folders are the following:
-**You can name these folders however you prefer.** In this document we use the names shown in the diagrams for clarity. The example folders are:
   * ''appdata''
   * ''data''
@@ Line 248: / Line 251: @@
   * ''docker''
-We will review them one by one below.
+We will see them below one by one:
-<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Beginners Info
-</span></strong></td></tr><tr><td style="background-color:#E6FEFF;padding:10px;width:380px;">
-<b>Why you should keep Docker off the OS drive</b> (this may surprise Windows users — Linux handles storage differently):<br>
-<ul>
-<li>If Docker lives on the same disk as the OS, a reinstallation of OMV will remove Docker data. Keeping Docker data on a separate drive makes recovery as simple as remounting that drive.</li>
-<li>Installing Docker on the OS disk can fill the root filesystem (rootfs). Depending on the number and type of containers, you can run out of rootfs space and cause system problems.</li>
-<li>Placing Docker on a faster drive (SSD or NVMe) improves container performance. OMV itself can run well from a USB flash drive (use <i>openmediavault-writecache</i>), while Docker benefits from high-speed storage.</li>
-<li>Do not put Docker on the OMV USB flash drive: Docker does continuous writes and will reduce the flash drive’s lifespan even with write caching enabled.</li>
-<li>If you don't have a fast spare drive, putting Docker on one of your data drives is better than keeping it on the OS disk — performance is lower, but rootfs remains protected.</li>
-</ul>
-</td></tr></table></body></html>
-\\
-<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Beginners Info
-</span></strong></td></tr><tr><td style="background-color:#E6FEFF;padding:10px;width:380px;">
-<b>Recommended capacity for the Docker drive</b><br>
-Required size depends on the number and type of containers. A sensible minimum is **60–100 GB**. If you run media servers (Jellyfin, Plex) with very large libraries, consider **250–500 GB** or more. Nextcloud can also require significant storage depending on your usage.
-</td></tr></table></body></html>
 \\
 <html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Note
-</span></strong></td></tr><tr><td style="background-color:#E6FEFF;padding:10px;width:380px;">
+</span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;">
-If your NAS already contains data, you probably already have a data folder (it may use a different name). Select that folder in the plugin settings if appropriate.
+If you already have data on the NAS you will probably already have the data folder created, not necessarily with the same name.
-</td></tr></table></body></html>
+</tr></table></body></html>
 \\
-== 2.3.1 appdata folder ==
+''appdata''
-\\
   * WHAT IS APPDATA FOLDER:
-    * The plugin creates the //appdata// folder to store copies of the compose files it generates (both the .yml file and the .env file). These copies act as backups — do not edit them manually (always use the plugin GUI).
+    * This folder contains the configuration files and persistent data for the containers by default.
-    * The plugin also generates a global.env file in the appdata root. Do not edit this file manually — it is automatically overwritten.
+    * The plugin will create subfolders inside the //appdata// folder for each compose file we generate. The name of each subfolder will be the same as the compose file. This subfolder will contain a copy of the //yml// file and the //env// file generated in the GUI. These are just backups, they should not be modified except in the plugin GUI.
-    * The procedure expected by the plugin would be to create a second folder in which to store persistent container data.
-    * However, many users — including myself — also use this folder to store persistent container data. It works perfectly //as long as you create a dedicated subfolder// inside each container folder.
-    * This is important because the plugin sets special permissions on every container directory it creates. If you mount a Docker volume directly into one of those folders, Docker may change the permissions and break the container or the plugin. Creating a subfolder prevents this and keeps everything safe.
-    * If you prefer to separate the persistent data into another folder, you can do so without any problem. In this document we will place persistent data in subfolders within //appdata//.
     *...<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Beginners Info
 </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;">
-Each container is defined by two files: the <i>yml</i> (service definitions: image, volumes, ports, etc.) and the <i>env</i> (environment variables for that container). You do not need to edit the env file manually for common tasks.
+Each container is created using two configuration files. The <i>yml</i> file contains the container operation definitions, such as the image that is downloaded, the volumes and/or ports transferred to the host, etc. The <i>env</i> file contains environment variables for that particular container. Don't worry about this last file, you won't need it for now.
 </tr></table></body></html>
-\\
+    * In the root of this folder the global environmental variables file generated by the plugin with the name ''global.env'' will be stored. We just need to know that this file is stored there, do not modify it manually or it will be overwritten.
-  * HOW TO CONFIGURE THE APPDATA FOLDER:
+  * CONFIGURE THE APPDATA FOLDER:
     * Create the //appdata// shared folder in the OMV GUI.
     *...<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Beginners Info
 </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;">
-To create a shared folder: go to <b>STORAGE &gt; SHARED FOLDERS</b> and click <b>+ CREATE</b>.<br>
+To create shared folders, for example the <i>appdata</i> folder in the OMV GUI go to STORAGE > SHARED FOLDERS and Click +CREATE button.<br>
-- NAME: <i>appdata</i><br>
+- In the NAME field type -> appdata<br>
-- FILE SYSTEM: choose the SSD/NVMe or drive you want to use<br>
+- In the FILE SYSTEM field, select the SSD or NVMe disk or the one that interests you.<br>
-- Click <b>SAVE</b><br>
+- Press SAVE button.
 </tr></table></body></html>
-    * In the plugin’s SETTINGS → COMPOSE FILES section, select the //appdata// shared folder from the drop-down and click SAVE.
+    * Return to the plugin's SETTINGS tab, click on the SHARED FOLDER field in the COMPOSE FILES section and from the drop-down menu select the //appdata// folder you created.
+    * Press the SAVE button.
     *...<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Beginners Info
 </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;">
-This folder will store the persistent data of each container. Example for Jellyfin config:<br>
+We can store persistent container data in this folder. For example, for the Jellyfin config folder we would do the following:<br>
-<b>/srv/dev-disk-by-uuid-.../appdata/jellyfin/config:/config</b><br>
+<b>- /srv/dev-disk-by-uuid-9d43cda9-20e5-474f-b38b-6b2b6c03211a/appdata/jellyfin/config:/config</b><br>
-When the container starts, Docker will create missing subfolders (for example, <i>jellyfin</i> and <i>config</i>) automatically.<br>
+Where <b>/srv/dev-disk-by-uuid-9d43cda9-20e5-474f-b38b-6b2b6c03211a/appdata</b> is the absolute path to the <i>appdata</i> folder. You can copy it from the OMV GUI in the STORAGE > SHARED FOLDERS tab in the ABSOLUTE PATH column. When you start the container, Docker will create the <i>jellyfin</i> and <i>config</i> subfolders if they do not exist.<br>
-Don't worry for now, we'll see it with examples later.
+Later you can see this with examples.
 </tr></table></body></html>
     *...<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#FFB663;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160;
 Warning
 </span></strong></td></tr><tr><td style="background-color:#FFE4A6;height:25px;width:380px;">
-Always create a subfolder inside each container directory in <i>appdata</i> to store persistent data.<br><br>
+Make sure to create subfolders within each appdata folder for each container folder.<br>
-❌ <b>Do NOT do this:</b><br>
+Don't do this: <b>- /srv/dev-disk-by-uuid-9d43cda9-20e5-474f-b38b-6b2b6c03211a/appdata/jellyfin:/config</b><br>
-/srv/.../appdata/jellyfin:/config<br>
+If you do this, the persistent data in the config folder will be mixed with the plugin's Docker files, and permissions could change without warning.<br>
-→ Docker writes directly inside <i>appdata/jellyfin</i> and modifies its permissions.<br><br>
+Do this: <b>- /srv/dev-disk-by-uuid-9d43cda9-20e5-474f-b38b-6b2b6c03211a/appdata/jellyfin/config:/config</b><br>
-✔️ <b>Do this instead:</b><br>
+This way, the permissions will remain as created by the container.
-/srv/.../appdata/jellyfin/config:/config<br>
-→ Keeps data isolated and preserves the plugin’s permissions.
 </tr></table></body></html>
     *...<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#2C6700;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Advanced configuration.
 </span></strong></td></tr><tr><td style="background-color:#e7fae1;height:25px;width:380px;">
-The compose plugin supports <b>relative paths</b> in volume definitions. Using relative paths ensures the data is stored in the correct subfolder.<br><br>
+Relative paths are supported by the compose plugin. If we use relative paths for volumes in containers, those volumes will be generated in these subfolders. For example, if we create a Jellyfin container and define this volume: <br>
-Example for Jellyfin:<br>
 <b>- ./config:/config</b><br>
-This creates:<br>
+the configuration folder will be created in the subfolder of that container in this case: <br>
-<b>/appdata/jellyfin/config</b><br><br>
+<b>/appdata/jellyfin/config</b><br>
+In addition to relative paths the compose plugin also supports symlinks to define volume paths. You can use the openmediavault-symlinks plugin to create them in the OMV GUI and combine both systems or use just one of them.
-The plugin also supports <b>symlinks</b> to define volume paths.
-You can create them with the <i>openmediavault-symlinks</i> plugin or manually.
-Both systems (relative paths and symlinks) can be combined.
 </tr></table></body></html>
 \\
-== 2.3.2 data folder ==
+''data''
-\\
   * WHAT IS DATA FOLDER:
-    * The data folder is basically a shortcut to a shared folder that can be used in compose files to define the location of a container volume.
+    * Use of this field is optional. This field in the plugin configuration allows you to define a path to a shared folder using the ''CHANGE_TO_COMPOSE_DATA_PATH'' variable. Later we will see how to use this variable in a compose file. The plugin allows you to use example compose files that are already preconfigured with this variable. In the GUI you can see a note that says: "Optional - Location of container persistent data", this was the goal when the plugin was created since at that time environment variables were not supported for paths in the bakup utility of the complement. At this point that is no longer a problem and all paths can be defined in the environment variables file.
-    * When a container is started, the ''CHANGE_TO_COMPOSE_DATA_PATH'' variable defined in the compose file is automatically replaced with the shared folder you configure here.
+    * In order to put this field to useful use, despite the legend in the GUI about persistent data, we will use this variable to define the path to the system data folder. This is more useful considering the system configuration we have designed as an example, but you can use this field to define the route you want. By user data we understand the main storage file system where you will have most of the data, such as movies or other types of files.
-    * You must configure this folder if you plan to use the plugin’s example compose files, as they rely on this variable.
+    * If you have more than one folder of these characteristics in different file systems, you will only be able to choose one of them to use the ''CHANGE_TO_COMPOSE_DATA_PATH'' variable. In that case, you will have to define the rest of the folder paths by other means, such as the global environmental variables file, for example.
-    * You can choose any shared folder for this purpose; it does not need to be named "data".
+    * ...<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Note
-\\
+</span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;">
-  * HOW TO CONFIGURE THE DATA FOLDER:
+If you don't have a fast drive for Docker, you can configure the <i>data</i> and <i>appdata</i> folders in the same shared folder. This will make the CHANGE_TO_COMPOSE_DATA_PATH variable serve to define the path of both. This is how the plugin example files are preconfigured.
-    * In the plugin configuration, under the DATA section, select the shared folder you want to assign to CHANGE_TO_COMPOSE_DATA_PATH.
+</tr></table></body></html>
-    * Click SAVE.
+    * ...<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Beginners Info
+</span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;">
+The internal structure described in the "data" folder is unimportant. In this document, a "standard" structure has simply been described for illustrative purposes, so that the reader has a general idea about what the content of that folder may be. You can distribute within that folder any directory tree that you feel comfortable with.
+</tr></table></body></html>
+  * CONFIGURE THE DATA FOLDER:
+    * If your server is already running, you will already have this folder created. In this case, simply open the SHARED FOLDER field in the DATA section and select the shared folder (it doesn't matter if the name is different than //data//).
+    * If it is a new installation and you still do not have data on the server nor have you created that folder, you can create it in the OMV GUI and select it in the mentioned field of the plugin configuration.
+    * Press SAVE button.
 \\
-== 2.3.3 backup_compose folder ==
+''backup_compose''
-\\
   * WHAT IS BACKUP_COMPOSE FOLDER:
-    * The compose plugin allows you to schedule automatic backups of each container’s persistent data.
+    * The compose plugin allows you to schedule automatic backups of persistent container data. Those backups will be stored in this folder.
-    * All scheduled backups created by the plugin are stored in this folder.
+  * CONFIGURE THE BACKUP_COMPOSE FOLDER:
-\\
-  * HOW TO CONFIGURE THE BACKUP_COMPOSE FOLDER:
     * Create the //backup_compose// shared folder in the OMV GUI and select it in the compose plugin settings in the BACKUP section.
     *...<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Note
 </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;">
-In the system diagram of this document, the <i>backup_compose</i> folder is located on the NVMe drive rather than on the dedicated backup drive.<br><br>
+In the system diagram of this document the backup_compose folder has been configured on the NVMe drive instead of the dedicated backup drive for the following reason.<br>
-The plugin’s scheduled backup function is designed to produce a consistent and up-to-date copy of your persistent data by temporarily stopping the containers during the backup and starting them again afterward. Since each backup overwrites the previous one, this folder is ideal for use together with a separate backup application, which can then create versioned and/or compressed backups <b>without needing to stop the containers</b>.<br><br>
+The primary purpose of the compose plugin's scheduled backup utility is to obtain a copy of persistent data when containers are stopped. The plugin is responsible for stopping the containers, backing them up and starting them again. This allows you to obtain a consistent copy. The next copy will overwrite the previous one (via rsync), so you will always only have the latest one.<br>
-If you prefer, you can place this folder directly on your backup drive instead — both approaches are valid.
+This makes it easier to later use a specialized bakcups application that is capable of generating versioned and/or compressed backups of that copy generated by the plugin.<br>
+If you prefer, you can configure that folder on the backup disk as well.
 </tr></table></body></html>
 \\
-== 2.3.4 docker folder ==
+''docker''
-\\
   * WHAT IS DOCKER FOLDER:
-    * This folder contains Docker’s internal data: downloaded images, layer data, and various runtime metadata required for Docker to operate.
+    * This folder contains the files that docker uses internally, such as downloaded images and other information necessary for docker to function.
-    * Under normal circumstances, **there is no need to preserve** the contents of this folder across a reinstallation of OMV. Everything stored here can be automatically recreated or re-downloaded when containers start.
+    * Unless you have special configurations, there is no need to preserve the data in this folder against a possible reinstallation of OMV, since everything in it is automatically downloaded if necessary each time a container is started. But it is convenient to locate this folder separate from rootfs to avoid problems.
-    * However, it is strongly recommended to **keep this folder off the root filesystem** (/) to avoid filling up the OS drive and to prevent performance issues.
+    * The plugin allows you to locate this folder somewhere else easily, simply go to the plugin's settings tab and in the DOCKER STORAGE field of the DOCKER section define the new path. By default this path is ''/var/lib/docker'' and it is located in the OMV file system, that is what we must change.
-    * The compose plugin allows you to relocate this folder easily. In the plugin settings, under the DOCKER section, set the DOCKER STORAGE field to the new path. By default, Docker uses /var/lib/docker on the OMV root filesystem, which you should normally change.
+    * To define this route it is necessary to define the complete route. Symlinks can sometimes cause problems.
-    * When defining this path, always use the **full absolute path**. Avoid symlinks — they can cause unexpected issues with Docker.
+  * CONFIGURE THE DOCKER FOLDER:
-\\
+    * Create the //docker// shared folder in the OMV GUI.
-  * HOW TO CONFIGURE THE DOCKER FOLDER:
+    * In the STORAGE > SHARED FOLDERS tab, look for the absolute path of the //docker// folder in the ABSOLUTE PATH column (if the column is closed, open it using the icon at the top right). Next to the path there is an icon that allows you to copy the path to the clipboard. Paste it in the corresponding field according to the previous image.
-    * Create a shared folder named //docker// in the OMV GUI.
-    * Go to STORAGE → SHARED FOLDERS and locate the absolute path of the docker shared folder in the ABSOLUTE PATH column (expand the column if needed using the icon in the top-right corner).
-    * Click the copy icon next to the path and paste it into the corresponding field in the compose plugin settings.
     *...<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#FFB663;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160;
 Warning
 </span></strong></td></tr><tr><td style="background-color:#FFE4A6;height:25px;width:380px;">
-<b>The filesystem hosting the docker folder should preferably be EXT4</b>.<br>
+<b>The file system where the docker folder is should preferably be EXT4</b>.<br>
-If you need to place it on <b>ZFS</b> or <b>BTRFS</b> file system, consult the official Docker documentation for the required configuration.<br>
+If you need to locate this folder on a <b>ZFS</b> or <b>BTRFS</b> file system, consult the corresponding documentation on the docker website to learn how to do it.<br>
-<b>Never use an NTFS</b> file system for Docker data — it does not work and will lead to failures. (or generally for anything on linux other than a staging mount for copying data).<br>
+<b>Never use an NTFS</b> file system to host docker folders, it won't work (or generally for anything on linux other than a staging mount for copying data).<br>
-Do not place the Docker folder in a <b>mergerfs</b> pool, as Docker will spread its internal files across multiple drives, eventually causing corruption or operational problems.<br>
+Do not place the docker folder in a <b>merges</b> pool, as this causes the docker files to be spread across several drives and ends up causing operating problems. If you do not have available units other than those contained in the mergerfs pool you can do the following:<br>
-If the only storage available is inside a mergerfs pool, you may:
+- Create the docker folder on one of the drives that make up the mergerfs pool instead of creating it in the pool, and use the absolute path of that drive in the compose plugin GUI to locate the docker folder.<br>
-- Create the Docker folder directly on a specific drive that belongs to the pool instead of inside the pool, and configure the plugin using the absolute path of that drive.
+- Don't use the mergerfs rebalance feature on that pool, the docker data could end up on a different drive and be lost.
-- Avoid using mergerfs rebalance on that pool, as it may move Docker’s files to another drive and break Docker.
 </tr></table></body></html>
     *...<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#2C6700;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160; Advanced configuration.
 </span></strong></td></tr><tr><td style="background-color:#e7fae1;height:25px;width:380px;">
-You can <b>manually edit /etc/docker/daemon.json to customize</b> Docker’s behaviour.<br>
+You can <b>customize the /etc/docker/daemon.json file</b> manually to customize the options. Doing this is useful for setting the driver for an nvidia card or for the driver for a different file system.<br>
-This is required, for example, to configure an NVIDIA GPU driver or to set a custom storage driver for certain filesystems.<br>
+If you need to customize this file just leave the Docker storage field blank, the plugin will not modify the file.
-If you need to customize this file, simply <b>leave the Docker storage field empty</b> in the plugin settings — the plugin will not modify the file.<br>
 </tr></table></body></html>