FAQ
Here will some Frequently Asked Questions reside
My host is incompatible with images based on Ubuntu Jammy {#jammy}
Some x86_64 hosts running older versions of the Docker engine are not compatible with some images based on Ubuntu Jammy.
-
Symptoms
If your host is affected you may see errors in your containers such as:
shell ERROR - Unable to determine java version; make sure Java is installed and callableOr
shell Failed to create CoreCLR, HRESULT: 0x80070008Or
shell WARNING :: MAIN : webStart.py:initialize:249 : can't start new thread -
Resolution
-
Option 1 (Long-Term Fix)
Upgrade your Docker engine install to at least version
20.10.10. Refer to the official Docker docs for installation/update details. -
Option 2 (Short-Term Fix)
For Docker CLI, run your container with:
--security-opt seccomp=unconfinedFor Docker Compose, run your container with:
yaml security_opt: - seccomp=unconfined
My host is incompatible with images based on rdesktop {#rdesktop}
Some x86_64 hosts have issues running rdesktop based images even with the latest docker version due to syscalls that are unknown to docker.
-
Symptoms
If your host is affected you may see errors in your containers such as:
shell Failed to close file descriptor for child process (Operation not permitted) -
Resolution
For Docker CLI, run your container with:
--security-opt seccomp=unconfinedFor Docker Compose, run your container with:
yaml security_opt: - seccomp=unconfined
My host is incompatible with images based on Ubuntu Focal and Alpine 3.13 and later {#libseccomp}
This only affects 32 bit installs of distros based on Debian Buster.
This is due to a bug in the libseccomp2 library (dependency of Docker itself), which is fixed. However it's not pushed to all the repositories.
You have a few options as noted below. Options 1 is short-term, while option 2 is considered the best option if you don't plan to reinstall the device (option 3).
-
Resolution
If you decide to do option 1 or 2, you should just need to restart the container after confirming you have libseccomp2.4.4 installed.
If 1 or 2 did not work, ensure your Docker install is at least version 20.10.0, refer to the official Docker docs for installation.
-
Option 1
Manually install an updated version of the library with dpkg.
shell wget http://ftp.us.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.4.4-1~bpo10+1_armhf.deb sudo dpkg -i libseccomp2_2.4.4-1~bpo10+1_armhf.deb{% hint style="info" %} This url may have been updated. Find the latest by browsing here. {% endhint %}
-
Option 2
Add the backports repo for DebianBuster. As seen here.
shell sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 04EE7237B7D453EC 648ACFD622F3D138 echo "deb http://deb.debian.org/debian buster-backports main" | sudo tee -a /etc/apt/sources.list.d/buster-backports.list sudo apt update sudo apt install -t buster-backports libseccomp2 -
Option 3
Reinstall/update your OS to a version that still gets updates.
- Any distro based on DebianStretch does not seem to have this package available
- DebianBuster based distros can get the package trough backports, as outlined in point 2.
{% hint style="info" %} RaspberryPI OS (formerly Raspbian) Can be upgraded to run with a 64bit kernel {% endhint %}
-
Symptoms
-
502 errors in Jellyfin as seen in linuxserver/docker-jellyfin#71
Error starting framework coremessages in the docker log for Plex. linuxserver/docker-plex#247- No WebUI for Radarr, even though the container is running. linuxserver/docker-radarr#118
- Images based on our Nginx base-image(Nextcloud, SWAG, Nginx, etc.) fails to generate a certificate, with a message similar to
error getting time:crypto/asn1/a_time.c:330 docker exec <container-name> datereturns 1970
I want to reverse proxy a application which defaults to https with a selfsigned certificate {#strict-proxy}
Traefik {#strict-proxy-traefik}
In this example we will configure a serverTransport rule we can apply to a service, as well as telling Traefik to use https on the backend for the service.
Create a ServerTransport in your dynamic Traefik configuration, we are calling ours ignorecert.
http:
+ FAQ - LinuxServer.io FAQ
Here will some Frequently Asked Questions reside
My host is incompatible with images based on Ubuntu Jammy
Some x86_64 hosts running older versions of the Docker engine are not compatible with some images based on Ubuntu Jammy.
-
Symptoms
If your host is affected you may see errors in your containers such as:
shell ERROR - Unable to determine java version; make sure Java is installed and callable
Or
shell Failed to create CoreCLR, HRESULT: 0x80070008
Or
shell WARNING :: MAIN : webStart.py:initialize:249 : can't start new thread
-
Resolution
-
Option 1 (Long-Term Fix)
Upgrade your Docker engine install to at least version 20.10.10. Refer to the official Docker docs for installation/update details.
-
Option 2 (Short-Term Fix)
For Docker CLI, run your container with:
--security-opt seccomp=unconfined
For Docker Compose, run your container with:
yaml security_opt: - seccomp=unconfined
My host is incompatible with images based on rdesktop
Some x86_64 hosts have issues running rdesktop based images even with the latest docker version due to syscalls that are unknown to docker.
-
Symptoms
If your host is affected you may see errors in your containers such as:
shell Failed to close file descriptor for child process (Operation not permitted)
-
Resolution
For Docker CLI, run your container with:
--security-opt seccomp=unconfined
For Docker Compose, run your container with:
yaml security_opt: - seccomp=unconfined
My host is incompatible with images based on Ubuntu Focal and Alpine 3.13 and later
This only affects 32 bit installs of distros based on Debian Buster.
This is due to a bug in the libseccomp2 library (dependency of Docker itself), which is fixed. However it's not pushed to all the repositories.
You have a few options as noted below. Options 1 is short-term, while option 2 is considered the best option if you don't plan to reinstall the device (option 3).
-
Resolution
If you decide to do option 1 or 2, you should just need to restart the container after confirming you have libseccomp2.4.4 installed.
If 1 or 2 did not work, ensure your Docker install is at least version 20.10.0, refer to the official Docker docs for installation.
-
Option 1
Manually install an updated version of the library with dpkg.
shell wget http://ftp.us.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.4.4-1~bpo10+1_armhf.deb sudo dpkg -i libseccomp2_2.4.4-1~bpo10+1_armhf.deb
{% hint style="info" %} This url may have been updated. Find the latest by browsing here.
-
Option 2
Add the backports repo for DebianBuster. As seen here.
shell sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 04EE7237B7D453EC 648ACFD622F3D138 echo "deb http://deb.debian.org/debian buster-backports main" | sudo tee -a /etc/apt/sources.list.d/buster-backports.list sudo apt update sudo apt install -t buster-backports libseccomp2
-
Option 3
Reinstall/update your OS to a version that still gets updates.
- Any distro based on DebianStretch does not seem to have this package available
- DebianBuster based distros can get the package trough backports, as outlined in point 2.
{% hint style="info" %} RaspberryPI OS (formerly Raspbian) Can be upgraded to run with a 64bit kernel
-
Symptoms
-
502 errors in Jellyfin as seen in linuxserver/docker-jellyfin#71
Error starting framework core messages in the docker log for Plex. linuxserver/docker-plex#247- No WebUI for Radarr, even though the container is running. linuxserver/docker-radarr#118
- Images based on our Nginx base-image(Nextcloud, SWAG, Nginx, etc.) fails to generate a certificate, with a message similar to
error getting time:crypto/asn1/a_time.c:330 docker exec <container-name> date returns 1970
I want to reverse proxy a application which defaults to https with a selfsigned certificate
Traefik
In this example we will configure a serverTransport rule we can apply to a service, as well as telling Traefik to use https on the backend for the service.
Create a ServerTransport in your dynamic Traefik configuration, we are calling ours ignorecert.
http:
serversTransports:
ignorecert:
insecureSkipVerify: true
diff --git a/general/fleet/index.html b/general/fleet/index.html
index 3b69b88c04..49cef838cd 100644
--- a/general/fleet/index.html
+++ b/general/fleet/index.html
@@ -1,4 +1,4 @@
- Fleet - LinuxServer.io Fleet
How Fleet works
Fleet stores a snapshot of Docker Images in its own database, consisting of metadata deemed most pertinent to both the users of the images, and the repository owner. It will synchronize with Docker Hub over a set interval in order to update its stored data.
It then displays this snapshot data on its own status page as a useful list, containing links to each repository and image owned by the repository owner. Each image also contains a status which is managed by the repository owner, who can define images as either Stable or Unstable. This is designed to quickly help users know when an image is undergoing a state of instability which is known by the owner.
Why a snapshot?
In short, Docker Hub's API is very slow. It would not be a good long-term solution to just proxy the responses from Docker Hub and translate the data into something considered useful by downstream clients. By caching the image information in its own database, Fleet is able to more efficiently return the status data for each image and repository. In doing so, it is also able to provide more concise data, such as image versions, as part of the primary response, rather than requiring users to make a separate call.
As an example comparison between obtaining all image name, pull and version information for all LinuxServer images from Docker Hub, and then obtaining that same data via Fleet's API:
API Time (ms) Docker Hub (multiple calls) 52000ms Fleet 50ms
Capabilities
Fleet has the ability to display images with a particular state, which provides contextual information to visitors of the application's main page.
Hidden
If an image is hidden, it will not be displayed as part of the main list, nor will it be returned as part of any API calls. This also means that the pull count of a hidden image is not included.
Unstable
Marks an image as having issues known by the maintainer. A useful state to assign to an image if the latest build (or builds) are causing downstream breakages. This may also be useful if an upstream dependency or application is causing breakages in the image directly.
Deprecated
If the maintainer of the image, or upstream application no longer wishes to provide support, or if the image has reached its end-of-life (or has been superseded by another), marking an image as deprecated will ensure users are made aware that no further updates will be supplied, and should stop using it. Deprecation notices are also provided to give context.
API
Fleet exposes a single API endpoint which can be used to obtain image list and pull count information for all relevant images maintained by the repository
{% api-method method="get" host="https://fleet.linuxserver.io" path="/api/v1/images" %} {% api-method-summary %} Get All Repositories and Images {% endapi-method-summary %}
{% api-method-description %} Returns all synchronized images. {% endapi-method-description %}
{% api-method-spec %} {% api-method-request %}
{% api-method-response %} {% api-method-response-example httpCode=200 %} {% api-method-response-example-description %} All synchronized repositories and images returned. {% endapi-method-response-example-description %}
{
+ Fleet - LinuxServer.io Fleet
How Fleet works
Fleet stores a snapshot of Docker Images in its own database, consisting of metadata deemed most pertinent to both the users of the images, and the repository owner. It will synchronize with Docker Hub over a set interval in order to update its stored data.
It then displays this snapshot data on its own status page as a useful list, containing links to each repository and image owned by the repository owner. Each image also contains a status which is managed by the repository owner, who can define images as either Stable or Unstable. This is designed to quickly help users know when an image is undergoing a state of instability which is known by the owner.
Why a snapshot?
In short, Docker Hub's API is very slow. It would not be a good long-term solution to just proxy the responses from Docker Hub and translate the data into something considered useful by downstream clients. By caching the image information in its own database, Fleet is able to more efficiently return the status data for each image and repository. In doing so, it is also able to provide more concise data, such as image versions, as part of the primary response, rather than requiring users to make a separate call.
As an example comparison between obtaining all image name, pull and version information for all LinuxServer images from Docker Hub, and then obtaining that same data via Fleet's API:
API Time (ms) Docker Hub (multiple calls) 52000ms Fleet 50ms
Capabilities
Fleet has the ability to display images with a particular state, which provides contextual information to visitors of the application's main page.
Hidden
If an image is hidden, it will not be displayed as part of the main list, nor will it be returned as part of any API calls. This also means that the pull count of a hidden image is not included.
Unstable
Marks an image as having issues known by the maintainer. A useful state to assign to an image if the latest build (or builds) are causing downstream breakages. This may also be useful if an upstream dependency or application is causing breakages in the image directly.
Deprecated
If the maintainer of the image, or upstream application no longer wishes to provide support, or if the image has reached its end-of-life (or has been superseded by another), marking an image as deprecated will ensure users are made aware that no further updates will be supplied, and should stop using it. Deprecation notices are also provided to give context.
API
Fleet exposes a single API endpoint which can be used to obtain image list and pull count information for all relevant images maintained by the repository
{% api-method method="get" host="https://fleet.linuxserver.io" path="/api/v1/images" %} {% api-method-summary %} Get All Repositories and Images
{% api-method-description %} Returns all synchronized images.
{% api-method-spec %}
{% api-method-response %} {% api-method-response-example httpCode=200 %} {% api-method-response-example-description %} All synchronized repositories and images returned.
{
"status": "OK",
"data" {
"totalPullCount": 1862494227,
@@ -37,7 +37,7 @@
}
}
}
-
{% endapi-method-response-example %} {% endapi-method-response %} {% endapi-method-spec %} {% endapi-method %}
{% hint style="info" %} Any repositories not synchronized with Docker Hub (e.g. staging or metadata repositories) will not be returned as part of the API. This also applies to images which the repository owner does not wish to be part of the primary image list. {% endhint %}
Running Fleet
{% hint style="warning" %} Fleet is a Java application and requires at least JRE 11. {% endhint %}
Grab the latest Fleet release from GitHub.
SQL
Fleet stores its data in a MariaDB database which you need to provide. In order for the application to manage its tables and procedures, the user you provide it needs to have the relevant GRANT permissions to the fleet database. The following script should be sufficient to get the initial database set up.
CREATE SCHEMA `fleet`;
+
{% endapi-method-response-example %} {% endapi-method-response %} {% endapi-method-spec %}
{% hint style="info" %} Any repositories not synchronized with Docker Hub (e.g. staging or metadata repositories) will not be returned as part of the API. This also applies to images which the repository owner does not wish to be part of the primary image list.
Running Fleet
{% hint style="warning" %} Fleet is a Java application and requires at least JRE 11.
Grab the latest Fleet release from GitHub.
SQL
Fleet stores its data in a MariaDB database which you need to provide. In order for the application to manage its tables and procedures, the user you provide it needs to have the relevant GRANT permissions to the fleet database. The following script should be sufficient to get the initial database set up.
CREATE SCHEMA `fleet`;
CREATE USER 'fleet_user' IDENTIFIED BY 'supersecretpassword';
GRANT ALL ON `fleet`.* TO 'fleet_user';
The username and password that you define must then be provided as part of Fleet's configuration.
Configuration File
All primary configuration for Fleet at runtime is loaded in via a fleet.properties file. This can be located anywhere on the file system, and is loaded in via a Runtime argument:
# Runtime
@@ -51,4 +51,4 @@ fleet.database.password=<fleet_sql_password>
# Password security
fleet.admin.secret=<a_random_string>
-
All configuration can be loaded either via the config file, via JVM arguments, or via the system environment. Fleet will first look in the configuration file, then JVM runtime, and finally in the system environment. It will load the first value it finds, which can be useful when needing to override specific properties.
{% hint style="info" %} If you place a property in the system environment, ensure that the property uses underscores rather than periods. This is due to a limitation in BASH environments where exported variables must not contain this character. E.g. fleet.app.port=8080 becomes export fleet_app_port=8080 {% endhint %}
Property Name Purpose fleet.app.portThe port which the application will be running under. fleet.admin.secretA string used as part of the password key derivation process. This secret is prepended to the raw password before its key is derived, providing further pseudo-randomness to hashed passwords. Once set, this must not be changed! It is vital to remain the same, as it will be used during the password verification step. If Fleet is restarted with this removed or set differently, the password verification process will fail because previously hashed passwords will have been derived with the old secret. fleet.database.driverThe driver to use for connections to Fleet's database. This should be org.mariadb.jdbc.Driver fleet.database.urlThe full JDBC connection string to the database. fleet.database.usernameThe username of the SQL user which will be managing the data in the Fleet database. This should have full GRANT access to the fleet database as it also manages any database migrations. fleet.database.passwordThe password for the SQL user
Runtime Arguments
As well as the base configuration file, Fleet also supports some runtime arguments by means of the -D flag. These can be used to direct Fleet to behave in a specific way at runtime.
{% hint style="info" %} Unlike the properties defined above, these properties are only accessed via the JVM arguments (-D). {% endhint %}
Runtime Argument Purpose fleet.config.baseThe absolute path of the configuration file. fleet.show.passwordsTells fleet to show passwords in plain text in its logs. Not recommended. fleet.nuke.databaseBe very careful. This will tell Fleet to completely wipe and rebuild its database. This can be useful if the owner deems the database to be too far out of synchronisation with Docker Hub, or if images have since been removed but are still showing in Fleet. fleet.skip.sync.on.startupBy default, Fleet will run a synchronisation process when it first starts up. Setting this flag will tell it to skip the first run. The next synchronisation will be at the set interval.
Default User
When starting Fleet for the first time it will create a default user in order for you to log in and manage the repositories/images synchronised by the application. The default username and password are:
Username: admin
Password: admin
{% hint style="warning" %} You should change the default password for this user as soon as possible! This can be done via the Admin -> Users menu options. {% endhint %}
\ No newline at end of file
+
All configuration can be loaded either via the config file, via JVM arguments, or via the system environment. Fleet will first look in the configuration file, then JVM runtime, and finally in the system environment. It will load the first value it finds, which can be useful when needing to override specific properties.
{% hint style="info" %} If you place a property in the system environment, ensure that the property uses underscores rather than periods. This is due to a limitation in BASH environments where exported variables must not contain this character. E.g. fleet.app.port=8080 becomes export fleet_app_port=8080
Property Name Purpose fleet.app.portThe port which the application will be running under. fleet.admin.secretA string used as part of the password key derivation process. This secret is prepended to the raw password before its key is derived, providing further pseudo-randomness to hashed passwords. Once set, this must not be changed! It is vital to remain the same, as it will be used during the password verification step. If Fleet is restarted with this removed or set differently, the password verification process will fail because previously hashed passwords will have been derived with the old secret. fleet.database.driverThe driver to use for connections to Fleet's database. This should be org.mariadb.jdbc.Driver fleet.database.urlThe full JDBC connection string to the database. fleet.database.usernameThe username of the SQL user which will be managing the data in the Fleet database. This should have full GRANT access to the fleet database as it also manages any database migrations. fleet.database.passwordThe password for the SQL user
Runtime Arguments
As well as the base configuration file, Fleet also supports some runtime arguments by means of the -D flag. These can be used to direct Fleet to behave in a specific way at runtime.
{% hint style="info" %} Unlike the properties defined above, these properties are only accessed via the JVM arguments (-D).
Runtime Argument Purpose fleet.config.baseThe absolute path of the configuration file. fleet.show.passwordsTells fleet to show passwords in plain text in its logs. Not recommended. fleet.nuke.databaseBe very careful. This will tell Fleet to completely wipe and rebuild its database. This can be useful if the owner deems the database to be too far out of synchronisation with Docker Hub, or if images have since been removed but are still showing in Fleet. fleet.skip.sync.on.startupBy default, Fleet will run a synchronisation process when it first starts up. Setting this flag will tell it to skip the first run. The next synchronisation will be at the set interval.
Default User
When starting Fleet for the first time it will create a default user in order for you to log in and manage the repositories/images synchronised by the application. The default username and password are:
Username: admin
Password: admin
{% hint style="warning" %} You should change the default password for this user as soon as possible! This can be done via the Admin -> Users menu options.
\ No newline at end of file
diff --git a/general/understanding-puid-and-pgid/index.html b/general/understanding-puid-and-pgid/index.html
index 504b2fa1ef..2622b01250 100644
--- a/general/understanding-puid-and-pgid/index.html
+++ b/general/understanding-puid-and-pgid/index.html
@@ -1,4 +1,4 @@
- Understanding PUID and PGID - LinuxServer.io Understanding PUID and PGID
{% hint style="info" %} We are aware that recent versions of the Docker engine have introduced the --user flag. Our images are not yet compatible with this, so we recommend continuing usage of PUID and PGID. {% endhint %}
Why use these?
Docker runs all of its containers under the root user domain because it requires access to things like network configuration, process management, and your filesystem. This means that the processes running inside your containers also run as root. This kind of elevated access is not ideal for day-to-day use, and potentially gives applications the access to things they shouldn't (although, a strong understanding of volume and port mapping will help with this).
Another issue is file management within the container's mapped volumes. If the process is running under root, all files and directories created during the container's lifespan will be owned by root, thus becoming inaccessible by you.
Using the PUID and PGID allows our containers to map the container's internal user to a user on the host machine. All of our containers use this method of user mapping and should be applied accordingly.
Using the variables
When creating a container from one of our images, ensure you use the -e PUID and -e PGID options in your docker command:
docker create --name=beets -e PUID=1000 -e PGID=1000 linuxserver/beets
+ Understanding PUID and PGID - LinuxServer.io Understanding PUID and PGID
{% hint style="info" %} We are aware that recent versions of the Docker engine have introduced the --user flag. Our images are not yet compatible with this, so we recommend continuing usage of PUID and PGID.
Why use these?
Docker runs all of its containers under the root user domain because it requires access to things like network configuration, process management, and your filesystem. This means that the processes running inside your containers also run as root. This kind of elevated access is not ideal for day-to-day use, and potentially gives applications the access to things they shouldn't (although, a strong understanding of volume and port mapping will help with this).
Another issue is file management within the container's mapped volumes. If the process is running under root, all files and directories created during the container's lifespan will be owned by root, thus becoming inaccessible by you.
Using the PUID and PGID allows our containers to map the container's internal user to a user on the host machine. All of our containers use this method of user mapping and should be applied accordingly.
Using the variables
When creating a container from one of our images, ensure you use the -e PUID and -e PGID options in your docker command:
docker create --name=beets -e PUID=1000 -e PGID=1000 linuxserver/beets
Or, if you use docker-compose, add them to the environment: section:
environment:
- PUID=1000
- PGID=1000
diff --git a/images/docker-fail2ban/index.html b/images/docker-fail2ban/index.html
index f9d087d146..25a5b84355 100644
--- a/images/docker-fail2ban/index.html
+++ b/images/docker-fail2ban/index.html
@@ -62,7 +62,7 @@ services:
-v /path/to/vaultwarden/log:/remotelogs/vaultwarden:ro `#optional` \
--restart unless-stopped \
lscr.io/linuxserver/fail2ban:latest
-
Parameters
Docker images are configured using parameters passed at runtime (such as those above). These parameters are separated by a colon and indicate <external>:<internal> respectively. For example, -p 8080:80 would expose port 80 from inside the container to be accessible from the host's IP on port 8080 outside the container.
Ports (-p)
Parameter Function
Networking (--net)
Parameter Function --net=hostShares host networking with container.
Environment Variables (-e)
Env Function PUID=1000for UserID - see below for explanation PGID=1000for GroupID - see below for explanation TZ=America/New_YorkSpecify a timezone to use EG America/New_York
Volume Mappings (-v)
Volume Function /configContains all relevant configuration files. /var/log:roHost logs. Mounted as Read Only. /remotelogs/airsonic:roOptional path to airsonic log folder. Mounted as Read Only. /remotelogs/apache2:roOptional path to apache2 log folder. Mounted as Read Only. /remotelogs/authelia:roOptional path to authelia log folder. Mounted as Read Only. /remotelogs/emby:roOptional path to emby log folder. Mounted as Read Only. /remotelogs/filebrowser:roOptional path to filebrowser log folder. Mounted as Read Only. /remotelogs/homeassistant:roOptional path to homeassistant log folder. Mounted as Read Only. /remotelogs/lighttpd:roOptional path to lighttpd log folder. Mounted as Read Only. /remotelogs/nextcloud:roOptional path to nextcloud log folder. Mounted as Read Only. /remotelogs/nginx:roOptional path to nginx log folder. Mounted as Read Only. /remotelogs/nzbget:roOptional path to nzbget log folder. Mounted as Read Only. /remotelogs/overseerr:roOptional path to overseerr log folder. Mounted as Read Only. /remotelogs/prowlarr:roOptional path to prowlarr log folder. Mounted as Read Only. /remotelogs/radarr:roOptional path to radarr log folder. Mounted as Read Only. /remotelogs/sabnzbd:roOptional path to sabnzbd log folder. Mounted as Read Only. /remotelogs/sonarr:roOptional path to sonarr log folder. Mounted as Read Only. /remotelogs/unificontroller:roOptional path to unificontroller log folder. Mounted as Read Only. /remotelogs/vaultwarden:roOptional path to vaultwarden log folder. Mounted as Read Only.
Miscellaneous Options
Parameter Function
Portainer notice
{% hint style="warning" %} This image utilises cap_add or sysctl to work properly. This is not implemented properly in some versions of Portainer, thus this image may not work if deployed through Portainer. {% endhint %}
Environment variables from files (Docker secrets)
You can set any environment variable from a file by using a special prepend FILE__.
As an example:
-e FILE__PASSWORD=/run/secrets/mysecretpassword
+
Parameters
Docker images are configured using parameters passed at runtime (such as those above). These parameters are separated by a colon and indicate <external>:<internal> respectively. For example, -p 8080:80 would expose port 80 from inside the container to be accessible from the host's IP on port 8080 outside the container.
Ports (-p)
Parameter Function
Networking (--net)
Parameter Function --net=hostShares host networking with container.
Environment Variables (-e)
Env Function PUID=1000for UserID - see below for explanation PGID=1000for GroupID - see below for explanation TZ=America/New_YorkSpecify a timezone to use EG America/New_York
Volume Mappings (-v)
Volume Function /configContains all relevant configuration files. /var/log:roHost logs. Mounted as Read Only. /remotelogs/airsonic:roOptional path to airsonic log folder. Mounted as Read Only. /remotelogs/apache2:roOptional path to apache2 log folder. Mounted as Read Only. /remotelogs/authelia:roOptional path to authelia log folder. Mounted as Read Only. /remotelogs/emby:roOptional path to emby log folder. Mounted as Read Only. /remotelogs/filebrowser:roOptional path to filebrowser log folder. Mounted as Read Only. /remotelogs/homeassistant:roOptional path to homeassistant log folder. Mounted as Read Only. /remotelogs/lighttpd:roOptional path to lighttpd log folder. Mounted as Read Only. /remotelogs/nextcloud:roOptional path to nextcloud log folder. Mounted as Read Only. /remotelogs/nginx:roOptional path to nginx log folder. Mounted as Read Only. /remotelogs/nzbget:roOptional path to nzbget log folder. Mounted as Read Only. /remotelogs/overseerr:roOptional path to overseerr log folder. Mounted as Read Only. /remotelogs/prowlarr:roOptional path to prowlarr log folder. Mounted as Read Only. /remotelogs/radarr:roOptional path to radarr log folder. Mounted as Read Only. /remotelogs/sabnzbd:roOptional path to sabnzbd log folder. Mounted as Read Only. /remotelogs/sonarr:roOptional path to sonarr log folder. Mounted as Read Only. /remotelogs/unificontroller:roOptional path to unificontroller log folder. Mounted as Read Only. /remotelogs/vaultwarden:roOptional path to vaultwarden log folder. Mounted as Read Only.
Miscellaneous Options
Parameter Function
Portainer notice
{% hint style="warning" %} This image utilises cap_add or sysctl to work properly. This is not implemented properly in some versions of Portainer, thus this image may not work if deployed through Portainer.
Environment variables from files (Docker secrets)
You can set any environment variable from a file by using a special prepend FILE__.
As an example:
-e FILE__PASSWORD=/run/secrets/mysecretpassword
Will set the environment variable PASSWORD based on the contents of the /run/secrets/mysecretpassword file.
Umask for running applications
For all of our images we provide the ability to override the default umask settings for services started within the containers using the optional -e UMASK=022 setting. Keep in mind umask is not chmod it subtracts from permissions based on it's value it does not add. Please read up here before asking for support.
User / Group Identifiers
When using volumes (-v flags), permissions issues can arise between the host OS and the container, we avoid this issue by allowing you to specify the user PUID and group PGID.
Ensure any volume directories on the host are owned by the same user you specify and any permissions issues will vanish like magic.
In this instance PUID=1000 and PGID=1000, to find yours use id user as below:
$ id username
uid=1000(dockeruser) gid=1000(dockergroup) groups=1000(dockergroup)
Docker Mods
We publish various Docker Mods to enable additional functionality within the containers. The list of Mods available for this image (if any) as well as universal mods that can be applied to any one of our images can be accessed via the dynamic badges above.
Support Info
- Shell access whilst the container is running:
docker exec -it fail2ban /bin/bash- To monitor the logs of the container in realtime:
docker logs -f fail2ban- Container version number
docker inspect -f '{{ index .Config.Labels "build_version" }}' fail2ban- Image version number
docker inspect -f '{{ index .Config.Labels "build_version" }}' lscr.io/linuxserver/fail2ban:latest
Versions
- 15.12.22: - Rebase to Alpine 3.17, Add ssmtp and whois packages. Symlink config to allow live reloading.
- 25.08.22: - Update README to clarify remote log information.
- 09.08.22: - Initial Release.
\ No newline at end of file
diff --git a/images/docker-scrutiny/index.html b/images/docker-scrutiny/index.html
index 403388a77b..fe9974343c 100644
--- a/images/docker-scrutiny/index.html
+++ b/images/docker-scrutiny/index.html
@@ -42,7 +42,7 @@ services:
--device /dev/nvme1n1:/dev/nvme1n1 \
--restart unless-stopped \
lscr.io/linuxserver/scrutiny:latest
-
Parameters
Docker images are configured using parameters passed at runtime (such as those above). These parameters are separated by a colon and indicate <external>:<internal> respectively. For example, -p 8080:80 would expose port 80 from inside the container to be accessible from the host's IP on port 8080 outside the container.
Ports (-p)
Parameter Function 8080Port for scrutiny's web interface and API.
Environment Variables (-e)
Env Function PUID=1000for UserID - see below for explanation PGID=1000for GroupID - see below for explanation TZ=Europe/LondonSpecify a timezone to use EG Europe/London. SCRUTINY_API_ENDPOINT=http://localhost:8080# optional - API endpoint of the scrutiny UI. Do not change unless using as a remote collector SCRUTINY_WEB=true# optional - Run the web service. SCRUTINY_COLLECTOR=true# optional - Run the metrics collector.
Volume Mappings (-v)
Volume Function /configWhere config is stored. /run/udev:roProvides necessary metadata to Scrutiny.
Device Mappings (--device)
Parameter Function /dev/sdaThis is how Scrutiny accesses drives. Optionally supply /dev:/dev instead for all devices. /dev/sdbA second drive. /dev/nvme1n1An NVMe drive. NVMe requires --cap-add=SYS_ADMIN.
Miscellaneous Options
Parameter Function
Portainer notice
{% hint style="warning" %} This image utilises cap_add or sysctl to work properly. This is not implemented properly in some versions of Portainer, thus this image may not work if deployed through Portainer. {% endhint %}
Environment variables from files (Docker secrets)
You can set any environment variable from a file by using a special prepend FILE__.
As an example:
-e FILE__PASSWORD=/run/secrets/mysecretpassword
+
Parameters
Docker images are configured using parameters passed at runtime (such as those above). These parameters are separated by a colon and indicate <external>:<internal> respectively. For example, -p 8080:80 would expose port 80 from inside the container to be accessible from the host's IP on port 8080 outside the container.
Ports (-p)
Parameter Function 8080Port for scrutiny's web interface and API.
Environment Variables (-e)
Env Function PUID=1000for UserID - see below for explanation PGID=1000for GroupID - see below for explanation TZ=Europe/LondonSpecify a timezone to use EG Europe/London. SCRUTINY_API_ENDPOINT=http://localhost:8080# optional - API endpoint of the scrutiny UI. Do not change unless using as a remote collector SCRUTINY_WEB=true# optional - Run the web service. SCRUTINY_COLLECTOR=true# optional - Run the metrics collector.
Volume Mappings (-v)
Volume Function /configWhere config is stored. /run/udev:roProvides necessary metadata to Scrutiny.
Device Mappings (--device)
Parameter Function /dev/sdaThis is how Scrutiny accesses drives. Optionally supply /dev:/dev instead for all devices. /dev/sdbA second drive. /dev/nvme1n1An NVMe drive. NVMe requires --cap-add=SYS_ADMIN.
Miscellaneous Options
Parameter Function
Portainer notice
{% hint style="warning" %} This image utilises cap_add or sysctl to work properly. This is not implemented properly in some versions of Portainer, thus this image may not work if deployed through Portainer.
Environment variables from files (Docker secrets)
You can set any environment variable from a file by using a special prepend FILE__.
As an example:
-e FILE__PASSWORD=/run/secrets/mysecretpassword
Will set the environment variable PASSWORD based on the contents of the /run/secrets/mysecretpassword file.
Umask for running applications
For all of our images we provide the ability to override the default umask settings for services started within the containers using the optional -e UMASK=022 setting. Keep in mind umask is not chmod it subtracts from permissions based on it's value it does not add. Please read up here before asking for support.
User / Group Identifiers
When using volumes (-v flags), permissions issues can arise between the host OS and the container, we avoid this issue by allowing you to specify the user PUID and group PGID.
Ensure any volume directories on the host are owned by the same user you specify and any permissions issues will vanish like magic.
In this instance PUID=1000 and PGID=1000, to find yours use id user as below:
$ id username
uid=1000(dockeruser) gid=1000(dockergroup) groups=1000(dockergroup)
Docker Mods
We publish various Docker Mods to enable additional functionality within the containers. The list of Mods available for this image (if any) as well as universal mods that can be applied to any one of our images can be accessed via the dynamic badges above.
Support Info
- Shell access whilst the container is running:
docker exec -it scrutiny /bin/bash- To monitor the logs of the container in realtime:
docker logs -f scrutiny- Container version number
docker inspect -f '{{ index .Config.Labels "build_version" }}' scrutiny- Image version number
docker inspect -f '{{ index .Config.Labels "build_version" }}' lscr.io/linuxserver/scrutiny:latest
Versions
- 13.06.22: - Deprecate container.
- 19.01.22: - Rebase to Alpine 3.15.
- 22.11.20: - Added fix for
nsswitch.conf to resolve local hosts - 17.09.20: - Initial Release.
\ No newline at end of file
diff --git a/images/docker-swag/index.html b/images/docker-swag/index.html
index 69ed3f87cd..50be5a5ef4 100644
--- a/images/docker-swag/index.html
+++ b/images/docker-swag/index.html
@@ -47,7 +47,7 @@ services:
-v /path/to/appdata/config:/config \
--restart unless-stopped \
lscr.io/linuxserver/swag:latest
-
Parameters
Docker images are configured using parameters passed at runtime (such as those above). These parameters are separated by a colon and indicate <external>:<internal> respectively. For example, -p 8080:80 would expose port 80 from inside the container to be accessible from the host's IP on port 8080 outside the container.
Ports (-p)
Parameter Function 443Https port 80Http port (required for http validation and http -> https redirect)
Environment Variables (-e)
Env Function PUID=1000for UserID - see below for explanation PGID=1000for GroupID - see below for explanation TZ=Europe/LondonSpecify a timezone to use EG Europe/London. URL=yourdomain.urlTop url you have control over (customdomain.com if you own it, or customsubdomain.ddnsprovider.com if dynamic dns). VALIDATION=httpCertbot validation method to use, options are http or dns (dns method also requires DNSPLUGIN variable set). SUBDOMAINS=www,Subdomains you'd like the cert to cover (comma separated, no spaces) ie. www,ftp,cloud. For a wildcard cert, set this exactly to wildcard (wildcard cert is available via dns validation only) CERTPROVIDER=Optionally define the cert provider. Set to zerossl for ZeroSSL certs (requires existing ZeroSSL account and the e-mail address entered in EMAIL env var). Otherwise defaults to Let's Encrypt. DNSPLUGIN=cloudflareRequired if VALIDATION is set to dns. Options are acmedns, aliyun, azure, cloudflare, cpanel, desec, digitalocean, directadmin, dnsimple, dnsmadeeasy, dnspod, do, domeneshop, duckdns, dynu, gandi, gehirn, godaddy, google, he, hetzner, infomaniak, inwx, ionos, linode, loopia, luadns, netcup, njalla, nsone, ovh, porkbun, rfc2136, route53, sakuracloud, standalone, transip, and vultr. Also need to enter the credentials into the corresponding ini (or json for some plugins) file under /config/dns-conf. PROPAGATION=Optionally override (in seconds) the default propagation time for the dns plugins. EMAIL=Optional e-mail address used for cert expiration notifications (Required for ZeroSSL). ONLY_SUBDOMAINS=falseIf you wish to get certs only for certain subdomains, but not the main domain (main domain may be hosted on another machine and cannot be validated), set this to true EXTRA_DOMAINS=Additional fully qualified domain names (comma separated, no spaces) ie. extradomain.com,subdomain.anotherdomain.org,*.anotherdomain.org STAGING=falseSet to true to retrieve certs in staging mode. Rate limits will be much higher, but the resulting cert will not pass the browser's security test. Only to be used for testing purposes.
Volume Mappings (-v)
Volume Function /configAll the config files including the webroot reside here.
Miscellaneous Options
Parameter Function
Portainer notice
{% hint style="warning" %} This image utilises cap_add or sysctl to work properly. This is not implemented properly in some versions of Portainer, thus this image may not work if deployed through Portainer. {% endhint %}
Environment variables from files (Docker secrets)
You can set any environment variable from a file by using a special prepend FILE__.
As an example:
-e FILE__PASSWORD=/run/secrets/mysecretpassword
+
Parameters
Docker images are configured using parameters passed at runtime (such as those above). These parameters are separated by a colon and indicate <external>:<internal> respectively. For example, -p 8080:80 would expose port 80 from inside the container to be accessible from the host's IP on port 8080 outside the container.
Ports (-p)
Parameter Function 443Https port 80Http port (required for http validation and http -> https redirect)
Environment Variables (-e)
Env Function PUID=1000for UserID - see below for explanation PGID=1000for GroupID - see below for explanation TZ=Europe/LondonSpecify a timezone to use EG Europe/London. URL=yourdomain.urlTop url you have control over (customdomain.com if you own it, or customsubdomain.ddnsprovider.com if dynamic dns). VALIDATION=httpCertbot validation method to use, options are http or dns (dns method also requires DNSPLUGIN variable set). SUBDOMAINS=www,Subdomains you'd like the cert to cover (comma separated, no spaces) ie. www,ftp,cloud. For a wildcard cert, set this exactly to wildcard (wildcard cert is available via dns validation only) CERTPROVIDER=Optionally define the cert provider. Set to zerossl for ZeroSSL certs (requires existing ZeroSSL account and the e-mail address entered in EMAIL env var). Otherwise defaults to Let's Encrypt. DNSPLUGIN=cloudflareRequired if VALIDATION is set to dns. Options are acmedns, aliyun, azure, cloudflare, cpanel, desec, digitalocean, directadmin, dnsimple, dnsmadeeasy, dnspod, do, domeneshop, duckdns, dynu, gandi, gehirn, godaddy, google, he, hetzner, infomaniak, inwx, ionos, linode, loopia, luadns, netcup, njalla, nsone, ovh, porkbun, rfc2136, route53, sakuracloud, standalone, transip, and vultr. Also need to enter the credentials into the corresponding ini (or json for some plugins) file under /config/dns-conf. PROPAGATION=Optionally override (in seconds) the default propagation time for the dns plugins. EMAIL=Optional e-mail address used for cert expiration notifications (Required for ZeroSSL). ONLY_SUBDOMAINS=falseIf you wish to get certs only for certain subdomains, but not the main domain (main domain may be hosted on another machine and cannot be validated), set this to true EXTRA_DOMAINS=Additional fully qualified domain names (comma separated, no spaces) ie. extradomain.com,subdomain.anotherdomain.org,*.anotherdomain.org STAGING=falseSet to true to retrieve certs in staging mode. Rate limits will be much higher, but the resulting cert will not pass the browser's security test. Only to be used for testing purposes.
Volume Mappings (-v)
Volume Function /configAll the config files including the webroot reside here.
Miscellaneous Options
Parameter Function
Portainer notice
{% hint style="warning" %} This image utilises cap_add or sysctl to work properly. This is not implemented properly in some versions of Portainer, thus this image may not work if deployed through Portainer.
Environment variables from files (Docker secrets)
You can set any environment variable from a file by using a special prepend FILE__.
As an example:
-e FILE__PASSWORD=/run/secrets/mysecretpassword
Will set the environment variable PASSWORD based on the contents of the /run/secrets/mysecretpassword file.
Umask for running applications
For all of our images we provide the ability to override the default umask settings for services started within the containers using the optional -e UMASK=022 setting. Keep in mind umask is not chmod it subtracts from permissions based on it's value it does not add. Please read up here before asking for support.
User / Group Identifiers
When using volumes (-v flags), permissions issues can arise between the host OS and the container, we avoid this issue by allowing you to specify the user PUID and group PGID.
Ensure any volume directories on the host are owned by the same user you specify and any permissions issues will vanish like magic.
In this instance PUID=1000 and PGID=1000, to find yours use id user as below:
$ id username
uid=1000(dockeruser) gid=1000(dockergroup) groups=1000(dockergroup)
Docker Mods
We publish various Docker Mods to enable additional functionality within the containers. The list of Mods available for this image (if any) as well as universal mods that can be applied to any one of our images can be accessed via the dynamic badges above.
Support Info
- Shell access whilst the container is running:
docker exec -it swag /bin/bash- To monitor the logs of the container in realtime:
docker logs -f swag- Container version number
docker inspect -f '{{ index .Config.Labels "build_version" }}' swag- Image version number
docker inspect -f '{{ index .Config.Labels "build_version" }}' lscr.io/linuxserver/swag:latest
Versions
- 08.12.22: - Revamp certbot init.
- 03.12.22: - Remove defunct cloudxns plugin.
- 22.11.22: - Pin acme to the same version as certbot.
- 22.11.22: - Pin certbot to 1.32.0 until plugin compatibility improves.
- 05.11.22: - Update acmedns plugin handling.
- 06.10.22: - Switch to certbot-dns-duckdns. Update cpanel and gandi dns plugin handling. Minor adjustments to init logic.
- 05.10.22: - Use certbot file hooks instead of command line hooks
- 04.10.22: - Add godaddy and porkbun dns plugins.
- 03.10.22: - Add default_server back to default site conf's https listen.
- 22.09.22: - Added support for DO DNS validation.
- 22.09.22: - Added certbot-dns-acmedns for DNS01 validation.
- 20.08.22: - Existing users should update: nginx.conf - Rebasing to alpine 3.15 with php8. Restructure nginx configs (see changes announcement).
- 10.08.22: - Added support for Dynu DNS validation.
- 18.05.22: - Added support for Azure DNS validation.
- 09.04.22: - Added certbot-dns-loopia for DNS01 validation.
- 05.04.22: - Added support for standalone DNS validation.
- 28.03.22: - created a logfile for fail2ban nginx-unauthorized in /etc/cont-init.d/50-config
- 09.01.22: - Added a fail2ban jail for nginx unauthorized
- 21.12.21: - Fixed issue with iptables not working as expected
- 30.11.21: - Move maxmind to a new mod
- 22.11.21: - Added support for Infomaniak DNS for certificate generation.
- 20.11.21: - Added support for dnspod validation.
- 15.11.21: - Added support for deSEC DNS for wildcard certificate generation.
- 26.10.21: - Existing users should update: proxy.conf - Mitigate https://httpoxy.org/ vulnerabilities. Ref: https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx#Defeating-the-Attack-using-NGINX-and-NGINX-Plus
- 23.10.21: - Fix Hurricane Electric (HE) DNS validation.
- 12.10.21: - Fix deprecated LE root cert check to fix failures when using
STAGING=true, and failures in revoking. - 06.10.21: - Added support for Hurricane Electric (HE) DNS validation. Added lxml build deps.
- 01.10.21: - Check if the cert uses the old LE root cert, revoke and regenerate if necessary. Here's more info on LE root cert expiration
- 19.09.21: - Add an optional header to opt out of Google FLoC in
ssl.conf. - 17.09.21: - Mark
SUBDOMAINS var as optional. - 01.08.21: - Add support for ionos dns validation.
- 15.07.21: - Fix libmaxminddb issue due to upstream change.
- 07.07.21: - Rebase to alpine 3.14.
- 24.06.21: - Update default nginx conf folder.
- 28.05.21: - Existing users should update: authelia-server.conf - Use
resolver.conf and patch for CVE-2021-32637. - 20.05.21: - Modify resolver.conf generation to detect and ignore ipv6.
- 14.05.21: - Existing users should update: nginx.conf, ssl.conf, proxy.conf, and the default site-conf - Rework nginx.conf to be inline with alpine upstream and relocate lines from other files. Use linuxserver.io wheel index for pip packages. Switch to using ffdhe4096 for
dhparams.pem per RFC7919. Added worker_processes.conf, which sets the number of nginx workers, and resolver.conf, which sets the dns resolver. Both conf files are auto-generated only on first start and can be user modified later. - 21.04.21: - Existing users should update: authelia-server.conf and authelia-location.conf - Add remote name/email headers and pass http method.
- 12.04.21: - Add php7-gmp and php7-pecl-mailparse.
- 12.04.21: - Add support for vultr dns validation.
- 14.03.21: - Add support for directadmin dns validation.
- 12.02.21: - Clean up rust/cargo cache, which ballooned the image size in the last couple of builds.
- 10.02.21: - Fix aliyun, domeneshop, inwx and transip dns confs for existing users.
- 09.02.21: - Rebasing to alpine 3.13. Add nginx mods brotli and dav-ext. Remove nginx mods lua and lua-upstream (due to regression over the last couple of years).
- 26.01.21: - Add support for hetzner dns validation.
- 20.01.21: - Add check for ZeroSSL EAB retrieval.
- 08.01.21: - Add support for getting certs from ZeroSSL via optional
CERTPROVIDER env var. Update aliyun, domeneshop, inwx and transip dns plugins with the new plugin names. Hide donoteditthisfile.conf because users were editing it despite its name. Suppress harmless error when no proxy confs are enabled. - 03.01.21: - Existing users should update: /config/nginx/site-confs/default.conf - Add helper pages to aid troubleshooting
- 10.12.20: - Add support for njalla dns validation
- 09.12.20: - Check for template/conf updates and notify in the log. Add support for gehirn and sakuracloud dns validation.
- 01.11.20: - Add support for netcup dns validation
- 29.10.20: - Existing users should update: ssl.conf - Add frame-ancestors to Content-Security-Policy.
- 04.10.20: - Existing users should update: nginx.conf, proxy.conf, and ssl.conf - Minor cleanups and reordering.
- 20.09.20: - Existing users should update: nginx.conf - Added geoip2 configs. Added MAXMINDDB_LICENSE_KEY variable to readme.
- 08.09.20: - Add php7-xsl.
- 01.09.20: - Existing users should update: nginx.conf, proxy.conf, and various proxy samples - Global websockets across all configs.
- 03.08.20: - Initial release.
\ No newline at end of file
diff --git a/images/docker-wireguard/index.html b/images/docker-wireguard/index.html
index a43a97cb02..4d8763a758 100644
--- a/images/docker-wireguard/index.html
+++ b/images/docker-wireguard/index.html
@@ -46,7 +46,7 @@ services:
--sysctl="net.ipv4.conf.all.src_valid_mark=1" \
--restart unless-stopped \
lscr.io/linuxserver/wireguard:latest
-Parameters
Docker images are configured using parameters passed at runtime (such as those above). These parameters are separated by a colon and indicate <external>:<internal> respectively. For example, -p 8080:80 would expose port 80 from inside the container to be accessible from the host's IP on port 8080 outside the container.
Ports (-p)
| Parameter | Function |
|---|---|
51820/udp | wireguard port |
Environment Variables (-e)
| Env | Function |
|---|---|
PUID=1000 | for UserID - see below for explanation |
PGID=1000 | for GroupID - see below for explanation |
TZ=Europe/London | Specify a timezone to use EG Europe/London |
SERVERURL=wireguard.domain.com | External IP or domain name for docker host. Used in server mode. If set to auto, the container will try to determine and set the external IP automatically |
SERVERPORT=51820 | External port for docker host. Used in server mode. |
PEERS=1 | Number of peers to create confs for. Required for server mode. Can also be a list of names: myPC,myPhone,myTablet (alphanumeric only) |
PEERDNS=auto | DNS server set in peer/client configs (can be set as 8.8.8.8). Used in server mode. Defaults to auto, which uses wireguard docker host's DNS via included CoreDNS forward. |
INTERNAL_SUBNET=10.13.13.0 | Internal subnet for the wireguard and server and peers (only change if it clashes). Used in server mode. |
ALLOWEDIPS=0.0.0.0/0 | The IPs/Ranges that the peers will be able to reach using the VPN connection. If not specified the default value is: '0.0.0.0/0, ::0/0' This will cause ALL traffic to route through the VPN, if you want split tunneling, set this to only the IPs you would like to use the tunnel AND the ip of the server's WG ip, such as 10.13.13.1. |
LOG_CONFS=true | Generated QR codes will be displayed in the docker log. Set to false to skip log output. |
Volume Mappings (-v)
| Volume | Function |
|---|---|
/config | Contains all relevant configuration files. |
/lib/modules | Maps host's modules folder. Only required if compiling wireguard modules. |
Miscellaneous Options
| Parameter | Function |
|---|---|
--sysctl= | Required for client mode. |
Portainer notice
{% hint style="warning" %} This image utilises cap_add or sysctl to work properly. This is not implemented properly in some versions of Portainer, thus this image may not work if deployed through Portainer. {% endhint %}
Environment variables from files (Docker secrets)
You can set any environment variable from a file by using a special prepend FILE__.
As an example:
-e FILE__PASSWORD=/run/secrets/mysecretpassword
+Parameters
Docker images are configured using parameters passed at runtime (such as those above). These parameters are separated by a colon and indicate <external>:<internal> respectively. For example, -p 8080:80 would expose port 80 from inside the container to be accessible from the host's IP on port 8080 outside the container.
Ports (-p)
| Parameter | Function |
|---|---|
51820/udp | wireguard port |
Environment Variables (-e)
| Env | Function |
|---|---|
PUID=1000 | for UserID - see below for explanation |
PGID=1000 | for GroupID - see below for explanation |
TZ=Europe/London | Specify a timezone to use EG Europe/London |
SERVERURL=wireguard.domain.com | External IP or domain name for docker host. Used in server mode. If set to auto, the container will try to determine and set the external IP automatically |
SERVERPORT=51820 | External port for docker host. Used in server mode. |
PEERS=1 | Number of peers to create confs for. Required for server mode. Can also be a list of names: myPC,myPhone,myTablet (alphanumeric only) |
PEERDNS=auto | DNS server set in peer/client configs (can be set as 8.8.8.8). Used in server mode. Defaults to auto, which uses wireguard docker host's DNS via included CoreDNS forward. |
INTERNAL_SUBNET=10.13.13.0 | Internal subnet for the wireguard and server and peers (only change if it clashes). Used in server mode. |
ALLOWEDIPS=0.0.0.0/0 | The IPs/Ranges that the peers will be able to reach using the VPN connection. If not specified the default value is: '0.0.0.0/0, ::0/0' This will cause ALL traffic to route through the VPN, if you want split tunneling, set this to only the IPs you would like to use the tunnel AND the ip of the server's WG ip, such as 10.13.13.1. |
LOG_CONFS=true | Generated QR codes will be displayed in the docker log. Set to false to skip log output. |
Volume Mappings (-v)
| Volume | Function |
|---|---|
/config | Contains all relevant configuration files. |
/lib/modules | Maps host's modules folder. Only required if compiling wireguard modules. |
Miscellaneous Options
| Parameter | Function |
|---|---|
--sysctl= | Required for client mode. |
Portainer notice
{% hint style="warning" %} This image utilises cap_add or sysctl to work properly. This is not implemented properly in some versions of Portainer, thus this image may not work if deployed through Portainer.
Environment variables from files (Docker secrets)
You can set any environment variable from a file by using a special prepend FILE__.
As an example:
-e FILE__PASSWORD=/run/secrets/mysecretpassword
Will set the environment variable PASSWORD based on the contents of the /run/secrets/mysecretpassword file.
Umask for running applications
For all of our images we provide the ability to override the default umask settings for services started within the containers using the optional -e UMASK=022 setting. Keep in mind umask is not chmod it subtracts from permissions based on it's value it does not add. Please read up here before asking for support.
User / Group Identifiers
When using volumes (-v flags), permissions issues can arise between the host OS and the container, we avoid this issue by allowing you to specify the user PUID and group PGID.
Ensure any volume directories on the host are owned by the same user you specify and any permissions issues will vanish like magic.
In this instance PUID=1000 and PGID=1000, to find yours use id user as below:
$ id username
uid=1000(dockeruser) gid=1000(dockergroup) groups=1000(dockergroup)
Docker Mods
We publish various Docker Mods to enable additional functionality within the containers. The list of Mods available for this image (if any) as well as universal mods that can be applied to any one of our images can be accessed via the dynamic badges above.
Support Info
- Shell access whilst the container is running:
docker exec -it wireguard /bin/bash- To monitor the logs of the container in realtime:
docker logs -f wireguard- Container version number
docker inspect -f '{{ index .Config.Labels "build_version" }}' wireguard- Image version number
docker inspect -f '{{ index .Config.Labels "build_version" }}' lscr.io/linuxserver/wireguard:latest
Versions
- 26.10.22: - Better handle unsupported peer names. Improve logging.
- 12.10.22: - Add Alpine branch. Optimize wg and coredns services.
- 09.10.22: - Switch back to iptables-legacy due to issues on some hosts.
- 04.10.22: - Rebase to Jammy. Upgrade to s6v3.
- 16.05.22: - Improve NAT handling in server mode when multiple ethernet devices are present.
- 23.04.22: - Add pre-shared key support. Automatically added to all new peer confs generated, existing ones are left without to ensure no breaking changes.
- 10.04.22: - Rebase to Ubuntu Focal. Add
LOG_CONFSenv var. Remove deprecatedadd-peercommand. - 28.10.21: - Add site-to-site vpn support.
- 11.02.21: - Fix bug related to changing internal subnet and named peer confs not updating.
- 06.10.20: - Disable CoreDNS in client mode, or if port 53 is already in use in server mode.
- 04.10.20: - Allow to specify a list of names as PEERS and add ALLOWEDIPS environment variable. Also, add peer name/id to each one of the peer sections in wg0.conf. Important: Existing users need to delete
/config/templates/peer.confand restart - 27.09.20: - Cleaning service binding example to have accurate PreDown script.
- 06.08.20: - Replace resolvconf with openresolv due to dns issues when a client based on this image is connected to a server also based on this image. Add IPv6 info to readme. Display kernel version in logs.
- 29.07.20: - Update Coredns config to detect dns loops (existing users need to delete
/config/coredns/Corefileand restart). - 27.07.20: - Update Coredns config to prevent issues with non-user-defined bridge networks (existing users need to delete
/config/coredns/Corefileand restart). - 05.07.20: - Add Debian updates and security repos for headers.
- 25.06.20: - Simplify module tests, prevent iptables issues from resulting in false negatives.
- 19.06.20: - Add support for Ubuntu Focal (20.04) kernels. Compile wireguard tools and kernel module instead of using the ubuntu packages. Make module install optional. Improve verbosity in logs.
- 29.05.20: - Add support for 64bit raspbian.
- 28.04.20: - Add Buster/Stretch backports repos for Debian. Tested with OMV 5 and OMV 4 (on kernel 4.19.0-0.bpo.8-amd64).
- 20.04.20: - Fix typo in client mode conf existence check.
- 13.04.20: - Fix bug that forced conf recreation on every start.
- 08.04.20: - Add arm32/64 builds and enable multi-arch (rpi4 with ubuntu and raspbian buster tested). Add CoreDNS for
PEERDNS=autosetting. Update theadd-peer/show-peerscripts to utilize the templates and theINTERNAL_SUBNETvar (previously missed, oops). - 05.04.20: - Add
INTERNAL_SUBNETvariable to prevent subnet clashes. Add templates for server and peer confs. - 01.04.20: - Add
show-peerscript and include info on host installed headers. - 31.03.20: - Initial Release.
