[GH-ISSUE #24829] issue: Public workspace model alias fails with "model not found" when base model is private (regression from v0.8.6) #123718

New Issue

GiteaMirror · 2026-05-21T03:11:18-05:00

GiteaMirror commented

2026-05-21 03:11:18 -05:00

Originally created by @mikisseth on GitHub (May 17, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24829

Check Existing Issues

I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.9.5 (broken) v0.8.6 (last known working)

Ollama Version (if applicable)

vllm v0.20.1

Operating System

Linux

Browser (if applicable)

Chrome

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

Before upgrading, we used public workspace models as user-facing aliases
pointing to private (admin-only) base models. Users would see and use the
public alias, while the real underlying model stayed hidden from the model
selector. This pattern worked correctly in v0.8.6.

Actual Behavior

After upgrading to v0.9.5, sending a message with any such alias fails with
a "model not found" error. The error disappears only if the base model is
also made public — which defeats the purpose of the alias pattern, as users
then see both the alias and the raw base model in the selector.

This appears to be a regression in how access control is enforced during
model resolution. Previously the public alias acted as the access boundary.
Now the backend re-checks the requesting user's permissions against the base
model at completion time, causing the failure.

Steps to Reproduce

In Admin Panel > Settings > Models, add a base model (e.g. "chat-llm").
Set its visibility to Private (admin-only).
In Workspace > Models, create a new model using "chat-llm" as the base.
Set this workspace model to Public.
Log in as a non-admin user.
Select the public workspace model in the chat interface.
Send any message.

Expected: The message completes successfully using the underlying base model.
Actual: The request fails with "model not found" (HTTP 400/404).

Logs & Screenshots

With Admin user:

Behaviour for normal user:

Additional Information

Workaround

Making the base model public resolves the error, but exposes it in every
user's model selector alongside the alias — which is undesirable in
organizations that want to hide implementation details from end users.

#14172 — Requirement for task model to be public (same root cause)
#15807 — BYPASS_MODEL_ACCESS_CONTROL still requires models to be explicitly public
#11237 — Workspace model 404 if foundation model not available to admin

Originally created by @mikisseth on GitHub (May 17, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24829 ### 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 have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.9.5 (broken) v0.8.6 (last known working) ### Ollama Version (if applicable) vllm v0.20.1 ### Operating System Linux ### Browser (if applicable) Chrome ### 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 Before upgrading, we used public workspace models as user-facing aliases pointing to private (admin-only) base models. Users would see and use the public alias, while the real underlying model stayed hidden from the model selector. This pattern worked correctly in v0.8.6. ### Actual Behavior After upgrading to v0.9.5, sending a message with any such alias fails with a "model not found" error. The error disappears only if the base model is also made public — which defeats the purpose of the alias pattern, as users then see both the alias and the raw base model in the selector. This appears to be a regression in how access control is enforced during model resolution. Previously the public alias acted as the access boundary. Now the backend re-checks the requesting user's permissions against the base model at completion time, causing the failure. ### Steps to Reproduce 1. In Admin Panel > Settings > Models, add a base model (e.g. "chat-llm"). Set its visibility to Private (admin-only). 2. In Workspace > Models, create a new model using "chat-llm" as the base. Set this workspace model to Public. 3. Log in as a non-admin user. 4. Select the public workspace model in the chat interface. 5. Send any message. Expected: The message completes successfully using the underlying base model. Actual: The request fails with "model not found" (HTTP 400/404). ### Logs & Screenshots With Admin user: <img width="1262" height="253" alt="Image" src="https://github.com/user-attachments/assets/e5d0f0c9-958c-4329-a073-4f1381359a0f" /> <img width="1531" height="1114" alt="Image" src="https://github.com/user-attachments/assets/f93e198d-f0ba-4d80-a8bb-7ba7cfe98c38" /> Behaviour for normal user: <img width="1731" height="330" alt="Image" src="https://github.com/user-attachments/assets/afa9f786-8156-4c01-8263-6515f468de7a" /> ### Additional Information ### Workaround Making the base model public resolves the error, but exposes it in every user's model selector alongside the alias — which is undesirable in organizations that want to hide implementation details from end users. ### Related issues - #14172 — Requirement for task model to be public (same root cause) - #15807 — BYPASS_MODEL_ACCESS_CONTROL still requires models to be explicitly public - #11237 — Workspace model 404 if foundation model not available to admin

GiteaMirror added the bug label 2026-05-21 03:11:18 -05:00

GiteaMirror closed this issue

2026-05-21 03:11:24 -05:00

GiteaMirror commented

2026-05-21 03:11:26 -05:00

@owui-terminator[bot] commented on GitHub (May 17, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

🟣 #23946 issue: 400 Model not found for Workspace Models whose base models are not available to the user
Directly matches the regression: a workspace model is listed, but chat returns 400/404 'model not found' unless users also have access to the underlying base model. The new issue describes the same access-control failure for a public alias over a private base model.
by itsHenry35 · bug
🟣 #24043 issue: Public custom models fail if base model connection is restricted
This reports the same core behavior for public custom models: the model is visible, but completion fails because backend access checks are applied to the hidden base model/connection. It is effectively the same regression described here, just with a provider connection example.
by jotaperez3 · bug
🟣 #24175 issue: Model access issue with private base models (works with older models, fails with newer ones)
Closely related regression report that newer models/custom wrappers require the base model to be public, while older ones worked. It points to the same chained base-model access check breaking wrapper/alias usage.
by Teimetues · bug
🟣 #24647 feat: allow the bypassing of the chained base model check
This feature request is about bypassing the chained base model check introduced in v0.9, which is the exact mechanism causing the public workspace alias to fail against a private base model.
by JIW-roosi
🟣 #11237 issue: Models defined by user from workspace has 404 model not found if foundation model is not available for admin
Older but structurally similar: a workspace-defined model returns 404 when the foundation/base model is unavailable to the admin, indicating the same class of model-resolution/access-control problem.
by Oaklight · bug

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

@owui-terminator[bot] commented on GitHub (May 17, 2026):  🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟣 [#23946](https://github.com/open-webui/open-webui/issues/23946) **issue: 400 Model not found for Workspace Models whose base models are not available to the user** *Directly matches the regression: a workspace model is listed, but chat returns 400/404 'model not found' unless users also have access to the underlying base model. The new issue describes the same access-control failure for a public alias over a private base model.* *by itsHenry35 · `bug`* 2. 🟣 [#24043](https://github.com/open-webui/open-webui/issues/24043) **issue: Public custom models fail if base model connection is restricted** *This reports the same core behavior for public custom models: the model is visible, but completion fails because backend access checks are applied to the hidden base model/connection. It is effectively the same regression described here, just with a provider connection example.* *by jotaperez3 · `bug`* 3. 🟣 [#24175](https://github.com/open-webui/open-webui/issues/24175) **issue: Model access issue with private base models (works with older models, fails with newer ones)** *Closely related regression report that newer models/custom wrappers require the base model to be public, while older ones worked. It points to the same chained base-model access check breaking wrapper/alias usage.* *by Teimetues · `bug`* 4. 🟣 [#24647](https://github.com/open-webui/open-webui/issues/24647) **feat: allow the bypassing of the chained base model check** *This feature request is about bypassing the chained base model check introduced in v0.9, which is the exact mechanism causing the public workspace alias to fail against a private base model.* *by JIW-roosi* 5. 🟣 [#11237](https://github.com/open-webui/open-webui/issues/11237) **issue: Models defined by user from workspace has 404 model not found if foundation model is not available for admin** *Older but structurally similar: a workspace-defined model returns 404 when the foundation/base model is unavailable to the admin, indicating the same class of model-resolution/access-control problem.* *by Oaklight · `bug`* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.

GiteaMirror commented

2026-05-21 03:11:27 -05:00

@mikisseth commented on GitHub (May 17, 2026):

I can see this is a duplicate of #24134

The suggested solution of hiding the base model is sufficient for me. I will close this issue

@mikisseth commented on GitHub (May 17, 2026): I can see this is a duplicate of #24134 The suggested solution of hiding the base model is sufficient for me. I will close this issue

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#123718