Kasm flooding with kasm_agent error GPU caps helper stderr: amdgpu: os_same_file_description couldn't determine if two DRM fds reference the same file description.

After upgrading Kasm on TrueNAS Scale to 1.19.0, there is a flood of error messages like below.

host: proxy

ingest_date: 20260701143256

application: kasm_agent

levelname: ERROR

process: __main__.handler

server_id: a9d2.............................c74

message

GPU caps helper stderr: amdgpu: os_same_file_description couldn't determine if two DRM fds reference the same file description.

If they do, bad things may happen!

Some online posts suggest that it is MESA issue so changed the Workspaces' Graphics Acceleration Method Preference to DRI3 but it had no effect to the flood of error messages.


Reinstall didn't really fix the issue.

Noticed a message in Kasm Install Settings that said:

GPU acceleration is automatically managed by Kasm Workspaces 1.19.0. Configure GPU settings after installation in the admin panel under Infrastructure > Agents.

hence the 'Passthru available GPU' should be checked even if there is no available GPU?

Still troubleshooting...


[quote="HelpfulSquid, post:4, topic:43812"]

* for GCN 5th gen based GPUs and APUs `HSA_OVERRIDE_GFX_VERSION=9.0.0`

* for RDNA 1 based GPUs and APUs `HSA_OVERRIDE_GFX_VERSION=10.1.0`

* for RDNA 2 based GPUs and APUs `HSA_OVERRIDE_GFX_VERSION=10.3.0`

* for RDNA 3 based GPUs and APUs `HSA_OVERRIDE_GFX_VERSION=11.0.0`



truenas scale app kasm gpu caps helper stderr: amdgpu: os_same_file_description couldn't determine if two drm fds reference the same file description. +11 The amdgpu: os_same_file_description error message is primarily a non-fatal warning generated by libdrm inside the container.

 It indicates that Kasm's GPU detection utility (gpu_caps_helper) cannot cleanly verify if two system file descriptors point to the same underlying AMD GPU device.

In TrueNAS SCALE, this is almost always caused by sandbox isolation or restricted file system permissions preventing the app container from executing the kcmp system call or reading the necessary /dev/dri/ device paths.

Phase 1: Determine if this is a cosmetic warning or a hard failureBefore changing settings, check if the Kasm app is actually broken:Scenario A (Cosmetic Warning): If Kasm deploys successfully and you can use workspaces with hardware acceleration, ignore this message. It is a safe-to-ignore warning from libdrm.Scenario B (Hard Failure): If the app crashes during initialization, hangs on a loop, or fails to utilize your AMD GPU for hardware transcoding/acceleration, proceed with the fixes below.

Phase 2: Fixes for Hard Failures

1. Allocate Allocated GPU Resources in TrueNASTrueNAS SCALE must explicitly pass your AMD GPU into the Kasm container ecosystem.Navigate to the Apps portal in your TrueNAS SCALE dashboard.Select Kasm and click Edit.Scroll down to the GPU Configuration / Resources section.Under AMD/Intel GPU, ensure your specific GPU or integrated graphics (iGPU) is explicitly allocated (e.g., allocating a value of 1).Save the configuration and let the app restart.

2. Configure Manual DRI3 Override (Kasm Environment Variables)When running nested container architectures (like Kasm Workspaces), the inner containers often lose direct reference to render nodes. You can manually bypass Kasm's auto-detection by setting explicit environment variables.In the Kasm App Edit settings menu, scroll to Environment Variables.Add the following key-value pairs to force direct rendering:Key: WEBRTC_HW_ACCEL | Value: trueKey: HSA_OVERRIDE_GFX_VERSION | Value: (Match your AMD architecture)For RDNA 1 (e.g., RX 5000): 10.1For RDNA 2 (e.g., RX 6000): 10.3For RDNA 3 (e.g., RX 7000): 11.0

