dify Knowledge base upload fails immediately after Dify 1.10.1 upgrade

Self Checks

[x] I have read the Contributing Guide and Language Policy.
[x] This is only for bug report, if you would like to ask a question, please head to Discussions.
[x] I have searched for existing issues search for existing issues, including closed ones.
[x] I confirm that I am using English to submit this report, otherwise it will be closed.
[x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭：）
[x] Please do not modify this template :) and fill in all the required fields.

Dify version

1.10.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Knowledge base upload fails immediately after Dify 1.10.1 upgrade

✔️ Expected Behavior

Knowledge base upload fails immediately after Dify 1.10.1 upgrade

❌ Actual Behavior

Knowledge base upload fails immediately after Dify 1.10.1 upgrade

Dec 05 '25 03:12 zhangleijun111

This upload failure in Dify 1.10.1 is likely caused by recent changes that introduced stricter validation and removed legacy API endpoints. Here’s what to check:

Make sure your knowledge base configuration includes valid embedding and reranking model settings. Both provider name and model name must be set if reranking is enabled—missing or invalid fields will cause immediate failure with an error message, as enforced by recent updates PR #26380 and PR #27241.
Confirm your document upload quota is not exceeded. The backend now enforces quotas and feature flags more strictly, and any overage or misconfiguration will block uploads feature_service.py.
Double-check Docker environment variables: set FILES_URL (and INTERNAL_FILES_URL if present) to http://api:5001, and ensure port 5001 is exposed in your docker-compose.yaml. If the file server is unreachable, uploads will fail immediately plugin upload troubleshooting.
The backend now blocks uploads for unsupported file types, blacklisted extensions, or files exceeding size limits. Make sure your .txt file meets all requirements file_service.py.
If you have custom workflows or plugins, ensure they do not rely on the deleted /datasets/{dataset_id}/documents/{document_id}/upload-file API endpoint, which was removed in PR #25543.

If these checks don’t resolve the issue, collect backend and frontend error logs during the upload attempt—they will help pinpoint the exact validation or configuration failure.

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

Dec 05 '25 03:12 dosubot[bot]

我试过了都不行

发自我的iPhone

