issue: a collaborator renaming a shared knowledge base turns off its Public sharing

问题场景

在 Open WebUI 的 Workspace 中，管理员创建了一个知识库（例如 “Team Docs”），在 Access 面板中将其设为 Public，并把用户 B 添加为 Write 权限的协作者。随后用户 B 在普通用户身份下打开该知识库，仅修改名称或描述并保存，页面提示 “Knowledge updated successfully”。但管理员重新加载后发现，知识库的 Access 面板变成了 Private，所有原本通过 Public 共享获得读取权限的用户和组都失去了访问权，而协作者 B 仍然保留 Write 权限。

报错原文

Knowledge updated successfully
Access panel shows the knowledge base as Private

原因分析

可能原因是知识库名称或描述变更时，前端保存逻辑会把知识库的整份分享列表一并提交。相关代码位于 src/lib/components/workspace/Knowledge/KnowledgeBase.svelte 第 635 行附近（commit fb5431a09）。服务端收到请求后，会移除保存者无权创建的分享项（例如 Public），然后用剩余列表替换已存储的分享列表。由于协作者 B 是普通用户，且系统默认关闭用户级 Knowledge public sharing，服务端便剥掉了 Public 项，最终把知识库降级为 Private。同类问题也出现在共享 model 和共享 note 上（见 #30087、#30174），属于同一类协作保存权限 bug。

环境排查

• 确认 Open WebUI 版本是否为 dev（fb5431a09）或包含该提交的版本；可对照 #32450（08f602342）判断是否已修复。
• 确认安装方式：Issue 中为 Git Clone，其他安装方式（Docker、pip）是否同样受影响未在 Issue 中验证。
• 确认操作系统为 Linux、浏览器为 Firefox；其他平台和浏览器未在 Issue 中验证。
• 确认 Ollama 版本为 v0.40.4；该版本与本 bug 无直接关系，仅作环境记录。
• 确认 Admin Panel > Users > Groups 中用户 B 所属组的 Workspace > Knowledge 权限，以及系统级 Knowledge public sharing 是否处于默认关闭状态。

解决步骤

1. 优先尝试升级到包含修复提交 08f602342（PR #32450）的 dev 或后续版本，该提交专门修复了此问题。
2. 如果暂时无法升级，作为临时规避，不要在协作者拥有 Write 权限且知识库为 Public 的情况下让协作者修改名称或描述；或先由管理员临时移除协作者的 Write 权限，再让管理员统一修改名称/描述。
3. 如果协作者已经完成编辑，管理员需要重新打开该知识库的 Access 面板，手动把 Public 共享重新打开，并为原本受影响的用户组恢复读取权限。
4. 记录受影响的用户和组，避免 Public 关闭期间出现访问中断；可考虑在编辑窗口期暂时用显式用户/组授权替代 Public 共享。

验证方法

按 Issue 的复现步骤重新验证：以管理员身份创建 Public 知识库并给用户 B 添加 Write 权限；以用户 B 身份修改名称或描述并保存；等待 “Knowledge updated successfully” 后，由管理员重新加载页面并打开 Access 面板。若修复生效，面板应仍显示 Public，且原有的用户和组权限保持不变。同时可确认当前版本是否已包含 #32450（08f602342）的改动。

参考来源

open-webui/open-webui #32449

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。