this post was submitted on 22 May 2026
9 points (80.0% liked)

Linux

13744 readers
209 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago
MODERATORS
 

cross-posted from: https://feddit.org/post/30198502

System:

Debian 13 KDE (actually MX Linux, but doesn't seem to matter)  
Wayland (xwayland installed as well)  
Docker 29.5.2

Dockerfile:

FROM debian:trixie

ENV DEBIAN_FRONTEND=noninteractive
ENV LANG=en_US.UTF-8
ENV LANGUAGE=en_US:en
ENV LC_ALL=en_US.UTF-8

# Set locale
RUN apt-get update && apt-get install -y --no-install-recommends \
        locales && \
    apt-get clean && \
    sed -i '/en_US.UTF-8/s/^# //g' /etc/locale.gen && \
    locale-gen

# Install Wayland-specific packages
RUN apt-get update && apt-get install -y --no-install-recommends \
        dbus \
        libwayland-client0 \
        libwayland-egl1 && \
    apt-get clean

# Install X-specific packages
RUN apt-get update && apt-get install -y --no-install-recommends \
        dbus-x11 && \
    apt-get clean

# Add contrib, default is only main
RUN sed -i 's/^Components:.*/Components: main contrib/g' /etc/apt/sources.list.d/debian.sources

# Add 32-bit arch for Steam libraries
RUN dpkg --add-architecture i386

# Install Steam
RUN apt-get update && apt-get install -y --no-install-recommends \
        steam-installer \
        pciutils && \
    apt-get clean

# Additional
# TODO: What is really needed?
RUN apt-get update && apt-get install -y --no-install-recommends \
        vulkan-tools \
        mesa-utils \
        x11-xserver-utils \
        libvulkan1 \
        mesa-vulkan-drivers && \
    apt-get clean

# TODO: Does `-storebeta` even work?
# https://developer.valvesoftware.com/wiki/Command_line_options_(Steam)
CMD ["/usr/games/steam", "-storebeta"]

To run the container:

xhost +
sudo docker run -it --name steam \
    -e XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR \
    -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \
    -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY \
    -e DISPLAY=$DISPLAY \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    --privileged steam:trixie

(The --privileged part is only temporary until I found out which capabilities are actually needed. Please don't run your containers with --privileged.)

I get the GUI dialogs to download Steam just fine, so at least some display forwarding is working:

The installation works fine, but when starting Steam it seems like it's not able to find Vulkan devices and then doesn't open any Steam window. (The container is not stopping and I'm seeing repeated ./steamwebhelper output after this.)

[...]
Running query: 1 - GpuTopology
CVulkanTopology: failed create vulkan instance: -9
CVulkanTopology: failed to create vulkan instanceFailed to query vulkan gpu topology

Failed to query vulkan gpu topology
Response: 
Exit code: -2
[...]
Vulkan missing requested extension 'VK_KHR_surface'.
Vulkan missing requested extension 'VK_KHR_xlib_surface'.
BInit - Unable to initialize Vulkan!
[...]

However, Vulkan is clearly working fine in the container, as this commands displays the cube rendering just fine:

$ sudo docker exec -it steam vkcube
Selected WSI platform: xcb
Selected GPU 0: AMD Radeon RX 550 / 550 Series (RADV POLARIS12), type: DiscreteGpu

(I've also tried it on another (pure) Debian machine with a 2080Ti, but I've got the same issue.)

I've created other GUI containers in the past (Firefox for example) and didn't have these problems.

Does anybody have an idea and can point me in the right direction?

top 14 comments
sorted by: hot top controversial new old
[–] yuman@programming.dev 2 points 7 hours ago (1 children)

you're not passing dri and render128 to docker, how is this supposed to work? as X client?

to anyone else looking for a bit better security wrt gaming, you can limit home folder exposure to wine with winetricks sandbox (eliminates links to anything but c: inside the prefix) and firejail --net=none as command prefix, to disable network access. the latter obv doesn't work with flatpak lutris/heroic/steam.

[–] Lemmchen@feddit.org 1 points 1 hour ago

https://docs.docker.com/engine/containers/run/#runtime-privilege-and-linux-capabilities

The --privileged flag gives all capabilities to the container. When the operator executes docker run --privileged, Docker enables access to all devices on the host, and reconfigures AppArmor or SELinux to allow the container nearly all the same access to the host as processes running outside containers on the host.

A manual --device /dev/dri should not be necessary. I'll make sure to test it nevertheless.

[–] littleomid@feddit.org 15 points 22 hours ago (1 children)
[–] Lemmchen@feddit.org 2 points 22 hours ago (1 children)

So proprietary software doesn't have access to my filesystem. I am also restricting my Flathub usage to verified apps and Steam unfortunately isn't one. And yesterday I learned Snaps don't support strict confinement under Debian.

[–] littleomid@feddit.org 2 points 18 hours ago (1 children)

And you would rather use snaps rather than an unverified flatpak?

[–] Lemmchen@feddit.org 2 points 15 hours ago* (last edited 15 hours ago)

A strictly confined Snap by the original software authors? For sure. The available Snap on Snapcraft.io is by Canonical though, but that'd be fine as well, if I can not get my own solution to work. I'm just a bit puzzled that apparmor on Debian apparently simply doesn't allow for strictly confined Snaps.

[–] cecilkorik@piefed.ca 12 points 22 hours ago (1 children)

Trying to use an immutable docker container to host a program that notoriously self-installs and requires self-updates is, I'm pretty sure, something that comprises one of Dante's circles of hell.

Wrong tool for the job. Don't do this. I consider docker harmful at the best of times, but this is truly something horrible to try to do with it. I'll never understand why people (not just OP, but also developers like Valve) insist on defying and sabotaging and actively working around the distro's package manager. Your software is not a special snowflake, it does not need its own magical install method and its own perfectly curated libraries. Just fucking use what's what the system is already providing and if certain libraries don't have a stable enough interface and have conflicts between versions so bad that you can't even have any different major versions you require installed alongside each other concurrently, then start shaming them or replacing them with alternatives, because having a compatible-except-for-bugs-and-edge-cases library interface is not such an unreasonable ask for a modern system and toolchain. And then we can all just peacefully use our distro's package manager like our lord and savior Debian intended.

[–] Lemmchen@feddit.org 2 points 22 hours ago

It's proprietary software and because of that I don't want to run it unisolated. Yes, I know there's a flatpack, unfortunately it is not by Valve themselves. Yes, I know there's a Snap, unfortunately it is by Canonical.
If I am not able to get Docker to work, I'll probably end up using bubblewrap, like this project here: https://git.sr.ht/~whynothugo/steam-container

[–] liinux@pawb.social 4 points 21 hours ago* (last edited 21 hours ago) (1 children)

I know this not answer your questions, but I was like this years ago, I wanted everything open source, everything in VM or container with minimum permissions, only open source drivers, only flatpak, and all that stuff. I was like that for 3 or 4 years, in the meantime I changed my email address to a provider with better reputation than Google, I stop using everything that was proprietary, stop using Google services. Even did the most stupid thing, deleting my 5 years old Steam account because "I don't need Steam to play, I can pirate games or play open source games so Valve or the companies can't access my data"

And what happened then? While I was happy owning my stuff, I don't have that much things to do on my system, can I play? Yeah, an pirated game through Bottles (since is sandboxes and pirated) but was a pain in the ass, the 50% of the games required at least 2 days setting up Wine to make them work, and I'm not an Linux expert but I know my way around. And by the way, at the moment I was using NVIDIA, and their open source graphics at the moment were shit, not sure how they are now, but you can't literally run Terraria, no joking.

And now that I mentioned NVIDIA open source drivers, at least at the moment you can't even play a video on Firefox because of the stuttering, I can't even try Hyprland or Sway, and even Plasma ran so bad, was so fucking laggy on both Xorg and Wayland.

Oh and the most cancerigneous thing: I distrohopped like 1 time a day searching for the distro with the most compatibility. How many time I wasted on this.

So I suggest you: Don't do that. Don't be me. Want to play? Why don't you set up a dual boot and let Steam only in the secondary OS that you don't want to use? If you want be sure that Steam can't access your other OS, you can encrypt the whole disk or partition. I can tell you, for sure, that videogames are pretty delicate and when you try to run something over different layers, something usually can break and you don't know why.

[–] Lemmchen@feddit.org 4 points 21 hours ago* (last edited 20 hours ago)

Thanks for the input, but I will probably never not want to use Steam and I've accepted non-free firmware blobs a long time ago. All I want is to use a simple sandbox like I use for many other applications (mostly as Docker containers).

[–] minfapper@piefed.social 2 points 20 hours ago

Only tangentially related, but might fill your need for isolation:

https://games-on-whales.github.io/

[–] nublug@piefed.blahaj.zone 1 points 17 hours ago (1 children)

perhaps need to add "--device /dev/dri" or "--gpus all" to the run command to be sure the container has access to the gpu for vulkan?

[–] Lemmchen@feddit.org 2 points 15 hours ago

https://docs.docker.com/engine/containers/run/#runtime-privilege-and-linux-capabilities

The --privileged flag gives all capabilities to the container. When the operator executes docker run --privileged, Docker enables access to all devices on the host, and reconfigures AppArmor or SELinux to allow the container nearly all the same access to the host as processes running outside containers on the host.

A manual --device /dev/dri should not be necessary. I'll make sure to test it nevertheless.

[–] whimsy@lemmy.zip 1 points 20 hours ago

Ooh this is very interesting and dare I say necessary.

Do you have more logs? Also have you considered trying this using some other distro and/or podman?

My approach would be to try getting this working bare metal and then slowly containerise it