------------------ Original ------------------ From: dosubot[bot] @.> Date: Fri,Dec 5,2025 11:23 AM To: langgenius/dify @.> Cc: zhangleijun111 @.>, Author @.> Subject: Re: [langgenius/dify] Knowledge base upload fails immediately afterDify 1.10.1 upgrade (Issue #29173)

dosubot[bot] left a comment (langgenius/dify#29173)

This upload failure in Dify 1.10.1 is likely caused by recent changes that introduced stricter validation and removed legacy API endpoints. Here’s what to check:

Make sure your knowledge base configuration includes valid embedding and reranking model settings. Both provider name and model name must be set if reranking is enabled—missing or invalid fields will cause immediate failure with an error message, as enforced by recent updates PR #26380 and PR #27241.

Confirm your document upload quota is not exceeded. The backend now enforces quotas and feature flags more strictly, and any overage or misconfiguration will block uploads feature_service.py.

Double-check Docker environment variables: set FILES_URL (and INTERNAL_FILES_URL if present) to http://api:5001, and ensure port 5001 is exposed in your docker-compose.yaml. If the file server is unreachable, uploads will fail immediately plugin upload troubleshooting.

The backend now blocks uploads for unsupported file types, blacklisted extensions, or files exceeding size limits. Make sure your .txt file meets all requirements file_service.py.

If you have custom workflows or plugins, ensure they do not rely on the deleted /datasets/{dataset_id}/documents/{document_id}/upload-file API endpoint, which was removed in PR #25543.

If these checks don’t resolve the issue, collect backend and frontend error logs during the upload attempt—they will help pinpoint the exact validation or configuration failure.

To reply, just mention @dosu.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

Dec 05 '25 03:12 zhangleijun111

你遇到的这个上传失败问题，在 Dify 1.10.1 里已经被多位用户和维护者确认是一个已知 bug，主要原因是前端没有收到后端返回的文件 ID，导致“下一步”按钮一直是灰色，上传直接失败。这通常不是配置问题，而是 1.10.1 版本的前后端集成 bug，和 PR #26199 的变更有关。

临时解决办法有两个：

回退 PR #26199，或者
把 Docker 部署的 dify-api 和 dify-web 镜像切换到 main 分支的最新版，等官方修复。

如果你已经排除了模型配置、配额、文件类型/大小、环境变量等问题，建议你：

查看 API 容器和 file server 容器的日志，确认有没有权限报错（比如 storage 目录权限不足）。
如果日志没有明显报错，基本可以确定就是前后端集成 bug，可以直接用上述临时方案绕过。

如果你需要具体操作步骤或日志分析方法，可以补充说明你的部署方式和日志内容，我可以帮你进一步定位。

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

Dec 05 '25 03:12 dosubot[bot]

没有用，我都升级到 main分支了，50分钟之前的分支，都不行

Dec 05 '25 05:12 songlin1994

你遇到的这个上传失败问题，在 Dify 1.10.1 里已经被多位用户和维护者确认是一个已知 bug，主要原因是前端没有收到后端返回的文件 ID，导致“下一步”按钮一直是灰色，上传直接失败。这通常不是配置问题，而是 1.10.1 版本的前后端集成 bug，和 PR #26199 的变更有关。

临时解决办法有两个：

回退 PR修复方法：将 FileUploader 上下文与 props 同步，以修复“查看缓存变量”中文件参数状态不一致的问题。 #26199，或者

把 Docker 部署的 dify-api 和 dify-web 镜像切换到 main 分支的最新版，等官方修复。

如果你已经排除了模型配置、配额、文件类型/大小、环境变量等问题，建议你：

查看 API 容器和 file server 容器的日志，确认有没有权限报错（比如 storage 目录权限不足）。

如果日志没有明显报错，基本可以确定就是前后端集成 bug，可以直接用上述临时方案绕过。

如果你需要具体操作步骤或日志分析方法，可以补充说明你的部署方式和日志内容，我可以帮你进一步定位。

回复时，只需提及@dosu。

我表现得怎么样？很好 |无关紧要 |错误 |冗长 |幻觉 |报告 🐛 |其他

这是日志

Dec 05 '25 05:12 zhangleijun111

I’m experiencing the same issue. After upgrading to version 1.10.1, uploading local files fails both on the Knowledge Base upload page and during Test Run in the Knowledge Pipeline. @dosu Below is the error log I encountered:

2025-12-05 05:48:59.446 ERROR [Dummy-1301] [app.py:875] - Exception on /console/api/files/upload [POST]
Traceback (most recent call last):
  File "/app/api/.venv/lib/python3.12/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask_restx/api.py", line 404, in wrapper
    resp = resource(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask/views.py", line 110, in view
    return current_app.ensure_sync(self.dispatch_request)(**kwargs)  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask_restx/resource.py", line 41, in dispatch_request
    resp = meth(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/controllers/console/wraps.py", line 220, in decorated
    return view(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/libs/login.py", line 80, in decorated_view
    return current_app.ensure_sync(func)(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/controllers/console/wraps.py", line 37, in decorated
    return view(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask_restx/marshalling.py", line 246, in wrapper
    resp = f(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^
  File "/app/api/controllers/console/wraps.py", line 122, in decorated
    return view(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/controllers/console/files.py", line 76, in post
    upload_file = FileService(db.engine).upload_file(
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/services/file_service.py", line 84, in upload_file
    storage.save(file_key, content)
  File "/app/api/extensions/ext_storage.py", line 89, in save
    self.storage_runner.save(filename, data)
  File "/app/api/extensions/storage/opendal_storage.py", line 44, in save
    self.op.write(path=filename, bs=data)
opendal.exceptions.PermissionDenied: PermissionDenied (persistent) at write => permission denied

Context:
   service: fs
   path: upload_files/2fbda805-0a2b-49a7-95ba-9c1a97386acc/b802d0d1-1cc2-4743-b1ba-0b6a38dd99d3.pdf

Source:
   Permission denied (os error 13)

2025-12-05 05:48:59.448 ERROR [Dummy-1301] [app.py:875] - Exception on /console/api/files/upload [POST]
Traceback (most recent call last):
  File "/app/api/.venv/lib/python3.12/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask_restx/api.py", line 404, in wrapper
    resp = resource(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask/views.py", line 110, in view
    return current_app.ensure_sync(self.dispatch_request)(**kwargs)  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask_restx/resource.py", line 41, in dispatch_request
    resp = meth(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/controllers/console/wraps.py", line 220, in decorated
    return view(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/libs/login.py", line 80, in decorated_view
    return current_app.ensure_sync(func)(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/controllers/console/wraps.py", line 37, in decorated
    return view(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask_restx/marshalling.py", line 246, in wrapper
    resp = f(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^
  File "/app/api/controllers/console/wraps.py", line 122, in decorated
    return view(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/controllers/console/files.py", line 76, in post
    upload_file = FileService(db.engine).upload_file(
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/services/file_service.py", line 84, in upload_file
    storage.save(file_key, content)
  File "/app/api/extensions/ext_storage.py", line 89, in save
    self.storage_runner.save(filename, data)
  File "/app/api/extensions/storage/opendal_storage.py", line 44, in save
    self.op.write(path=filename, bs=data)
opendal.exceptions.PermissionDenied: PermissionDenied (persistent) at write => permission denied

Context:
   service: fs
   path: upload_files/2fbda805-0a2b-49a7-95ba-9c1a97386acc/b802d0d1-1cc2-4743-b1ba-0b6a38dd99d3.pdf

Source:
   Permission denied (os error 13)

Dec 05 '25 07:12 xsxustc

I fix it. @zhangleijun111 @dosu

In Dify 1.10.1, the api and worker containers now run as a non-root user (UID 1001). If the host-mounted storage directory is still owned by root or another user, the OpenDAL fs backend will fail to write files and throw:

Permission denied (os error 13)

You can fix this by updating the ownership and permissions of the storage directory:

# 1. Go to the Dify docker directory
cd /path/to/dify/docker

# 2. Stop the containers
docker compose down

# 3. Check current permissions
ls -ld volumes/app/storage
ls -ld volumes/app/storage/upload_files || true

# 4. Change ownership to UID 1001
sudo chown -R 1001:1001 volumes/app/storage
# Or, if needed:
# sudo chown -R 1001:1001 volumes

# 5. Ensure the owner has read/write/execute permissions
sudo chmod -R u+rwX volumes/app/storage

# 6. Restart
docker compose up -d

After applying these changes, file uploads should work normally. This issue occurs because the new non-root container user must have write access to the mounted storage directory.

Dec 06 '25 06:12 xsxustc

Confirmed—your solution is correct and matches the recent changes in Dify 1.10.1. The containers now run as a non-root user (UID 1001), so the storage directory must be owned and writable by that user for uploads to work. This change was introduced in PR #28756 and PR #26419, which updated the Dockerfiles to use the dify user (UID 1001) by default.

For anyone else running into Permission denied (os error 13) during file uploads, update the ownership and permissions of your storage directory as described above, then restart your containers. This resolves the issue.

It would be helpful for the Dify team to highlight this breaking change in the upgrade and troubleshooting docs to prevent confusion for future upgrades. If you run into any other permission-related problems after this fix, let me know!

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

Dec 06 '25 06:12 dosubot[bot]

I fix it. @zhangleijun111 @dosu

In Dify 1.10.1, the api and worker containers now run as a non-root user (UID 1001). If the host-mounted storage directory is still owned by root or another user, the OpenDAL fs backend will fail to write files and throw:
Permission denied (os error 13)
You can fix this by updating the ownership and permissions of the storage directory:

1. Go to the Dify docker directory

cd /path/to/dify/docker

2. Stop the containers

docker compose down

3. Check current permissions

ls -ld volumes/app/storage ls -ld volumes/app/storage/upload_files || true

4. Change ownership to UID 1001

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

Or, if needed:

sudo chown -R 1001:1001 volumes

5. Ensure the owner has read/write/execute permissions

sudo chmod -R u+rwX volumes/app/storage

6. Restart

docker compose up -d After applying these changes, file uploads should work normally. This issue occurs because the new non-root container user must have write access to the mounted storage directory.

用你的办法可以上传了但是知识库文档分块不可以了

Dec 08 '25 01:12 zhangleijun111

@zhangleijun111 About the new errors you’re seeing:

Error code: 400 ... "未正常接收到prompt参数"
Error: 401 ... "user authenticate failed"
An error occurred in langgenius/mineru/mineru plugin ...

These don’t seem related to the permission issue discussed in this thread. From the messages, it looks more like the Mineru plugin is failing (missing prompt payload, authentication error, etc.).

Since this is a different problem and I’m just a regular user (I haven’t encountered this myself), it might be better to open a new issue so the plugin/Dify maintainers can take a look.

Dec 08 '25 05:12 xsxustc

Due to the security risks associated with high-risk vulnerabilities, I chose to upgrade to the latest FIX version. The version before the upgrade was 1.9.2, and uploading files was normal. Then I also encountered the problem of not being able to upload files.

I am using Docker desktop in the Windows environment. Unable to execute command to modify folder permissions: sudo chown - R 1001:1001 volumes The upload path is in volumes\app\storage\upload_files. Do we need to give everyone write permission? @dosu.

Dec 08 '25 07:12 moncat2005

Due to a security vulnerability detected on December 4, I upgraded Dify to version 1.10.1. After the upgrade, the chatflow is working normally, but in the workflow, all file uploads are failing.

While checking the server logs, I actually found an error—not sure if it's related.

Dec 09 '25 01:12 LiTianSuo777

After confirming the update to 57d244de693f5334db021e6446b3a8ccf2f6cb7b, the issue of unable to upload has been resolved

Dec 10 '25 09:12 moncat2005

same question

Dec 14 '25 16:12 tujw-ht