anticholium

Just ssh in your Unraid server and execute the given command but replace 'steam-headless' with 'SteamHeadless', i.e. don‘t use the container console in this case

well ok, I can't tell for sure, but there won't be the same modesetting driver related bug in parallel that I was experiencing with my Blackwell-GPU (5060)...

host terminal, you execute the commands inside the docker though

additionally post the result of this command: docker exec steam-headless bash -lc ' echo "=== /usr/bin/start-dumb-udev.sh in current container ===" ls -l /usr/bin/start-dumb-udev.sh echo nl -ba /usr/bin/start-dumb-udev.sh '

also your syslog has multiple lines with May 2 10:58:36 Loki acpid: input device has been disconnected, fd 10 May 2 10:58:38 Loki kernel: input: Mouse passthrough as /devices/virtual/input/input275 May 2 10:58:38 Loki kernel: input: Mouse passthrough (absolute) as /devices/virtual/input/input276 May 2 10:58:38 Loki kernel: input: Keyboard passthrough as /devices/virtual/input/input277 May 2 10:58:38 Loki kernel: input: Sunshine Nintendo (virtual) pad as /devices/virtual/input/input278 May 2 10:58:38 Loki kernel: input: Sunshine X-Box One (virtual) pad as /devices/virtual/input/input279 May 2 10:58:38 Loki elogind-daemon[2149]: Watching system buttons on /dev/input/event7 (Keyboard passthrough) May 2 10:58:38 Loki kernel: traps: light-locker[133722] trap int3 ip:14a5b214fa77 sp:7ffc59149ee0 error:0 in libglib-2.0.so.0.8400.4[66a77,14a5b2108000+a1000] after the modesetting related bug (which was preventing a display beeing initializable and therfore no xorg etc) was resolved by the recent driverupdate to 595.71.05, I was stuck to a somehow udev realted crashloop, which I was trying to manually workaround (wihtout longlasting effect)... – I can tell you the way by which I currently have a running/working steam-headless, but let's see your results first, since your case is maybe different in detail and my workaround might not help you... also try this docker command and provide the results: docker exec steam-headless bash -lc ' tail -200 /home/default/.cache/log/xorg.err.log 2>/dev/null \ | grep -Ei "EE|fatal|failed|evdev|input|nvidia|screen|permission|no such|segmentation|backtrace|Server is already active" '

Your having a somehow comparable crashloop I was experiecing until recently, where Xorg is exiting (status 1) and all following processes like xvnc11 and sunshine are exiting too, therefore no working webvnc and sinshine and consecutive no working moonlight streaming. In the beginning, there was a nvidia modesetting related error, which prevented a virtual display to be initialized so maybe you can provide your xorg.log (for e.g. docker exec steam-headless bash -lc 'tail -200 /home/default/.cache/log/xorg.err.log') and also some simple check if nvidia smi is working inside your container (by docker exec steam-headless bash -lc 'nvidia-smi').

please provide the containers logs, docker run command and system diagnostics

Xorg related crashloop, somehow in the context of a udev associated script... – My complex manual workaround somewhere above wasn't very reliable, when there was a pause in input and/or temporary gamepad disconnection/reconnection, it mostly crashed. I was tired of further debugging and trying to fix issues manually. Then I backuped everything and tried the current steam-headless via cli manually in a seperate test container, installed everything from scratch -> no crashloops, xorg and following processes running, stable, everything worked from the first try, steam, big picture, controller de-/reconnects, no issues. I removed the temporary test-container and made a clean reinstall of steam-headless with latest container images via Unraid CA, fresh appdata folder, everything from scratch except Steam library. Container ended up in the know xorg initiated crashloop again! So why was it, that the test container worked without any issues? I removed the whole steam-headless container and made a fresh and complete re-install via cli with docker commands etc., container starting without any issues, sunshine worked, moonlight pairing as expected, steam install, mapping of steam library, big picture -> games starting as they should, no crashes for many hour right now... I don't get it!

if interested in any details

