Before inviting more people into Open WebUI, check what an ordinary account can actually see and share. A working login tells you little about access to a colleague’s notes, a team model or a conversation link.
This Open WebUI permissions audit gives you a small, repeatable check using two test users and dummy content. Keep the results with your upgrade notes so the next check starts with a known expectation.
Why check after an upgrade?
The v0.11.2 release of 31 August 2026 includes security and access-control fixes. Separately, the current documentation flags saved Tools and Notes sharing settings that administrators should recheck. An upgrade and an access audit answer different questions: which code is running, and which permissions your installation has retained.
Before changing anything
- Record your installed version and arrange a maintenance window for changes that affect existing users.
- Have a current deployment backup and a known restore procedure. Screenshots of settings are useful, but do not replace a database and data backup.
- Use a staging copy where possible. Keep authentication and your existing network restrictions enabled.
- Prepare two authorised test accounts, Casey and Morgan, with separate browser profiles. Use made-up names, notes and chat text throughout.
Check their roles in Admin Panel → Users. Both need the ordinary User role. A Pending account cannot exercise normal access, while an Admin bypasses many checks. Keep your own administrator account available for recovery. Open WebUI’s role definitions explain those differences.
1. Write down the intended access
For this exercise, Casey belongs to an Audit Team group; Morgan does not. Both may chat. Only Casey should read a sample team resource. Neither should create server-side tools or publish conversations without sign-in.
Keep feature permissions separate from resource access. Being allowed to use a feature does not tell you which particular model or knowledge base a person should receive. Open WebUI’s RBAC overview separates roles, permissions and groups.
Open Admin Panel → Users → Groups → Default Permissions, then inspect Casey’s and Morgan’s groups. Permissions are additive: an enabled default or any group grant can supply a feature. Turning it off in one group does not cancel a grant elsewhere. Keep the default baseline small and grant additional capabilities deliberately.
Record each setting you intend to change, its original value and the reason. Do not disable a team-wide feature merely to demonstrate a test; use staging if the exercise would interrupt real work.
2. Recheck Tools and Notes public sharing
The permissions documentation describes an older mismatch: Tools Public Sharing and Notes Public Sharing could appear enabled while sharing was refused. Saving another permission could then store both as enabled. Corrected behaviour does not undo those saved values.
In Default Permissions, inspect Sharing → Tools Public Sharing and Notes Public Sharing. Repeat for relevant groups. Their parent sharing permissions control whether the public toggles appear; do not turn a parent on just to expose a switch. Check the effective policy and save only intended changes.
The documentation does not identify the exact affected versions in that warning. Do not assume your instance was affected, or that a particular patch automatically restored your preferred settings.
3. Distinguish Public, Open and community uploads
For chat links hosted on your instance, Public means signed-in users of that instance. Open means anyone holding the link can read it without an account. They are separate permissions: Chats Public Sharing and Chats Open Sharing, both dependent on Allow Chat Share. Admins are exempt from these user restrictions. See the configuration reference.
Share to Open WebUI Community is another route: it uploads a conversation snapshot to the community website. Do not use it for this audit. The same word “Public” there has a different audience. The chat-sharing guide explains both destinations.
For a private team, leave Open sharing unavailable to ordinary users unless publishing conversations is an explicit requirement. Review existing links too. A restriction on creating new shares is not evidence that an older link has stopped working.
4. Run a small ordinary-user test
From your administrator account, create a dummy knowledge base named Audit sample containing only “Project colour: teal”. In its create/edit access controls, choose Private and give Audit Team Read access. Keep Morgan outside that group, without a direct grant. The Groups guide documents private resource grants and the Access List used to review them.
This example assumes both test accounts have Knowledge Access for the workspace; the resource grant is what differs. If your policy disables that workspace, run this example in staging instead of adding production rights. The final column is the policy you are checking; enter actual results alongside it.
| Account | Check | Intended result |
|---|---|---|
| Casey | Open Audit sample through its direct resource URL | Can read the sample; cannot edit it |
| Morgan | Open that same resource URL | Cannot read the sample |
| Casey | Look for tool creation/import controls | Unavailable under this audit policy |
| Casey | Inspect a dummy chat’s Share options | Open unavailable; other options match policy |
| Signed out | Open an approved, non-Open dummy chat link | No conversation content before sign-in |
If your policy disables Allow Chat Share, record “Share unavailable” and skip the dummy-link check. Do not enable sharing just to complete the table.
Record actual results beside the table. Test the direct resource URL as well as the visible menu: a missing navigation item alone is not enough. Do not send a real document to a model to prove a permission setting.
Where your installed version offers it, Admin Panel → Users → Preview Access provides a read-only view of a non-admin user’s model, knowledge and tool access. It includes group and direct grants, plus owned resources. Treat this as a useful cross-check, not a replacement for the account tests or an inventory of chat links.
5. Treat tool creation as server access
Review Workspace → Tools Access and Import Tools within the permissions editor. Ordinary chat users rarely need to create executable plugins. Open WebUI warns that Tools and Functions run Python on the server, and that a featured community listing is not a security review. Inspect existing installations through Workspace → Tools and Admin Panel → Functions; do not import anything for this exercise. Plugin security guidance.
Tools and Import controls can be absent when ENABLE_PLUGINS=false. Record “Plugins disabled”; do not enable them for this audit. When plugins are enabled, their code inherits the Open WebUI process’s access. Separate host, network and credential controls still matter; see the hardening guide. If you also use tools in llama.cpp’s built-in Web UI, audit that separate interface too. These Open WebUI switches do not configure it.
Troubleshooting and reverting changes
A user still has access
Confirm the account is not Admin. Then check defaults, every group, direct resource grants and ownership. For the dummy sample, remove the test group’s Read grant from its Access List and repeat Casey’s direct-link check. If access persists, investigate before treating the audit as passed.
An environment change appears ignored
Settings marked ConfigVar can be retained in the database after first launch. Compare the saved admin settings with deployment configuration. Do not delete the data volume to reset permissions. Setting ENABLE_PERSISTENT_CONFIG=False changes persistence behaviour, including whether UI edits survive restarts; it is not a harmless troubleshooting toggle.
A signed-out chat link still works
Check the link’s host and whether its audience is Open. For a dummy share on your own instance, return it to Private or use the chat’s Share → delete this link control, then retest the old URL. Search-engine noindex settings do not make a readable link private.
To revert the exercise, restore only the settings you recorded, remove temporary grants and retest. Do not blindly restore a permission you discovered was excessive. Record that as a separate decision. Recheck saved values after the next planned restart.
Does this also protect the model backend?
No. Provider credentials and backend administration need their own restrictions. Use only the provider access required for inference. If you run a local API, our LocalAI Windows and Docker guide covers that separate setup. Finish this audit with recorded account-level results, then review the other services in your deployment.
Sources checked 6 September 2026: official Open WebUI release notes, roles, permissions, groups, chat sharing, configuration and plugin documentation linked above. Match settings to your installed version; the configuration reference currently identifies v0.11.1 as its documented baseline.