用 Docker 拉起 Open WebUI 后，打开页面或上传文件时提示 Permission denied、数据库目录无法写入，这类现象多由容器内进程的用户标识与宿主机挂载目录属主不一致引起。常见触发场景包括：在 NAS 或云服务器上把数据目录挂载进容器、从其他机器拷贝数据目录到新机器、宿主目录原先由 root 创建。修复不是靠单一命令，而是先确认容器以哪个 UID 运行，再在启动参数或挂载参数上对齐。
容器内权限问题的核心矛盾是 UID/GID 映射不一致：容器内用户与宿主机目录属主不是同一数字 ID。通常不建议只靠 chmod 777 或简单 chown 解决，优先用 docker-compose 的 user 字段或运行时的 `--user` 参数固定容器内 UID，再配合挂载目录属主调整。SELinux 开启环境下还需要处理 :Z 或 :z 挂载标签。操作前先确认容器以哪个用户运行。
先确认容器进程的实际 UID
不要根据端口映射或日志直接推断，先执行：
docker exec open-webui id输出形如 uid=0(root) gid=0(root) 时，说明容器内以 root 运行，问题通常出在挂载目录属主不是 root 或文件系统本身不允许该用户写入。输出形如 uid=1000 时，则要根据这个 1000 与宿主机目录属主做比对。这一步决定后续选哪种修正，跳过它直接改参数容易改错方向。
用 user 字段或 `--user` 对齐 UID/GID
docker-compose 部署时，在服务定义里增加 user 字段：
services:
open-webui:
image: ghcr.io/open-webui/open-webui:main
user: "1000:1000"
volumes:
- ./data:/app/backend/data这里的 1000:1000 是宿主机上拥有 ./data 目录的用户的数字 UID 和 GID。若目录由当前登录用户持有，可用 id -u 和 id -g 查得后再手动填入 compose 文件。使用 docker run 时对应写成：
docker run -d \
`--name` open-webui \
`--user` "1000:1000" \
-v "$PWD/data:/app/backend/data" \
-p 3000:8080 \
ghcr.io/open-webui/open-webui:main注意 `--user` "$(id -u):$(id -g)" 在 root 或 sudo 环境会展开成 0:0，等于没改，需要手动替换为具体数字。另外，部分镜像提供 PUID/PGID 环境变量作为切换运行用户的入口，但并非所有镜像都实现了这类初始化逻辑，使用前需要结合镜像自身的用户管理方式确认，不能假设设置了就生效。
挂载参数与 SELinux 标签
卷挂载默认保留宿主机目录的权限元数据，不会自动转换为容器内可写。在 Fedora、RHEL、CentOS 这类默认开启 SELinux 的系统上，即便 UID 已经对齐，缺少 :Z 或 :z 后缀仍会被 SELinux 拦截，现象与权限不足一模一样。compose 中写成：
volumes:
- ./data:/app/backend/data:Z单容器独占目录用 :Z，多个容器共享同一目录用 :z。不确定是否开启 SELinux 时可执行 getenforce，输出 Enforcing 就必须处理标签。
验证与边界
改完参数后按下面顺序确认修复是否完整：
- 执行
docker exec open-webui id，确认容器内 UID/GID 已变为目标数字。 - 在宿主机执行
ls -ln ./data，比较目录属主数字与容器内 UID 是否一致；不要看用户名，容器内用户列表与宿主机不通。 - 在页面里新建对话或上传附件，实际写入一次。
两个容易踩的边界：一是旧数据文件由 root 生成且属主未变时，只改启动参数仍无法读取旧库，需先停容器、一次性调整目录内文件属主再启动；二是在群晖或使用 SMB/NFS 挂载的环境里，宿主机自身的挂载权限会叠在 Docker 层之上，需要先在存储侧确认目录属主，再回来看容器参数。
常见问题
容器内能看到挂载文件，为什么还是写不进去？
看到文件只代表挂载成功，写权限取决于进程 UID 与文件属主、权限位的匹配关系。非 root 进程若与文件属主不一致，且属主没有开放组或其他用户写权限，就会“看得见但写不了”。
调整 user 参数会不会弄丢已有数据？
数据文件保留在宿主机挂载目录，不在容器层，调整启动参数不会清空数据。但旧文件属主若与新的进程 UID 不一致，可能暂时读不到；调整前建议备份数据目录，再做一次属主对齐。