That's exactly what I couldn't do, because I have a 5060Ti (Blackwell) and therefore dependent to the open kernel modules, which in turn prevented any driver downgrade under Unraid. – That said: the acutal unraid/driver upgrade (7.2.5/6.12.85/595.71.05) fixed the bug with "Failed to acquire modesetting permission" issue. before: NVIDIA(GPU-0): Failed to acquire modesetting permission xorg FATAL Sunshine Found [0] outputsafter: xorg RUNNING DISPLAY :55 OK Sunshine Found [1] outputs Detected display: HDMI-0 connected: true Found H.264 encoder: h264_nvenc Found HEVC encoder: hevc_nvenc Found AV1 encoder: av1_nvencBUT: There is now a separate second issue in the container stack: a crash/restart loop related to Sunshine virtual input devices and /dev/input/event* handling. That appears to be separate from the original NVIDIA modesetting problem, which I was only able to "fix" with a crazy manual workaround. Ther should be a way better solution by fixing the issue upstream...

Update / findings concerning "failed to acquire modesetting permission issue" in the context of steam-headless and consecutive xorg, xvnc and sunshine crashloop: After further testing and updating the plugin/driver to latest open source, the original "Failed to acquire modesetting permission" issue appears to be related to the NVIDIA 595 driver branch and the host GUI / DRM modesetting state, not simply a Docker or container configuration mistake. before: NVIDIA(GPU-0): Failed to acquire modesetting permission xorg FATAL Sunshine Found [0] outputsafter: xorg RUNNING DISPLAY :55 OK Sunshine Found [1] outputs Detected display: HDMI-0 connected: true Found H.264 encoder: h264_nvenc Found HEVC encoder: hevc_nvenc Found AV1 encoder: av1_nvencThere is now a separate second issue in the container stack: a crash/restart loop related to Sunshine virtual input devices and /dev/input/event* handling. That appears to be separate from the original NVIDIA modesetting problem. And ich77, you already wondered about the many "input devices" related lines with in my syslog, so another independent issue I try to adress at the steam-headless support forum and github respectively. Thank you so much for your work!

Oh, that's weird, I obviously didn't realize that before. Thank you nontheless.

another unraid user was able to resolve the same bug by rolling back to 580.142, since he has a RTX 3060, so not dependent on open source kernel modules. 590.48.01 did only work partially... Any thougts on that? the linuxserver image, as expected, didn't work because of not supporting open source driver... – any "clean" option to manually downgrade to https://github.com/unraid/unraid-nvidia-driver/releases/download/6.12.54-Unraid/nvos-580.95.05-6.12.54-Unraid-1.txz ? https://github.com/Steam-Headless/docker-steam-headless/issues/224

I didn't try the linuxserver.io image, since it doesn't have moonlight/sunshine support implemented, it's "only" web accessible... – Maybe I should try it nontheless. – Concerning the xorg test on the host itself: how would a window manager or a desktop session help without an initialized/initializable display? I thougt its roughly this: xorg starts, loads the driver, gpu/display/screen is initialized, x display is provided, then the window manager!? No? But the host xorg logs show that it's already failing at step 3, initializing the display, like in the steam-headless container. I just thought, that even a full blown desktop environment would fail also with high probability because of that? But I will try to run unraid in GUI mode and run the test again. Thank you for your efforts, I really appreciate your answers! from the logs: NVIDIA dlloader X Driver 595.58.03 NVIDIA GLX Module 595.58.03 NVIDIA GPU NVIDIA GeForce RTX 5060 Ti (GB206-A) at PCI:1:0:0 Option "UseDisplayDevice" "DFP-0" ... NVIDIA(GPU-0): Failed to acquire modesetting permission. NVIDIA(0): Failing initialization of X screen PS: yes, Plex for eg successfully uses the gpu for transcoding PPS: linuxserver.io: "Nvidia support only works on 580 and up full proprietary drivers (no MIT/GPL)" so not suitable for me at all (blackwell architecture, open source, you know that way better than me).