3. Disable Kasm Agent GPU AutodetectIf gpu_caps_helper is causing your installation or startup hook to fail completely, you can tell Kasm to stop checking the GPU state automatically.Log into your Kasm Admin Web UI.Navigate to Infrastructure ➔ Docker Agents ➔ Edit.Locate your active agent configuration and manually assign the GPU resources, or completely toggle off strict hardware capability checking.Note: Using this method means you should manage your simultaneous workspace sessions manually, as Kasm will no longer query the hardware limits via the broken script.4. Address TrueNAS Dev/Dri Driver BugsIf the GPU completely fails to initiate after a TrueNAS upgrade, the host kernel may have temporarily misconfigured device paths.Open the TrueNAS SCALE Shell.Verify if the host actually has active render links by running:bashls -l /dev/dri

Use code with caution.If /dev/dri is empty or missing, navigate to System Settings ➔ Advanced and verify that your GPU is not accidentally blacklisted under Isolated GPU Devices. If it is isolated, remove it and reboot your TrueNAS host.

[/quote]

Comments

Post a Comment

Popular posts from this blog

Proxmox VM PCI Passthru Error MSIX PBA outside of specified BAR

Proxmox VM PCIE Passthru Error  MSIX PBA outside of specified BAR I created a Proxmox VM created for LLM purposes, with a NVIDIA RTX 3060 allocated to it through PCIE Passthru, which there are plenty of literature about. Essentially, Enabled "above 4g decoding" in BIOS. Ensure "Re-size BAR Support" is Disabled in BIOS. In PVE host, blacklist the NVIDIA drivers to ensure it is not used by the host so that the GPU can be passed on to the VM. Create a VM which will use the host's virtual GPU as the primary display. While the VM is offline open Hardware to add PCI device, select the GPU with all functions etc. It worked smoothly with the NVIDIA RTX 3060. Then... Later I replaced NVIDIA RTX 3060 with a RTX 5060Ti, thinking that it should be a smooth upgrade because the new card is using the same PCIE slot & the VM would use the same NVIDIA driver,  Upon replacing the GPU though, the VM would refuse to start with the following error message: MSIX PBA outside of sp...
Read more

Open WebUI cannot see your models in ollama after upgrade

After upgrading Ollama & Open WebUI, my Open WebUI no longer displayed the LLMs in Ollama. Initially I thought it may be to do with the Open WebUI configuration issue so I fiddled around with the IP Addresses of the Ollama API URLs. Especially when I could still access the LLMs in Ollama via Terminal. But a quick search revealed that the most likely cause was Ollama only listening to the local loopback address (127.0.0.1), hence Open WebUI could not connect to Ollama API port. To do so, 1. run the following command in terminal sudo systemctl edit ollama.service 2. Add the following lines in the editor to let Ollama listen to any IP address on the machine [Service] Environment="OLLAMA_HOST=0.0.0.0" 3. Save and close the editor 4. Restart processes and ollama by sudo systemctl daemon-reload sudo systemctl restart ollama   Then the Open WebUI started to show the models available in Ollama.
Read more

Kasm stuck on "Creating a secure connection - 100%" accessing through Cloudflare tunnel

The most likely cause is that your browser failed to establish the WebSocket connection needed to stream the session's audio and visuals, or there is a reverse proxy/firewall misconfiguration blocking Kasm's upstream protocols. If you are accessing Kasm workspace through Cloudflare tunnel especially, then Kasm's internal proxy ports (eg. 30128) wouldn't be reachable because you are accessing the page through: [Your browser] --https--> [hostname on Cloudflare:443] --cloudflare tunnel--> [Kasm host:port] So if your Kasm host uses an internal proxy port like 30128, then your browser has no way of reaching it. The solution is to disable the proxy. Go to Kasm's Admin panel Open Admin > Infrastructure > Zones Edit the default zone Change Proxy Port to 0 (zero) Save/Apply
Read more