issue: v0.6.33 default model does not populate for standard users #6641

Closed
opened 2025-11-11 17:02:03 -06:00 by GiteaMirror · 13 comments
Owner

Originally created by @tkg61 on GitHub (Oct 9, 2025).

Check Existing Issues

  • I have searched for any existing and/or related issues.
  • I have searched for any existing and/or related discussions.
  • I am using the latest version of Open WebUI.

Installation Method

Other

Open WebUI Version

v0.6.33

Ollama Version (if applicable)

No response

Operating System

Ubuntu / K8s

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

When upgrading from 0.6.32, the admin selected default model would continue to show for standard users

Actual Behavior

The default model no longer populates and "Select a model" is the prefilled option. Downgrading to 0.6.32 fixes the issue

Admins continue to have the default model work for them. Only a standard user experiences the issue

Steps to Reproduce

  • Start with a 0.6.32 system
  • have a public model or workspace model available
  • As an admin, select a model to be the default model
  • upgrade to 0.6.33
  • Login with a standard user account
  • You will not see the model prepopulated but it will be in the dropdown if you click it

Logs & Screenshots

Not working: Image

Working:

Image

Additional Information

No response

Originally created by @tkg61 on GitHub (Oct 9, 2025). ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Other ### Open WebUI Version v0.6.33 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu / K8s ### 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 When upgrading from 0.6.32, the admin selected default model would continue to show for standard users ### Actual Behavior The default model no longer populates and "Select a model" is the prefilled option. Downgrading to 0.6.32 fixes the issue Admins continue to have the default model work for them. Only a standard user experiences the issue ### Steps to Reproduce - Start with a 0.6.32 system - have a public model or workspace model available - As an admin, select a model to be the default model - upgrade to 0.6.33 - Login with a standard user account - You will not see the model prepopulated but it will be in the dropdown if you click it ### Logs & Screenshots Not working: <img width="1288" height="338" alt="Image" src="https://github.com/user-attachments/assets/0904026a-0482-418d-ac34-18af740a889c" /> Working: <img width="1526" height="335" alt="Image" src="https://github.com/user-attachments/assets/0d4ef418-12f5-4489-b659-fd84551bb92a" /> ### Additional Information _No response_
GiteaMirror added the bug label 2025-11-11 17:02:03 -06:00
Author
Owner

@frenzybiscuit commented on GitHub (Oct 9, 2025):

I don’t have this issue but my user is in a group. If you add the user to groups and they have access to the models section of workspace does this still happen?

@frenzybiscuit commented on GitHub (Oct 9, 2025): I don’t have this issue but my user is in a group. If you add the user to groups and they have access to the models section of workspace does this still happen?
Author
Owner

@tkg61 commented on GitHub (Oct 9, 2025):

I don’t have this issue but my user is in a group. If you add the user to groups and they have access to the models section of workspace does this still happen?

Yes, i have tried:

  • models that are made public via admins settings
  • models from workspace that has public settings
  • a user in a group that has model access to workspaces with a public model created in workspace
  • a user in a group that has write access to the model that is permissioned to a group

log out and back in to confirm and it doesn't default to the chat.

@tkg61 commented on GitHub (Oct 9, 2025): > I don’t have this issue but my user is in a group. If you add the user to groups and they have access to the models section of workspace does this still happen? Yes, i have tried: - models that are made public via admins settings - models from workspace that has public settings - a user in a group that has model access to workspaces with a public model created in workspace - a user in a group that has write access to the model that is permissioned to a group log out and back in to confirm and it doesn't default to the chat.
Author
Owner

@cableman commented on GitHub (Oct 13, 2025):

I see the same issue in 0.6.33

@cableman commented on GitHub (Oct 13, 2025): I see the same issue in 0.6.33
Author
Owner

@Lyhtande commented on GitHub (Oct 13, 2025):

Confirmation of Issue with User-Level Direct Connections

I can confirm this issue, but only in a specific case: when a user sets up a direct connection under User Settings → Connections.

In that case, none of the models (e.g. gpt-4.1-mini) are available in the dropdown during workspace model creation — even though:

  • The model is correctly assigned to the user's group via admin settings
  • The same model is accessible via a working admin-level connection
  • The API key used for the direct connection has full permissions (All)
  • The OpenAI endpoint is https://api.openai.com/v1 with Bearer authentication
  • No model IDs are set (so all available models should be fetched)

Additionally, in the browser console I get this error when clicking "Verify connection":

Uncaught (in promise) SyntaxError: Unexpected end of JSON input
    at JSON.parse ...

The direct connection seems to be broken — it never gets marked as used in OpenAI's API key dashboard, and no models become available when this connection is active.

Summary:
Direct connections currently break model access for the user, even when everything is configured correctly. This is not an issue of group permissions or model availability — it seems to be a bug in how OpenWebUI handles user-level direct connections (at least for OpenAI in my case).

