一、错误原因核心分析
日志中明确显示 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. 修改 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. 重启服务：
docker compose down && docker compose up -d
三、预防措施（避免后续升级重复踩坑）
-
1. 升级前提前给存储目录赋权： sudo chown -R 1001:1001 ./volumes/app/storage； -
2. 生产环境避免使用 777权限，优先适配容器默认的 1001 用户； -
3. 若使用自定义存储路径（如 .env中配置STORAGE_PATH），需同步给自定义路径赋权。
四、验证修复效果
使用DeepSeek OCR 流程上传一个PDF文件测试一下看看。
文件正常上传了！
往期精彩图文
Dify社区群：Dify嗨聊社
友情提示：由于群成员太多，如果扫描二维码无法入群，请私信留下微信号，管理员单独邀请入群。