| Both sides previous revision Previous revision Next revision | Previous revision |
| docs_in_draft:docker_in_omv [2025/12/07 15:11] – chente | docs_in_draft:docker_in_omv [2025/12/08 19:06] (current) – [1. Choose a container] chente |
|---|
| \\ | \\ |
| \\ | \\ |
| === 1. Installation === | |
| | ==== 1. Installation ==== |
| |
| {{ :omv7:dockeromv7-7.jpg?direct&1200 |Expand image -> Installation}} | {{ :omv7:dockeromv7-7.jpg?direct&1200 |Expand image -> Installation}} |
| In OMV7's GUI:\\ | In OMV8's GUI:\\ |
| 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.\\ | 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 > PLUGINS find and highlight **openmediavault-compose 7.X**, and click the INSTALL button. | Next, go to **SYSTEM > PLUGINS**, find and select **openmediavault-compose 8.X**, and click **INSTALL**. |
| * Installing the openmediavault-compose plugin will also install the openmediavault-sharerootfs plugin as a dependency. | * Installing the openmediavault-compose plugin will also install the openmediavault-sharerootfs plugin as a dependency. |
| \\ | \\ |
| Warning | Warning |
| </span></strong></td></tr><tr><td style="background-color:#FFE4A6;height:25px;width:380px;"> | </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 plugin. Uninstalling openmediavault-sharerootfs when the openmediavault-compose plugin is installed will cause the openmediavault-compose plugin to be uninstalled. | 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. |
| </tr></table></body></html> | </tr></table></body></html> |
| |
| ---- | ---- |
| |
| === 2. Plugin Settings === | ==== 2. Plugin Settings ==== |
| |
| 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. | The first step is to define the folders where the different data is stored. |
| 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. | To do this, we go to **SERVICES > COMPOSE > SETTINGS**. |
| | |
| | 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%;">  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 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. | 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. |
| |
| The following image shows a schematic of this type of configuration. | The following diagram shows a schematic example of this layout: |
| |
| {{ :omv7:dockeromv7-28.jpg?direct&1200 |Expand image -> Docker folders - Simple NAS}} | {{ :omv7:dockeromv7-28.jpg?direct&1200 |Expand image -> Docker folders - Simple NAS}} |
| |
| 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. | In this case, all required folders are located on the same drive, which makes the configuration very straightforward. |
| | All folders will live under the mount point of that drive, for example: ''/srv/dev-disk-by-uuid.../appdata'' |
| |
| 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. | Create these shared folders from the OMV GUI, then follow the explanations in section 2.3. |
| | 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 a more advanced configuration than the previous one we can find something like the following. | In more advanced setups, your system may look similar to the following example. |
| |
| 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 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 OMV operating system is installed on a pendrive. | * The OMV operating system is installed on a USB flash drive. |
| * A mergerfs pool has been configured with three drives where massive data of NAS users is stored. | * A mergerfs pool composed of three hard drives stores users’ large NAS data. |
| * There is another hard drive where backups are made. | * A separate hard drive stores NAS backup data. |
| * A high access speed NVMe drive stores Docker data. | * A high-speed NVMe drive is used for 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%;">  Beginners Info | 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. |
| </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 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}} | {{ :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 and the OMV operating system separate**. | In any case, the main recommendation here is to **keep Docker data separate from the OMV operating system**. |
| | |
| <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%;">  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%;">  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'' | * ''appdata'' |
| * ''data'' | * ''data'' |
| * ''backup_compose'' | * ''backup_compose'' |
| * ''docker'' | * ''docker'' |
| | (These names match the diagrams in this document. You can create the shared folder with any name you prefer; the plugin will work the same.) |
| | |
| | We will review them one by one below. |
| | |
| | <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%;">  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%;">  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> |
| |
| 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%;">  Note | <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%;">  Note |
| </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#E6FEFF;padding:10px;width:380px;"> |
| If you already have data on the NAS you will probably already have the data folder created, not necessarily with the same name. | 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. |
| </tr></table></body></html> | </td></tr></table></body></html> |
| |
| \\ | \\ |
| | == 2.3.1 appdata folder == |
| ''appdata'' | ''appdata'' |
| |
| | (This name matches the diagrams in this document. You can create the shared folder with any name you prefer; the plugin will work the same.) |
| | \\ |
| * WHAT IS APPDATA FOLDER: | * WHAT IS APPDATA FOLDER: |
| * This folder contains the configuration files and persistent data for the containers by default. | * 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). |
| * 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 plugin also generates a global.env file in the appdata root. Do not edit this file manually — it is automatically overwritten. |
| | * 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%;">  Beginners Info | *...<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%;">  Beginners Info |
| </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> |
| 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. | 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. |
| </tr></table></body></html> | </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. | \\ |
| * CONFIGURE THE APPDATA FOLDER: | * HOW TO CONFIGURE THE APPDATA FOLDER: |
| * Create the //appdata// shared folder in the OMV GUI. | * In the plugin’s SETTINGS → COMPOSE FILES section, click the **+** button next to the SHARED FOLDER field to create a new shared folder, or select an existing one if you already have it. |
| | * If creating a new folder: |
| | * NAME: <i>appdata</i> |
| | * FILE SYSTEM: choose the SSD/NVMe or drive you want to use |
| | * Click <b>SAVE</b> |
| | * Once selected, click **SAVE** in the plugin settings to apply the choice. |
| *...<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%;">  Beginners Info | *...<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%;">  Beginners Info |
| </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> |
| 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> | This folder will store the persistent data of each container. Example for Jellyfin config:<br> |
| - In the NAME field type -> appdata<br> | <b>/srv/dev-disk-by-uuid-.../appdata/jellyfin/config:/config</b><br> |
| - In the FILE SYSTEM field, select the SSD or NVMe disk or the one that interests you.<br> | When the container starts, Docker will create missing subfolders (for example, <i>jellyfin</i> and <i>config</i>) automatically.<br> |
| - Press SAVE button. | Don't worry for now, we'll see it with examples later. |
| </tr></table></body></html> | |
| * 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%;">  Beginners Info | |
| </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> | |
| 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-9d43cda9-20e5-474f-b38b-6b2b6c03211a/appdata/jellyfin/config:/config</b><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> | |
| Later you can see this with examples. | |
| </tr></table></body></html> | </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%;">  | *...<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%;">  |
| Warning | Warning |
| </span></strong></td></tr><tr><td style="background-color:#FFE4A6;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#FFE4A6;height:25px;width:380px;"> |
| Make sure to create subfolders within each appdata folder for each container folder.<br> | Always create a subfolder inside each container directory in <i>appdata</i> to store persistent data.<br><br> |
| Don't do this: <b>- /srv/dev-disk-by-uuid-9d43cda9-20e5-474f-b38b-6b2b6c03211a/appdata/jellyfin:/config</b><br> | ❌ <b>Do NOT do this:</b><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> | /srv/.../appdata/jellyfin:/config<br> |
| Do this: <b>- /srv/dev-disk-by-uuid-9d43cda9-20e5-474f-b38b-6b2b6c03211a/appdata/jellyfin/config:/config</b><br> | → Docker writes directly inside <i>appdata/jellyfin</i> and modifies its permissions.<br><br> |
| This way, the permissions will remain as created by the container. | ✔️ <b>Do this instead:</b><br> |
| | /srv/.../appdata/jellyfin/config:/config<br> |
| | → Keeps data isolated and preserves the plugin’s permissions. |
| </tr></table></body></html> | </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%;">  Advanced configuration. | *...<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%;">  Advanced configuration. |
| </span></strong></td></tr><tr><td style="background-color:#e7fae1;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#e7fae1;height:25px;width:380px;"> |
| 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> | 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> |
| | |
| | Example for Jellyfin:<br> |
| <b>- ./config:/config</b><br> | <b>- ./config:/config</b><br> |
| the configuration folder will be created in the subfolder of that container in this case: <br> | This creates:<br> |
| <b>/appdata/jellyfin/config</b><br> | <b>/appdata/jellyfin/config</b><br><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> | </tr></table></body></html> |
| |
| \\ | \\ |
| | == 2.3.2 data folder == |
| ''data'' | ''data'' |
| |
| | (This name matches the diagrams in this document. You can create the shared folder with any name you prefer; the plugin will work the same.) |
| | \\ |
| * WHAT IS DATA FOLDER: | * WHAT IS DATA FOLDER: |
| * 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. | * 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. |
| * 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. | * 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. |
| * 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 must configure this folder if you plan to use the plugin’s example compose files, as they rely on this variable. |
| * ...<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%;">  Note | * You can choose any shared folder for this purpose; it does not need to be named "data". |
| </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> | \\ |
| 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. | * HOW TO CONFIGURE THE DATA FOLDER: |
| </tr></table></body></html> | * In the plugin configuration, under the DATA section, select the shared folder you want to assign to CHANGE_TO_COMPOSE_DATA_PATH. |
| * ...<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%;">  Beginners Info | * Click SAVE. |
| </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'' | ''backup_compose'' |
| |
| | (This name matches the diagrams in this document. You can create the shared folder with any name you prefer; the plugin will work the same.) |
| | \\ |
| * WHAT IS BACKUP_COMPOSE FOLDER: | * WHAT IS BACKUP_COMPOSE FOLDER: |
| * The compose plugin allows you to schedule automatic backups of persistent container data. Those backups will be stored in this folder. | * The compose plugin allows you to schedule automatic backups of each container’s persistent data. |
| * CONFIGURE THE BACKUP_COMPOSE FOLDER: | * All scheduled backups created by the plugin are stored in this 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. | * 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%;">  Note | *...<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%;">  Note |
| </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> |
| 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> | 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> |
| 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> | 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> |
| 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 place this folder directly on your backup drive instead — both approaches are valid. |
| If you prefer, you can configure that folder on the backup disk as well. | |
| </tr></table></body></html> | </tr></table></body></html> |
| |
| \\ | \\ |
| | == 2.3.4 docker folder == |
| ''docker'' | ''docker'' |
| |
| | (This name matches the diagrams in this document. You can create the shared folder with any name you prefer; the plugin will work the same.) |
| | \\ |
| * WHAT IS DOCKER FOLDER: | * WHAT IS DOCKER FOLDER: |
| * This folder contains the files that docker uses internally, such as downloaded images and other information necessary for docker to function. | * This folder contains Docker’s internal data: downloaded images, layer data, and various runtime metadata required for Docker to operate. |
| * 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. | * 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. |
| * 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. | * 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. |
| * To define this route it is necessary to define the complete route. Symlinks can sometimes cause problems. | * 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. |
| * CONFIGURE THE DOCKER FOLDER: | * When defining this path, always use the **full absolute path**. Avoid symlinks — they can cause unexpected issues with Docker. |
| * Create the //docker// shared folder in the OMV GUI. | \\ |
| * 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. | * HOW TO CONFIGURE THE DOCKER FOLDER: |
| | * 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%;">  | *...<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%;">  |
| Warning | Warning |
| </span></strong></td></tr><tr><td style="background-color:#FFE4A6;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#FFE4A6;height:25px;width:380px;"> |
| <b>The file system where the docker folder is should preferably be EXT4</b>.<br> | <b>The filesystem hosting the docker folder should preferably be EXT4</b>.<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> | 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> |
| <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> | <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> |
| 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> | 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> |
| - 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> | If the only storage available is inside a mergerfs pool, you may: |
| - Don't use the mergerfs rebalance feature on that pool, the docker data could end up on a different drive and be lost. | - 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. |
| | - Avoid using mergerfs rebalance on that pool, as it may move Docker’s files to another drive and break Docker. |
| </tr></table></body></html> | </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%;">  Advanced configuration. | *...<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%;">  Advanced configuration. |
| </span></strong></td></tr><tr><td style="background-color:#e7fae1;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#e7fae1;height:25px;width:380px;"> |
| 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> | You can <b>manually edit /etc/docker/daemon.json to customize</b> Docker’s behaviour.<br> |
| If you need to customize this file just leave the Docker storage field blank, the plugin will not modify the file. | 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, 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> | </tr></table></body></html> |
| |
| === 3. Create appuser === | === 3. Create appuser === |
| |
| If you have read the introduction of this document you already know if the //appuser// user is enough for you or you need something else. If you are happy with this user for some or all of the containers go ahead, otherwise customize it as above. | If you read the introduction, you already know whether the //appuser// user is sufficient for your needs or if you should create a custom user. |
| | |
| | If you are happy with this user for some or all containers, proceed; otherwise, customize it as explained earlier. |
| |
| {{ :omv7:dockeromv7-8.jpg?direct&400|Expand image -> UID-GID}} | {{ :omv7:dockeromv7-8.jpg?direct&400|Expand image -> UID-GID}} |
| * In the OMV GUI create a user called //appuser//. | * In the OMV GUI create a user called //appuser//. |
| * Add //appuser// to the groups you need. | * Add //appuser// to the groups you need. |
| * For example, if you are going to use hardware transcoding with an Intel GPU you will want to add this user to the //render// and //video// groups. | * For example, if you plan to use hardware transcoding with an Intel GPU, add this user to the ''render'' and ''video'' groups. |
| * ...<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%;">  | * ...<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%;">  |
| Warning | Warning |
| </span></strong></td></tr><tr><td style="background-color:#FFE4A6;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#FFE4A6;height:25px;width:380px;"> |
| Don't add <i>appuser</i> to the <i>docker</i> group. This is a security hole. | Do not add <i>appuser</i> to the <i>docker</i> group. This creates a security hole. |
| </tr></table></body></html> | </tr></table></body></html> |
| * Edit //appuser//'s permissions and grant the appropriate permissions to each shared folder that the containers should be able to access. Persistent configuration data will generally be stored in //appdata//, so we'll give appuser write permissions to the //appdata// folder. It must also have access to the shared folders defined as volumes in the containers. For example, for Jellyfin, this could be the /media folder where movies are stored. Make sure this user only has access to the necessary folders. | * Edit //appuser//'s permissions and grant appropriate access to each shared folder that containers will need: |
| | * Give write access to //appdata// (for persistent container configuration). |
| | * Give access only to the folders required as container volumes (e.g., ''/media'' for Jellyfin movies). |
| * ...<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%;">  Beginners Info | * ...<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%;">  Beginners Info |
| </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> |
| - Go to the USERS > USERS tab and press the +CREATE button.<br> | - Go to the USERS > USERS tab and press the +CREATE button.<br> |
| - In the NAME field type <i>appuser</i><br> | - In the NAME field type <i>appuser</i><br> |
| - In the PASSWORD field define a strong password and confirm it in the next field.<br> | - In the PASSWORD field define a strong password and confirm it.<br> |
| - If you need to add <i>appuser</i> to a group, click the GROUPS field and choose the ones you need.<br> | - If needed, add <i>appuser</i> to the required groups by clicking the GROUPS field.<br> |
| - Click on SAVE button.<br><br> | - Click SAVE.<br><br> |
| To assign permissions to <i>appuser</i>, select <i>appuser</i> and press the SHARED FOLDER PERMISSIONS button.<br> | To assign permissions to <i>appuser</i>, select <i>appuser</i> and press the SHARED FOLDER PERMISSIONS button.<br> |
| - On each line of each shared folder, choose the appropriate permissions and click the corresponding box so that it is yellow.<br> | - For each folder, choose the appropriate permissions and ensure the box is highlighted in yellow.<br> |
| - Click on SAVE button.<br> | - Click SAVE.<br> |
| <br> | <br> |
| </tr></table></body></html> | </tr></table></body></html> |
| * Open the UID and GID columns and take note of the values that //appuser// has. | * Open the UID and GID columns and note the values for //appuser//: |
| * Example: UID=1002 GID=100 | * Example: UID=1002 GID=100 |
| * If you already had one user, //appuser// UID will be 1001. If you had 2 users, //appuser// UID will be 1002, etc. This may vary on your system. | * If you already have one user, //appuser// UID will be 1001; with two users, UID=1002, etc. This may vary depending on your system. |
| |
| <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%;">  | <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%;">  |
| Warning | Warning |
| </span></strong></td></tr><tr><td style="background-color:#FFE4A6;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#FFE4A6;height:25px;width:380px;"> |
| Except for very controlled special cases, <b>never</b> designate the admin user (UID=998) or the root user (UID=0) to manage a container. This is a <b>serious security flaw</b>.<br> | Except in very controlled special cases, <b>never</b> assign the admin user (UID=998) or root (UID=0) to manage a container. This is a <b>serious security flaw</b>.<br> |
| If we do this we are giving the container complete freedom to do whatever it wants in our system. Have you created this container? Do you know what he is capable of doing? | Doing so gives the container unrestricted access to your system. Consider carefully what the container is capable of doing before assigning elevated privileges. |
| </tr></table></body></html> | </tr></table></body></html> |
| |
| === 4. Global environmental variables === | === 4. Global environmental variables === |
| |
| Global environment variables will be used in the procedure that follows this document. | Global environment variables are used in the procedures described in this document. |
| |
| The plugin allows you to define global environment variables in a file that will be available to all running containers. This means that the variables defined in this file can be used in the different compose files. When you start a container, docker will replace those variables with their real values. | The plugin allows you to define these variables in a **single global file**. This file is then available to **all running containers**, so you can reference the same variables across different compose files. When a container starts, Docker automatically replaces the variable names in the compose files with the actual values from the global file. |
| |
| This is very useful for defining paths to folders or the user running the container. We define these values once and have them updated automatically in all containers. | This makes it easy to **define paths and user IDs** once and have them applied everywhere, ensuring consistency and simplifying maintenance. |
| |
| Example: | Example global environment file: |
| {{ :omv7:dockeromv7-9.jpg?direct&400|Expand image -> OMV System}} | {{ :omv7:dockeromv7-9.jpg?direct&400|Expand image -> OMV System}} |
| * Variables defined in the global variables file: | * Variables defined in the global variables file: |
| </code> | </code> |
| |
| * Now we could define the following compose file: | * Using these variables, you could write a compose file like this: |
| |
| <code> | <code> |
| </code> | </code> |
| |
| * And the file that would actually be executed would be this: | * When Docker executes the compose file, it replaces the variables with the real values: |
| |
| <code> | <code> |
| </code> | </code> |
| |
| What this variable system does is convert the variables that we have defined in the compose file into the actual values that we need to define in the compose file. If we are only creating one compose file it may not make much sense, but it is very useful when there are several compose files. | Why this is useful: |
| | |
| | * You only define paths and IDs once. |
| | * Compose files never need to be modified if you move folders or reinstall OMV. |
| | * All containers automatically pick up the updated values. |
| |
| The advantage of using this system is that we define the compose file once and never need to modify it. Even if we reinstall the OMV system we just need to update those global variables and all our containers will be up to date and continue to work as before. | |
| \\ | \\ |
| <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%;">  | <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%;">  |
| Note | Note |
| </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> |
| At this time, the plugin fully supports global environment variables, even while using the plugin's backup utility, so there is no reason to use symlinks. But if you want to use them for some reason, you can still do so.<br> | The plugin fully supports global environment variables, even when using its backup utility. There is no need to use symlinks. If you prefer, you can still use them, but it is optional. If you don’t want to use variables, you can write the full paths and values directly in your compose files. |
| | The plugin fully supports global environment variables, even while using the plugin's backup utility, so there is no reason to use symlinks.<br> |
| | But if you want to use them for some reason, you can still do so.<br> |
| If you don't want to use environment variables, simply write the full values to the compose files without using variables. | If you don't want to use environment variables, simply write the full values to the compose files without using variables. |
| </tr></table></body></html> | </tr></table></body></html> |
| \\ | \\ |
| * In the OMV GUI go to SERVICES > COMPOSE > FILES and press the EDIT GLOBAL ENVIRONEMENT FILE button. | How to configure in the OMV GUI: |
| * In the GLOBAL ENVIRONMENT field copy and paste the example file at the beginning of this section. | |
| | * Go to SERVICES > COMPOSE > FILES and press the EDIT GLOBAL ENVIRONEMENT FILE button. |
| | * In the GLOBAL ENVIRONMENT field copy and paste the example file at the beginning of this section. |
| * Customize it with your own values. | * Customize it with your own values. |
| * PUID and PGID -> You can see the values of user //appuser// in USERS > USERS in the UID and GID columns. See point 3 of this document. | * PUID and PGID -> You can see the values of user //appuser// in USERS > USERS in the UID and GID columns. See point 3 of this document. |
| \\ | \\ |
| \\ | \\ |
| === Choose a container === | ==== 1. Choose a container ==== |
| \\ | \\ |
| [[https://hub.docker.com/|{{ :omv7:dockeromv7-10.png?direct&200|Go to -> https://hub.docker.com/}}]] | [[https://hub.docker.com/|{{ :omv7:dockeromv7-10.png?direct&200|Go to -> https://hub.docker.com/}}]] |
| * On the [[https://hub.docker.com/|dockerhub]] there are thousands of containers ready to configure. | * On [[https://hub.docker.com/|dockerhub]] there are thousands of containers ready to use. |
| * Try to choose containers from reputable publishers ([[https://www.linuxserver.io/|linuxserver]] is very popular) or with many downloads and current ones. | * Try to choose containers from reputable publishers ([[https://www.linuxserver.io/|linuxserver]] is very popular) or containers with many downloads and regular updates. |
| * Check that the container is compatible with your server's architecture amd64, arm64... | * Check that the container is compatible with your server's architecture: **amd64**, **arm64**, etc. |
| * When choosing one read the publisher's recommendations before installing it. | * When choosing one, read the publisher's recommendations before installing it. |
| [[https://www.linuxserver.io/|{{ :omv7:dockeromv7-11.png?direct&200|Go to -> https://www.linuxserver.io/}}]] | [[https://www.linuxserver.io/|{{ :omv7:dockeromv7-11.png?direct&200|Go to -> https://www.linuxserver.io/}}]] |
| * The plugin has examples that you can install directly. As an example we are going to install [[https://jellyfin.org/|Jellyfin]]. | * The plugin includes examples that you can install directly. |
| | * As an example we are going to install [[https://jellyfin.org/|Jellyfin]]. |
| *...<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%;">  | *...<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%;">  |
| Note | Note |
| </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> |
| If you have configured folders in the plugin's SETTINGS tab, the example files will usually work as is, but you may want to modify them to optimize your settings. If you finish reading this document and look at any of the example files, you will understand why. | If you have configured folders in the plugin's SETTINGS tab, the example files will usually work as-is, but you may still want to modify them to optimize your setup. After finishing this document and looking at any example file, you will understand why. |
| </tr></table></body></html> | </tr></table></body></html> |
| * Go to SERVICES > COMPOSE > FILES and click ADD button, then click ADD FROM EXAMPLE button. | * Go to SERVICES > COMPOSE > FILES and click ADD button, then click ADD FROM EXAMPLE button. |
| * Click on the EXAMPLE field and in the list look for the jellyfin file and select it. | * Click on the EXAMPLE field and and select the **jellyfin** file from the list. |
| * In the NAMEame field you can simply write //jellyfin// | * In the NAMEame field you can simply write //jellyfin// |
| * In the DESCRIPTION field you can write something to identify it as Media server. | * In the DESCRIPTION field you can write something to identify it as //Media server//. |
| * Press SAVE button. | * Press SAVE. |
| * In the form you will see a line with the compose file you just added called //jellyfin//. Select that file and press the EDIT button. At the time of writing this document, the example compose file looks like this: | * You will now see a line with the compose file you just added, called //jellyfin//. Select that file and click EDIT. At the time of writing this document, the example compose file looks like this: |
| <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%;">  | <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%;">  |
| Beginners Info | Beginners Info |
| </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> |
| You will find containers where the creator has not published a compose file. Containers can be run from the CLI with a command line. The plugin uses docker-compose for easy setup but you need that compose file. If you can't find it, you can build it yourself using Composerize and starting from that container's docker command. There is a prepared Composerize container in the plugin's examples list. | Some containers do not provide a compose file. They can be run from the CLI using a docker command. The plugin uses docker-compose for easy setup, but you still need the compose file. If you can't find it, you can generate one using <b>Composerize</b> starting from the container's docker command. There is a prepared Composerize container in the plugin's examples list. |
| </tr></table></body></html> | </tr></table></body></html> |
| [[https://jellyfin.org/|{{ :omv7:dockeromv7-12.png?200|Go to -> https://jellyfin.org/}}]] | [[https://jellyfin.org/|{{ :omv7:dockeromv7-12.png?200|Go to -> https://jellyfin.org/}}]] |
| Beginners Info | Beginners Info |
| </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> | </span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;"> |
| WHAT A COMPOSE FILE IS LIKE<br> | <b>WHAT A COMPOSE FILE LOOKS LIKE</b><br> |
| A compose file is a yaml format file that is used to define the configurations that docker will adjust to the downloaded image to form the container.<br> | A compose file is a YAML file that defines the configuration that Docker will apply to the downloaded image to create the container.<br><br> |
| The parts of this composition file for jellyfin are as follows:<br> | The parts of this compose file for Jellyfin are as follows:<br> |
| <b>services:</b> It is always the first line and gives way to the definition of the different services.<br> | <b>services:</b> Always the first line. It begins the definition of services.<br> |
| <b>jellyfin:</b> Is the name of a service in this compose file. In this case there is only one but there could be more.<br> | <b>jellyfin:</b> The name of a service in this compose file. In this example there is only one, but there could be more.<br> |
| <b>image:</b> Defines where the container is downloaded from, in this case linuxserver. This value may have options to download different versions of images. In this case the word <b>latest</b> indicates that the latest available version will always be downloaded.<br> | <b>image:</b> Defines where the container image is downloaded from. In this case, LinuxServer. The value may specify different image versions. Here, <b>latest</b> means the newest version will always be used.<br> |
| <b>container_name:</b> Simply the name of the container for this service, in this case jellyfin.<br> | <b>container_name:</b> The name we assign to the container, in this case <i>jellyfin</i>.<br> |
| <b>environment</b> In this section some environment values are defined, such as in this case the user who will run the container, the time zone, or others.<br> | <b>environment:</b> Defines environment variables such as user, timezone, and other settings.<br> |
| <b>volumes</b> Here we define the folder mounts in the container.<br> | <b>volumes:</b> Defines folder mappings between the host and the container.<br> |
| <b>ports</b> To define port mounts.<br> | <b>ports:</b> Defines port mappings.<br> |
| <b>restart</b> Tells docker how we want the container to behave when the server starts, etc. In this case, the container will always be running unless we stop it manually.<br> | <b>restart:</b> Indicates how Docker should behave when the server restarts. <i>unless-stopped</i> means the container will always start unless you manually stop it. |
| </tr></table></body></html> | </tr></table></body></html> |
| |