</span></code></pre></div><h1id=available-distros>Available Distros<aclass=headerlinkhref=#available-distrostitle="Permanent link">¶</a></h1><p>All base images are built for x86_64 and aarch64 platforms.</p><table><thead><tr><thstyle="text-align: center;">Distro</th><th>Current Tag</th></tr></thead><tbody><tr><tdstyle="text-align: center;">Alpine</td><td>alpine320</td></tr><tr><tdstyle="text-align: center;">Arch</td><td>arch</td></tr><tr><tdstyle="text-align: center;">Debian</td><td>debianbookworm</td></tr><tr><tdstyle="text-align: center;">Fedora</td><td>fedora40</td></tr><tr><tdstyle="text-align: center;">Ubuntu</td><td>ubuntunoble</td></tr></tbody></table><h1id=proot-apps>PRoot Apps<aclass=headerlinkhref=#proot-appstitle="Permanent link">¶</a></h1><p>All images include <ahref=https://github.com/linuxserver/proot-apps>proot-apps</a> which allow portable applications to be installed to persistent storage in the user's <code>$HOME</code> directory. These applications and their settings will persist upgrades of the base container and can be mounted into different flavors of rdesktop containers. IE if you are running an Alpine based container you will be able to use the same <code>/config</code> directory mounted into an Ubuntu based container and retain the same applications and settings as long as they were installed with <code>proot-apps install</code>.</p><p>A list of linuxserver.io supported applications is located <ahref="https://github.com/linuxserver/proot-apps?tab=readme-ov-file#supported-apps">HERE</a>.</p><h1id=i-like-to-read-documentation>I like to read documentation<aclass=headerlinkhref=#i-like-to-read-documentationtitle="Permanent link">¶</a></h1><h2id=building-images>Building images<aclass=headerlinkhref=#building-imagestitle="Permanent link">¶</a></h2><h3id=application-containers>Application containers<aclass=headerlinkhref=#application-containerstitle="Permanent link">¶</a></h3><p>Included in these base images is a simple <ahref=http://openbox.org/>Openbox DE</a> and the accompanying logic needed to launch a single application. Lets look at the bare minimum needed to create an application container starting with a Dockerfile:</p><divclass="language-text highlight"><pre><span></span><code><spanid=__span-1-1><aid=__codelineno-1-1name=__codelineno-1-1href=#__codelineno-1-1></a>FROM ghcr.io/linuxserver/baseimage-rdesktop:alpine320
</span></code></pre></div><p>And we can define the application to start using:</p><divclass="language-text highlight"><pre><span></span><code><spanid=__span-2-1><aid=__codelineno-2-1name=__codelineno-2-1href=#__codelineno-2-1></a>mkdir -p root/defaults
</span></code></pre></div><p>Resulting in a folder that looks like this:</p><divclass="language-text highlight"><pre><span></span><code><spanid=__span-3-1><aid=__codelineno-3-1name=__codelineno-3-1href=#__codelineno-3-1></a>├── Dockerfile
</span></code></pre></div><p>Now build and test:</p><divclass="language-text highlight"><pre><span></span><code><spanid=__span-4-1><aid=__codelineno-4-1name=__codelineno-4-1href=#__codelineno-4-1></a>docker build -t firefox .
</span><spanid=__span-4-2><aid=__codelineno-4-2name=__codelineno-4-2href=#__codelineno-4-2></a>docker run --rm -it -p 3389:3389 firefox bash
</span></code></pre></div><p>On rdp port 3389 you will be presented with a fullscreen firefox window.</p><p>This similar setup can be used to embed any Linux Desktop application in an rdp accesible container.</p><p><strong>If building images it is important to note that many application will not work inside of Docker without <code>--security-opt seccomp=unconfined</code>, they may have launch flags to not use syscalls blocked by Docker like with chromium based applications and <code>--no-sandbox</code>. In general do not expect every application will simply work like a native Linux installation without some modifications</strong></p><h4id=in-container-application-launching>In container application launching<aclass=headerlinkhref=#in-container-application-launchingtitle="Permanent link">¶</a></h4><p>Also included in the init logic is the ability to define application launchers. As the user has the ability to close the application or if they want to open multiple instances of it this can be useful. Here is an example of a menu definition file for Firefox:</p><divclass="language-text highlight"><pre><span></span><code><spanid=__span-5-1><aid=__codelineno-5-1name=__codelineno-5-1href=#__codelineno-5-1></a><?xml version="1.0" encoding="utf-8"?>
</span></code></pre></div><p>Simply create this file and add it to your defaults folder as <code>menu.xml</code>:</p><divclass="language-text highlight"><pre><span></span><code><spanid=__span-6-1><aid=__codelineno-6-1name=__codelineno-6-1href=#__codelineno-6-1></a>├── Dockerfile
</span></code></pre></div><p>This allows users to right click the desktop background to launch the application.</p><h3id=full-desktop-environments>Full Desktop environments<aclass=headerlinkhref=#full-desktop-environmentstitle="Permanent link">¶</a></h3><p>When building an application container we are leveraging the Openbox DE to handle window management, but it is also possible to completely replace the DE that is launched on container init using the <code>startwm.sh</code> script, located again in defaults:</p><divclass="language-text highlight"><pre><span></span><code><spanid=__span-7-1><aid=__codelineno-7-1name=__codelineno-7-1href=#__codelineno-7-1></a>├── Dockerfile
</span></code></pre></div><p>If included in the build logic it will be launched in place of Openbox. Examples for this kind of configuration can be found in our <ahref=https://github.com/linuxserver/docker-rdesktop>rdesktop repository</a></p><h2id=open-source-gpu-acceleration>Open Source GPU Acceleration<aclass=headerlinkhref=#open-source-gpu-accelerationtitle="Permanent link">¶</a></h2><p>For accelerated apps or games, render devices can be mounted into the container and leveraged by applications using:</p><p><code>--device /dev/dri:/dev/dri</code></p><p>This feature only supports <strong>Open Source</strong> GPU drivers:</p><table><thead><tr><thstyle="text-align: center;">Driver</th><th>Description</th></tr></thead><tbody><tr><tdstyle="text-align: center;">Intel</td><td>i965 and i915 drivers for Intel iGPU chipsets</td></tr><tr><tdstyle="text-align: center;">AMD</td><td>AMDGPU, Radeon, and ATI drivers for AMD dedicated or APU chipsets</td></tr><tr><tdstyle="text-align: center;">NVIDIA</td><td>nouveau2 drivers only, closed source NVIDIA drivers lack DRI3 support</td></tr></tbody></table><h2id=nvidia-gpu-support>Nvidia GPU Support<aclass=headerlinkhref=#nvidia-gpu-supporttitle="Permanent link">¶</a></h2><p><strong>Nvidia is not compatible with Alpine based images</strong></p><p>Nvidia support is available by leveraging Zink for OpenGL support. This can be enabled with the following run flags:</p><table><thead><tr><thstyle="text-align: center;">Variable</th><th>Description</th></tr></thead><tbody><tr><tdstyle="text-align: center;">--gpus all</td><td>This can be filtered down but for most setups this will pass the one Nvidia GPU on the system</td></tr><tr><tdstyle="text-align: center;">--runtime nvidia</td><td>Specify the Nvidia runtime which mounts drivers and tools in from the host</td></tr></tbody></table><p>The compose syntax is slightly different for this as you will need to set nvidia as the default runtime:</p><divclass="language-text highlight"><pre><span></span><code><spanid=__span-8-1><aid=__codelineno-8-1name=__codelineno-8-1href=#__codelineno-8-1></a>sudo nvidia-ctk runtime configure --runtime=docker --set-as-default
</span><spanid=__span-8-2><aid=__codelineno-8-2name=__codelineno-8-2href=#__codelineno-8-2></a>sudo service docker restart
</span></code></pre></div><p>And to assign the GPU in compose:</p><divclass="language-text highlight"><pre><span></span><code><spanid=__span-9-1><aid=__codelineno-9-1name=__codelineno-9-1href=#__codelineno-9-1></a>services:
