一、错误原因核心分析

日志中明确显示 opendal.exceptions.PermissionDenied (os error 13)（权限拒绝），结合 dify 1.10.1-fix.1 版本特性，根因是：

1.10.1-fix.1 版本为安全考量，默认以非 root 用户（UID/GID=1001）运行 API 容器，但本地文件存储目录（宿主机 / 容器内的upload_files）的读写权限未同步适配，导致上传文件时无法写入磁盘。

关键佐证：

• • 报错上下文service: fs说明使用本地文件系统存储；
• • 报错路径upload_files/xxx.pdf是文件上传的核心目录；
• • os error 13是 Linux 经典的权限不足错误。

二、分步骤修复建议

步骤 1：停止 Dify 服务（避免修复时文件被占用）

# 进入Dify的docker目录（根据你的实际路径调整）

cd /你的dify安装目录/docker

# 停止所有服务

docker compose down

步骤 2：修复宿主机存储目录权限（核心）

Dify 的文件存储默认映射到宿主机./volumes/app/storage，需给该目录赋权（让容器内 1001 用户可读写）：

# 方式1：直接赋权（最简单，适配非root用户）

sudo chown -R 1001:1001 ./volumes/app/storage

sudo chmod -R 755 ./volumes/app/storage  # 保证读/写/执行权限

# 方式2：若方式1无效（如宿主机无1001用户），可放宽目录权限（测试环境可用）

sudo chmod -R 777 ./volumes/app/storage

步骤 3：验证容器内权限（可选，排查深层问题）

启动 API 容器并检查目录权限：

# 临时启动API容器并进入

docker compose run --rm api bash

# 容器内检查存储目录权限

ls -ld /app/storage/upload\_files

# 预期输出（所有者为1001）：

# drwxr-xr-x 2 1001 1001 4096 Dec  8 14:00 /app/storage/upload\_files

# 测试写入权限（创建空文件）

touch /app/storage/upload\_files/test.txt

# 无报错则权限正常，执行exit退出容器

exit

步骤 4：重启 Dify 服务并验证

docker compose up -d

# 查看API日志，确认无权限错误

docker compose logs -f api

步骤 5：若仍报错，调整容器运行用户（兜底方案）

如果上述步骤无效，可临时将容器改回 root 用户运行（不推荐生产环境，仅应急）：

1. 1. 修改docker-compose.yml中api服务的配置，添加user: root：

services:

 api:

   image: langgenius/dify-api:1.10.1-fix.1

   user: root  # 新增这一行

   volumes:

     - ./volumes/app/storage:/app/storage

     # 其他配置不变

1. 1. 重启服务：

docker compose down && docker compose up -d

三、预防措施（避免后续升级重复踩坑）

1. 1. 升级前提前给存储目录赋权：sudo chown -R 1001:1001 ./volumes/app/storage；
2. 2. 生产环境避免使用777权限，优先适配容器默认的 1001 用户；
3. 3. 若使用自定义存储路径（如.env中配置STORAGE_PATH），需同步给自定义路径赋权。

四、验证修复效果

使用DeepSeek OCR 流程上传一个PDF文件测试一下看看。

文件正常上传了！

往期精彩图文

Dify社区群：Dify嗨聊社

友情提示：由于群成员太多，如果扫描二维码无法入群，请私信留下微信号，管理员单独邀请入群。