@Lyhtande commented on GitHub (Oct 13, 2025): ### Confirmation of Issue with User-Level Direct Connections I can confirm this issue, but only in a specific case: when a user sets up a direct connection under **User Settings → Connections**. In that case, none of the models (e.g. `gpt-4.1-mini`) are available in the dropdown during workspace model creation — even though: - The model is correctly assigned to the user's group via admin settings - The same model is accessible via a working admin-level connection - The API key used for the direct connection has full permissions (`All`) - The OpenAI endpoint is `https://api.openai.com/v1` with **Bearer** authentication - No model IDs are set (so all available models should be fetched) Additionally, in the browser console I get this error when clicking **"Verify connection"**: ```js Uncaught (in promise) SyntaxError: Unexpected end of JSON input at JSON.parse ... ```` The direct connection seems to be broken — it never gets marked as *used* in OpenAI's API key dashboard, and no models become available when this connection is active. **Summary:** Direct connections currently break model access for the user, even when everything is configured correctly. This is not an issue of group permissions or model availability — it seems to be a bug in how OpenWebUI handles user-level direct connections (at least for OpenAI in my case).
Author
Owner

@jimbo-p commented on GitHub (Oct 13, 2025):

Same issue in 0.6.33. Any users who have not set a default model themselves are forced to select one from the drop down (admin default settings will not apply).

@jimbo-p commented on GitHub (Oct 13, 2025): Same issue in 0.6.33. Any users who have not set a default model themselves are forced to select one from the drop down (admin default settings will not apply).
Author
Owner

@nekomiya-hinata commented on GitHub (Oct 14, 2025):

I'm facing the same issue in version 0.6.33. The default model set by the administrator is not being populated as the user's default model.

However, if a user sets their own default model, it works correctly.

The drag-and-drop sorting feature on the model settings page also stopped working. After downgrading to v0.6.32, it returned to normal.

@nekomiya-hinata commented on GitHub (Oct 14, 2025): I'm facing the same issue in version 0.6.33. The default model set by the administrator is not being populated as the user's default model. However, if a user sets their own default model, it works correctly. The drag-and-drop sorting feature on the model settings page also stopped working. After downgrading to v0.6.32, it returned to normal.
Author
Owner

@rahepler2 commented on GitHub (Oct 14, 2025):

Also seeing this. I have a link to the model as URL.com?models=model_id. For admin this works, for users it simply brings up the model dropdown with search modal and won't display the model.

We are also having an issue with non-admins unable to call tools from a model.

It seems that there is an issue with access checks for users accross the app in 0.6.33

@rahepler2 commented on GitHub (Oct 14, 2025): Also seeing this. I have a link to the model as URL.com?models=model_id. For admin this works, for users it simply brings up the model dropdown with search modal and won't display the model. We are also having an issue with non-admins unable to call tools from a model. It seems that there is an issue with access checks for users accross the app in 0.6.33
Author
Owner

@JARZcorp commented on GitHub (Oct 14, 2025):

Same issue here as described by @nekomiya-hinata

@JARZcorp commented on GitHub (Oct 14, 2025): Same issue here as described by @nekomiya-hinata
Author
Owner

@nickmachairas commented on GitHub (Oct 16, 2025):

This is a significant issue. Not sure if it is related, but when this issue appeared on v0.6.33, I noticed that workspace models with default tools do not get these tools turned on when standard users select the models. They have to manually turn the models on via the integrations menu.

Also, switching models with tools does not change the tools that should be turned on, the interface keeps the tools of the model selected first.

This has turned into a bigger problem than it may seem because users think they get good responses (i.e. with a RAG tool) when in reality they get wrong answers. Most standard users don't know what tools are and how to turn them on.

@nickmachairas commented on GitHub (Oct 16, 2025): This is a significant issue. Not sure if it is related, but when this issue appeared on v0.6.33, I noticed that workspace models with default tools do not get these tools turned on when standard users select the models. They have to manually turn the models on via the integrations menu. Also, switching models with tools does not change the tools that should be turned on, the interface keeps the tools of the model selected first. This has turned into a bigger problem than it may seem because users think they get good responses (i.e. with a RAG tool) when in reality they get wrong answers. Most standard users don't know what tools are and how to turn them on.
Author
Owner

@tkg61 commented on GitHub (Oct 16, 2025):

I believe this has been solved in 0.6.34 can others test as well?

@tkg61 commented on GitHub (Oct 16, 2025): I believe this has been solved in 0.6.34 can others test as well?
Author
Owner

@nickmachairas commented on GitHub (Oct 17, 2025):

I installed v0.6.34 and the issues I described above persist.

@nickmachairas commented on GitHub (Oct 17, 2025): I installed v0.6.34 and the issues I described above persist.
Author
Owner

@Azzeo commented on GitHub (Oct 18, 2025):

Having the same problem right now with v0.6.34

@Azzeo commented on GitHub (Oct 18, 2025): Having the same problem right now with v0.6.34
Author
Owner

@tjbck commented on GitHub (Oct 20, 2025):

We cannot reproduce this issue, perhaps screen recordings here would be helpful.

As a sidenote, "Direct" connections should NOT be used for global models as per its name.

@tjbck commented on GitHub (Oct 20, 2025): We cannot reproduce this issue, perhaps screen recordings here would be helpful. As a sidenote, "Direct" connections should **NOT** be used for global models as per its name.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#6641