</code></pre><p>if using compose. Where possible, to improve security, we recommend mounting them read-only (<code>:ro</code>) so that container processes cannot write to the location.</p><p>One example use case is our Piwigo container has a plugin that supports video, but requires ffmpeg to be installed. No problem. Add this bad boy into a script file (can be named anything) and you're good to go.</p><pre><codeclass=language-bash>#!/bin/bash
echo "**** installing ffmpeg ****"
apk add --no-cache ffmpeg
</code></pre><p><strong>NOTE:</strong> The folder <code>/custom-cont-init.d</code> needs to be owned by root! If this is not the case, this folder will be renamed and a new (empty) folder will be created. This is to prevent remote code execution by putting scripts in the aforementioned folder.</p><h2id=custom-services>Custom Services</h2><p>There might also be a need to run an additional service in a container alongside what we already package. Similarly to the custom scripts, just create a new directory at <code>/custom-services.d</code>. The files in this directory should be named after the service they will be running. Similar to with custom scripts you will need to mount this folder like any other volume if you wish to make use of it. e.g. <code>-v /home/foo/appdata/my-custom-services:/custom-services.d</code> if using the Docker CLI or</p><pre><codeclass=language-yaml>services:
</code></pre><p>if using compose. Where possible, to improve security, we recommend mounting them read-only (<code>:ro</code>) so that container processes cannot write to the location.</p><p>Running cron in our containers is now as simple as a single file. Drop this script in <code>/custom-services.d/cron</code> and it will run automatically in the container:</p><pre><codeclass=language-bash>#!/usr/bin/with-contenv bash
/usr/sbin/crond -f -S -l 0 -c /etc/crontabs
</code></pre><p><strong>NOTE:</strong> With this example, you will most likely need to have cron installed via a custom script using the technique in the previous section, and will need to populate the crontab.</p><p><strong>NOTE:</strong> The folder <code>/custom-services.d</code> needs to be owned by root! If this is not the case, this folder will be renamed and a new (empty) folder will be created. This is to prevent remote code execution by putting scripts in the aforementioned folder.</p><h2id=docker-mods>Docker Mods</h2><p>In most cases if you needed to write some kind of custom logic to get a plugin to work or to use some kind of popular external service you will not be the only one that finds this logic useful.</p><p>If you would like to publish and support your hard work we provide a system for a user to pass a single environment variable to the container to ingest your custom modifications.</p><p>We consume Mods from Dockerhub and in order to publish one following our guide, you only need a Github Account and a Dockerhub account. <ahref=https://github.com/linuxserver/docker-mods>(Our guide and example code can be found here)</a></p><p>Essentially it is a system that stashes a tarball of scripts and any other files you need in an image layer on Dockerhub. When we spin up the container we will download this tarball and extract it to /.</p><p>This allows community members to publish a relatively static pile of logic that will always be applied to an end user's up to date Linuxserver.io container.</p><p>An example of how this logic can be used to greatly expand the functionality of our base containers would be to add VPN support to a Transmission container:</p><pre><code>docker create \
