issue: Docker MSWindows NVIDIA host default config apparent incompatibility. #5378

Closed
opened 2025-11-11 16:19:17 -06:00 by GiteaMirror · 1 comment
Owner

Originally created by @mirage335 on GitHub (May 29, 2025).

Check Existing Issues

  • I have searched the existing issues and discussions.
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.12 - 2025-05-29

Ollama Version (if applicable)

No response

Operating System

MSWindows 11

Browser (if applicable)

No response

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

Starts OpenWebUI Docker container.

Actual Behavior

Fails to start OpenWebUI Docker container until the WSL2 distribution hosting Docker is reconfigured.

Steps to Reproduce

Install OpenWebUI Docker container with command to use NVIDIA stuff. Run Docker OpenWebUI container.

Logs & Screenshots

(HTTP code 500) server error - failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running prestart hook #0: exit status 1, stdout: , stderr: Auto-detected mode as 'legacy' nvidia-container-cli: mount error: failed to add device rules: unable to generate new device filter program from existing programs: unable to create new device filters program: load program: invalid argument: last insn is not an exit or jmp processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0: unknown

Additional Information

Please see this linked PDF file for full details, including all version numbers, detailed explanations of the underlying issue with NVIDIA, Docker, etc, workaround, etc, links to relevant web pages, etc.

https://github.com/mirage335-special/kit-researchEngine/blob/main/kit/_ref/Why%20the%20open-webui_cuda%20Container%20Fails%20to%20Start%20WSL2%20GPU%20Issue.pdf

The actual workaround itself is simple. Two shell commands on the host should suffice. However, this may or may not be applicable to Linux hosts, and the issue initially occurred with OpenWebUI v0.6.11 Docker container (the v0.6.12 version released the same hour I was diagnosing this, by the time that was installed, I had already applied the workaround).

358854ab7d (diff-f95584720e74ef817cb365a86278305f1924fca503f7c69d61427bc5b6d0dc40R756)

If possible, it might be nice if the OpenWebUI Docker container could implement some configuration change to address this issue. If not, this may need escalation to Docker, NVIDIA, etc.

Improving stability is important, this just happened to me AFAIK before any upgrades of OpenWebUI, Docker, NVIDIA drivers, etc, so I'm not sure I could have been ready for such downtime.

By the way, yes I do override the entrypoint with a custom shell script . Not necessarily related to this bug, but please do not break that if possible.
https://github.com/mirage335-special/kit-researchEngine/blob/main/kit/researchEngine.sh#L773

Originally created by @mirage335 on GitHub (May 29, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.12 - 2025-05-29 ### Ollama Version (if applicable) _No response_ ### Operating System MSWindows 11 ### Browser (if applicable) _No response_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior Starts OpenWebUI Docker container. ### Actual Behavior Fails to start OpenWebUI Docker container until the WSL2 distribution hosting Docker is reconfigured. ### Steps to Reproduce Install OpenWebUI Docker container with command to use NVIDIA stuff. Run Docker OpenWebUI container. ### Logs & Screenshots ``` (HTTP code 500) server error - failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running prestart hook #0: exit status 1, stdout: , stderr: Auto-detected mode as 'legacy' nvidia-container-cli: mount error: failed to add device rules: unable to generate new device filter program from existing programs: unable to create new device filters program: load program: invalid argument: last insn is not an exit or jmp processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0: unknown ``` ### Additional Information Please see this linked PDF file for full details, including all version numbers, detailed explanations of the underlying issue with NVIDIA, Docker, etc, workaround, etc, links to relevant web pages, etc. https://github.com/mirage335-special/kit-researchEngine/blob/main/kit/_ref/Why%20the%20open-webui_cuda%20Container%20Fails%20to%20Start%20WSL2%20GPU%20Issue.pdf The actual workaround itself is simple. Two shell commands on the host should suffice. However, this may or may not be applicable to Linux hosts, and the issue initially occurred with OpenWebUI v0.6.11 Docker container (the v0.6.12 version released the same hour I was diagnosing this, by the time that was installed, I had already applied the workaround). https://github.com/mirage335-special/kit-researchEngine/commit/358854ab7d782f447e66fca43c12fed45d235131#diff-f95584720e74ef817cb365a86278305f1924fca503f7c69d61427bc5b6d0dc40R756 If possible, it might be nice if the OpenWebUI Docker container could implement some configuration change to address this issue. If not, this may need escalation to Docker, NVIDIA, etc. Improving stability is important, this just happened to me AFAIK before any upgrades of OpenWebUI, Docker, NVIDIA drivers, etc, so I'm not sure I could have been ready for such downtime. By the way, yes I do override the entrypoint with a custom shell script . Not necessarily related to this bug, but please do not break that if possible. https://github.com/mirage335-special/kit-researchEngine/blob/main/kit/researchEngine.sh#L773
GiteaMirror added the bug label 2025-11-11 16:19:17 -06:00
Author
Owner

@mirage335 commented on GitHub (May 29, 2025):

Then again, this gets worse. There is no way to make the workaround persist, effective on computer reboot.

Directives in '%USERPROFILE%.wslconfig' and '/etc/wsl.conf' directives do persist and take effect if 'wsl --shutdown' and 'wsl -d docker-desktop sysctl -a | grep 'bpf_jit_harden' commands are given. However, on computer reboot, seems Docker Desktop starts this 'docker-desktop' WSL2 instance in such a way that these commands either do not take effect or are not yet acted on. The docker-desktop sysctl -a | grep 'bpf_jit_harden' again shows the maximum hardening value of '2' which is incompatible with the OpenWebUI Docker container using NVIDIA drivers.

I guess the workaround is really to just not use containers with NVIDIA (ie. using the generic OpenWebUI Docker container without NVIDIA support).

@mirage335 commented on GitHub (May 29, 2025): Then again, this gets worse. There is no way to make the workaround persist, effective on computer reboot. Directives in '%USERPROFILE%\.wslconfig' and '/etc/wsl.conf' directives do persist and take effect if 'wsl --shutdown' and 'wsl -d docker-desktop sysctl -a | grep 'bpf_jit_harden' commands are given. However, on computer reboot, seems Docker Desktop starts this 'docker-desktop' WSL2 instance in such a way that these commands either do not take effect or are not yet acted on. The docker-desktop sysctl -a | grep 'bpf_jit_harden' again shows the maximum hardening value of '2' which is incompatible with the OpenWebUI Docker container using NVIDIA drivers. I guess the workaround is really to just not use containers with NVIDIA (ie. using the generic OpenWebUI Docker container without NVIDIA support).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#5378