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.15
Ollama Version (if applicable)
No response
Operating System
Windows 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
A private model that is shared with certain user groups (e.g. Group A) should be accessible only to members of that group.
Actual Behavior
Members of an authorised user group (e.g. Group A) can on-share the model to members of non-authorised groups (e.g. a member of Group B).
Steps to Reproduce
Install open-webui using Docker (tested on Windows 11).
As admin, and via the UI Admin panel:
Go to Users tab and create two groups ("Group A" and "Group B")
Create two users ("User A" and "User B")
Add User A to Group A and both users to Group B
Under Groups, go to "Default permissions" and enable "Models Access"
Admin Panel-> Settings->Models-> Edit a model (we will call this "Model X"), set it to private, and share with group A only (read access only).
Save & Update
At this point, User A has access to Model X and User B does not.
Switch to User A account:
Workspace-> Models tab-> Add model (+).
Select Model X from base model, give new name ("Model X2) [Model X2 here is identical to Model X)
Share Model X2 with Group B
Save & Create
Switch to User B account:
Choose Model X2 and start chat
User B has access to the model.
Logs & Screenshots
N/A.
Additional Information
Admins can restrict model access by setting a model to "private" and choosing the group(s) who should have access. However, a non-admin user who has been granted access is then able to to on-share the model (by creating their own custom-model from it as a base) with any group of which they are a member. This can mean that a user who was NOT given access according to the Admin (i.e. not a member of any group given access) can nevertheless access the model. Is this intended behaviour?
Originally created by @adam-morris-xrd on GitHub (Jul 14, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/15696
### 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.15
### Ollama Version (if applicable)
_No response_
### Operating System
Windows 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
A private model that is shared with certain user groups (e.g. Group A) should be accessible only to members of that group.
### Actual Behavior
Members of an authorised user group (e.g. Group A) can on-share the model to members of non-authorised groups (e.g. a member of Group B).
### Steps to Reproduce
1. Install open-webui using Docker (tested on Windows 11).
2. As admin, and via the UI Admin panel:
3. Go to Users tab and create two groups ("Group A" and "Group B")
4. Create two users ("User A" and "User B")
5. Add User A to Group A and **both** users to Group B
6. Under Groups, go to "Default permissions" and enable "Models Access"
7. Admin Panel-> Settings->Models-> Edit a model (we will call this "Model X"), set it to private, and share with group A only (read access only).
8. Save & Update
At this point, User A has access to Model X and User B does not.
Switch to User A account:
9. Workspace-> Models tab-> Add model (+).
10. Select Model X from base model, give new name ("Model X2) [Model X2 here is identical to Model X)
11. Share Model X2 with Group B
12. Save & Create
Switch to User B account:
13. Choose Model X2 and start chat
User B has access to the model.
### Logs & Screenshots
N/A.
### Additional Information
Admins can restrict model access by setting a model to "private" and choosing the group(s) who should have access. However, a non-admin user who has been granted access is then able to to on-share the model (by creating their own custom-model from it as a base) with any group of which they are a member. This can mean that a user who was NOT given access according to the Admin (i.e. not a member of any group given access) can nevertheless access the model. Is this intended behaviour?
GiteaMirror
added the bug label 2026-04-25 07:04:20 -05:00
This is an intended behaviour and the workspace permissions should only be given out extremely judiciously. You can prevent what you described here by carefully scoping the permissions for each group.
<!-- gh-comment-id:3070699140 -->
@tjbck commented on GitHub (Jul 14, 2025):
This is an intended behaviour and the workspace permissions should only be given out extremely judiciously. You can prevent what you described here by carefully scoping the permissions for each group.
Related: https://github.com/open-webui/open-webui/discussions/15519
@adam-morris-xrd commented on GitHub (Jul 14, 2025):
Thank you for your swift reply. Can I please ask for some clarification? I do not see a way for the admin to prevent on-sharing of private base models (e.g. one configured to be accessed only by Group A) without disabling Group A's "Models Access" too. I would like to allow users in Group A to define their own workspace models (system prompts etc) but not to allow them to share the base model beyond the group it is intended for. It seems counterintuitive to me that a base model would show as private to Group A when actually this isn't the ultimate control, and it might be available to all groups via on-sharing. Is there something about the design that I am misunderstanding? It seems that perhaps you consider "Model Access" to only be for a set of "power-users" or quasi-admins? I couldn't see anything that addresses this question in #15519 or that describes this design concept in the docs.
<!-- gh-comment-id:3071368093 -->
@adam-morris-xrd commented on GitHub (Jul 14, 2025):
Thank you for your swift reply. Can I please ask for some clarification? I do not see a way for the admin to prevent on-sharing of private base models (e.g. one configured to be accessed only by Group A) without disabling Group A's "Models Access" too. I would like to allow users in Group A to define their own workspace models (system prompts etc) but not to allow them to share the base model beyond the group it is intended for. It seems counterintuitive to me that a base model would show as private to Group A when actually this isn't the ultimate control, and it might be available to all groups via on-sharing. Is there something about the design that I am misunderstanding? It seems that perhaps you consider "Model Access" to only be for a set of "power-users" or quasi-admins? I couldn't see anything that addresses this question in #15519 or that describes this design concept in the docs.
You give user A access to more sensitive documents than user B.
User B only gets access to normal documents.
User A has access to all documents.
User B can still decide to go ahead and take some of the sensitive documents and share it with user A, even though user A initially didn't have access to it.
As Tim said, this is intended behavior
<!-- gh-comment-id:3071978337 -->
@Classic298 commented on GitHub (Jul 15, 2025):
You have a document management system
You give user A access to more sensitive documents than user B.
User B only gets access to normal documents.
User A has access to all documents.
User B can still decide to go ahead and take some of the sensitive documents and share it with user A, even though user A initially didn't have access to it.
As Tim said, this is intended behavior
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @adam-morris-xrd on GitHub (Jul 14, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/15696
Check Existing Issues
Installation Method
Docker
Open WebUI Version
v0.6.15
Ollama Version (if applicable)
No response
Operating System
Windows 11
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
A private model that is shared with certain user groups (e.g. Group A) should be accessible only to members of that group.
Actual Behavior
Members of an authorised user group (e.g. Group A) can on-share the model to members of non-authorised groups (e.g. a member of Group B).
Steps to Reproduce
At this point, User A has access to Model X and User B does not.
Switch to User A account:
Switch to User B account:
User B has access to the model.
Logs & Screenshots
N/A.
Additional Information
Admins can restrict model access by setting a model to "private" and choosing the group(s) who should have access. However, a non-admin user who has been granted access is then able to to on-share the model (by creating their own custom-model from it as a base) with any group of which they are a member. This can mean that a user who was NOT given access according to the Admin (i.e. not a member of any group given access) can nevertheless access the model. Is this intended behaviour?
@tjbck commented on GitHub (Jul 14, 2025):
This is an intended behaviour and the workspace permissions should only be given out extremely judiciously. You can prevent what you described here by carefully scoping the permissions for each group.
Related: https://github.com/open-webui/open-webui/discussions/15519
@adam-morris-xrd commented on GitHub (Jul 14, 2025):
Thank you for your swift reply. Can I please ask for some clarification? I do not see a way for the admin to prevent on-sharing of private base models (e.g. one configured to be accessed only by Group A) without disabling Group A's "Models Access" too. I would like to allow users in Group A to define their own workspace models (system prompts etc) but not to allow them to share the base model beyond the group it is intended for. It seems counterintuitive to me that a base model would show as private to Group A when actually this isn't the ultimate control, and it might be available to all groups via on-sharing. Is there something about the design that I am misunderstanding? It seems that perhaps you consider "Model Access" to only be for a set of "power-users" or quasi-admins? I couldn't see anything that addresses this question in #15519 or that describes this design concept in the docs.
@Classic298 commented on GitHub (Jul 15, 2025):
You have a document management system
You give user A access to more sensitive documents than user B.
User B only gets access to normal documents.
User A has access to all documents.
User B can still decide to go ahead and take some of the sensitive documents and share it with user A, even though user A initially didn't have access to it.
As Tim said, this is intended behavior