</span></code></pre></div><p>The web interface has the option for "IME Input Mode" in Settings which will allow non english characters to be used from a non en_US keyboard on the client. Once enabled it will perform the same as a local Linux installation set to your locale.</p><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>alpine319</td></tr><tr><tdstyle="text-align: center;">Arch</td><td>arch</td></tr><tr><tdstyle="text-align: center;">Debian</td><td>debianbullseye</td></tr><tr><tdstyle="text-align: center;">Debian</td><td>debianbookworm</td></tr><tr><tdstyle="text-align: center;">Fedora</td><td>fedora39</td></tr><tr><tdstyle="text-align: center;">Ubuntu</td><td>ubuntujammy</td></tr></tbody></table><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-kasmvnc:alpine318
</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 3000:3000 firefox bash
</span></code></pre></div><p>On http://localhost:3000 you should be presented with a Firefox web browser interface.</p><p>This similar setup can be used to embed any Linux Desktop application in a web 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-webtop>Webtop repository</a></p><h3id=kasm-workspaces-compatibility>Kasm Workspaces compatibility<aclass=headerlinkhref=#kasm-workspaces-compatibilitytitle="Permanent link">¶</a></h3><p>Included in these base images are binary blobs <code>/kasmbins</code> and a special init process <code>/kasminit</code> to maintain compatibility with <ahref=https://www.kasmweb.com/>Kasm Workspaces</a>, If using this base image as reccomended with the <code>startwm.sh</code> or <code>autostart</code> entrypoints. They will be able to be used on that platform without issue.</p><h2id=docker-in-docker-dind>Docker in Docker (DinD)<aclass=headerlinkhref=#docker-in-docker-dindtitle="Permanent link">¶</a></h2><p>These base images include an installation of Docker that can be used in two ways. The simple method is simply leveraging the Docker/Docker Compose cli bins to manage the host level Docker installation by mounting in <code>-v /var/run/docker.sock:/var/run/docker.sock</code>. </p><p>The base images can also run an isolated in container DinD setup simply by passing <code>--privileged</code> to the container when launching. If for any reason the application needs privilege but Docker is not wanted the <code>-e START_DOCKER=false</code> can be set at runtime or in the Dockerfile. In container Docker (DinD) will most likely use the fuse-overlayfs driver for storage which is not as fast as native overlay2. To increase perormance the <code>/var/lib/docker/</code> directory in the container can be mounted out to a Linux host and will use overlay2. Keep in mind Docker runs as root and the contents of this directory will not respect the PUID/PGID environment variables available on all LinuxServer.io containers.</p><h2id=dri3-gpu-acceleration>DRI3 GPU Acceleration<aclass=headerlinkhref=#dri3-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><p>The <code>DRINODE</code> environment variable can be used to point to a specific GPU. Up to date information can be found <ahref=https://www.kasmweb.com/kasmvnc/docs/master/gpu_acceleration.html>here</a></p><h3id=display-compositing-desktop-effects>Display Compositing (desktop effects)<aclass=headerlinkhref=#display-compositing-desktop-effectstitle="Permanent link">¶</a></h3><p>When using this image in tandem with a supported video card, compositing will function albeit with a performance hit when syncing the frames with pixmaps for the applications using it. This can greatly increase app compatibility if the application in question requires compositing, but requires a real GPU to be mounted into the container. By default we disable compositing at a DE level for performance reasons on our downstream images, but it can be enabled by the user and programs using compositing will still function even if the DE has it disabled in its settings. When building desktop images be sure you understand that with it enabled by default only users that have a compatible GPU mounted in will be able to use your image.</p><h2id=lossless>Lossless<aclass=headerlinkhref=#losslesstitle="Permanent link">¶</a></h2><p>These images support all
