langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-25 05:26:11 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

dify does not get the correct file path from azure-blob storage #14527

New Issue
Closed
opened 2026-02-21 19:17:39 -05:00 by yindo · 3 comments
yindo commented 2026-02-21 19:17:39 -05:00
Owner
Copy Link
Copy Source

Originally created by @nikkoyuthinkcol on GitHub (Jun 9, 2025).

Self Checks

  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
  • Please do not modify this template :) and fill in all the required fields.

Dify version

v1.4.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

  1. change .env to these, leave everything else as default:
# File preview or download Url prefix.
# used to display File preview or download Url to the front-end or as Multi-model inputs;
# Url is signed and has expiration time.
# Setting FILES_URL is required for file processing plugins.
#   - For https://example.com, use FILES_URL=https://example.com
#   - For http://example.com, use FILES_URL=http://example.com
#   Recommendation: use a dedicated domain (e.g., https://upload.example.com).
#   Alternatively, use http://<your-ip>:5001 or http://api:5001,
#   ensuring port 5001 is externally accessible (see docker-compose.yaml).
FILES_URL=https://<account_name>.blob.core.windows.net


# The type of storage to use for storing user files.
STORAGE_TYPE=azure-blob


# Azure Blob Configuration
#
AZURE_BLOB_ACCOUNT_NAME=<account_name>
AZURE_BLOB_ACCOUNT_KEY=<keys>
AZURE_BLOB_CONTAINER_NAME=<container_name>
AZURE_BLOB_ACCOUNT_URL=https://<account_name>.blob.core.windows.net
  1. install pymupdf v0.0.2 in marketplace
  2. create a workflow like the picture below
  3. for the input, create a variable where the type is file upload for document
  4. upload any pdfs
    Image

I noticed this issue, that one is tencant, the error codes and comments are the same.

✔️ Expected Behavior

the files are stored in https://<account_name>.blob.core.windows.net/<container_name>/upload_files/<hex>/<hex>.pdf and dify should be able to read them.

❌ Actual Behavior

Error processing basic-text.pdf: Client error '404 The specified resource does not exist.' for url 'https://<account_name>.blob.core.windows.net/files//file-preview?timestamp=1749525820&nonce=&sign=
For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404

Originally created by @nikkoyuthinkcol on GitHub (Jun 9, 2025). ### Self Checks - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version v1.4.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce 1. change `.env` to these, leave everything else as default: ``` # File preview or download Url prefix. # used to display File preview or download Url to the front-end or as Multi-model inputs; # Url is signed and has expiration time. # Setting FILES_URL is required for file processing plugins. # - For https://example.com, use FILES_URL=https://example.com # - For http://example.com, use FILES_URL=http://example.com # Recommendation: use a dedicated domain (e.g., https://upload.example.com). # Alternatively, use http://<your-ip>:5001 or http://api:5001, # ensuring port 5001 is externally accessible (see docker-compose.yaml). FILES_URL=https://<account_name>.blob.core.windows.net # The type of storage to use for storing user files. STORAGE_TYPE=azure-blob # Azure Blob Configuration # AZURE_BLOB_ACCOUNT_NAME=<account_name> AZURE_BLOB_ACCOUNT_KEY=<keys> AZURE_BLOB_CONTAINER_NAME=<container_name> AZURE_BLOB_ACCOUNT_URL=https://<account_name>.blob.core.windows.net ``` 2. install pymupdf v0.0.2 in marketplace 3. create a workflow like the picture below 4. for the input, create a variable where the type is file upload for **document** 5. upload any pdfs ![Image](https://github.com/user-attachments/assets/8cd2aef7-7440-4781-a866-abd448bea373) I noticed this [issue](https://github.com/langgenius/dify/issues/17934), that one is tencant, the error codes and comments are the same. ### ✔️ Expected Behavior the files are stored in `https://<account_name>.blob.core.windows.net/<container_name>/upload_files/<hex>/<hex>.pdf` and dify should be able to read them. ### ❌ Actual Behavior Error processing basic-text.pdf: Client error '404 The specified resource does not exist.' for url 'https://<account_name>.blob.core.windows.net/files/<hex>/file-preview?timestamp=1749525820&nonce=<hex>&sign=<hex> For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404
yindo added the 🐞 bug label 2026-02-21 19:17:39 -05:00
yindo closed this issue 2026-02-21 19:17:39 -05:00
yindo commented 2026-02-21 19:17:39 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jun 9, 2025):

Based on the code, Dify constructs file paths for Azure Blob Storage in the application logic, typically using a format like upload_files/<tenant_id>/<uuid>.<extension>, and then passes these directly to Azure without modifying them in the storage adapter. The URLs for file access are generated using your FILES_URL as a prefix, but the actual files are stored under the container you specify, using the constructed path as the blob name (source).

Your error shows a 404 for a path like /files/<hex>/file-preview, which doesn't match the expected storage path (upload_files/...). This suggests a mismatch between the URL used for preview/download and the actual blob path in Azure. This can happen if the file preview endpoint is generating URLs that don't match the storage key, or if the FILES_URL is set in a way that doesn't reflect the actual container and path structure.

Double-check that:

  • FILES_URL should point to a domain or endpoint that can serve files via Dify's API, not directly to the Azure Blob Storage root unless you have public access and the path structure matches exactly.
  • The container name and path structure in Azure match what Dify expects (upload_files/...).
  • There are no typos or mismatches in your .env values, especially for AZURE_BLOB_CONTAINER_NAME and FILES_URL.

If you want Dify to serve files through its own API (with signed URLs and access control), FILES_URL should point to your Dify instance (e.g., http://<your-ip>:5001), not directly to Azure Blob Storage. If you point directly to Azure, make sure the blob paths and permissions align with what Dify generates.

There are no known open issues or documentation covering this exact Azure Blob Storage path problem in Dify. If the above checks don't resolve it, the issue may be with how the file preview/download URLs are generated versus how files are stored in Azure.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (Jun 9, 2025): <!-- Answer --> Based on the code, Dify constructs file paths for Azure Blob Storage in the application logic, typically using a format like `upload_files/<tenant_id>/<uuid>.<extension>`, and then passes these directly to Azure without modifying them in the storage adapter. The URLs for file access are generated using your `FILES_URL` as a prefix, but the actual files are stored under the container you specify, using the constructed path as the blob name ([source](https://github.com/langgenius/dify/blob/a97ff587d2b6fc7b1130ecef525e14a303c66921/api/services/file_service.py)). Your error shows a 404 for a path like `/files/<hex>/file-preview`, which doesn't match the expected storage path (`upload_files/...`). This suggests a mismatch between the URL used for preview/download and the actual blob path in Azure. This can happen if the file preview endpoint is generating URLs that don't match the storage key, or if the `FILES_URL` is set in a way that doesn't reflect the actual container and path structure. Double-check that: - `FILES_URL` should point to a domain or endpoint that can serve files via Dify's API, not directly to the Azure Blob Storage root unless you have public access and the path structure matches exactly. - The container name and path structure in Azure match what Dify expects (`upload_files/...`). - There are no typos or mismatches in your `.env` values, especially for `AZURE_BLOB_CONTAINER_NAME` and `FILES_URL`. If you want Dify to serve files through its own API (with signed URLs and access control), `FILES_URL` should point to your Dify instance (e.g., `http://<your-ip>:5001`), not directly to Azure Blob Storage. If you point directly to Azure, make sure the blob paths and permissions align with what Dify generates. There are no known open issues or documentation covering this exact Azure Blob Storage path problem in Dify. If the above checks don't resolve it, the issue may be with how the file preview/download URLs are generated versus how files are stored in Azure. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/1cc531f3-bcb0-4a05-beb4-9c65c8c28c9d?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/1cc531f3-bcb0-4a05-beb4-9c65c8c28c9d?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/1cc531f3-bcb0-4a05-beb4-9c65c8c28c9d?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/1cc531f3-bcb0-4a05-beb4-9c65c8c28c9d?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/1cc531f3-bcb0-4a05-beb4-9c65c8c28c9d?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/1cc531f3-bcb0-4a05-beb4-9c65c8c28c9d?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/1cc531f3-bcb0-4a05-beb4-9c65c8c28c9d?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/20854)
yindo commented 2026-02-21 19:17:39 -05:00
Author
Owner
Copy Link
Copy Source

@kenwoodjw commented on GitHub (Jun 28, 2025):

Hi @nikkoyuthinkcol , Please set

FILES_URL=http://127.0.0.1:5001

because Dify api proxy access Blob

@kenwoodjw commented on GitHub (Jun 28, 2025): Hi @nikkoyuthinkcol , Please set ``` FILES_URL=http://127.0.0.1:5001 ``` because Dify api proxy access Blob
yindo commented 2026-02-21 19:17:39 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Aug 27, 2025):

Hi, @nikkoyuthinkcol. I'm Dosu, and I'm helping the Dify team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported that Dify v1.4.1 self-hosted via Docker had issues with file preview URLs returning 404 errors when using Azure Blob Storage.
  • The problem was due to FILES_URL being set directly to Azure Blob Storage, causing mismatched paths.
  • Maintainers recommended setting FILES_URL to the Dify API endpoint (e.g., http://127.0.0.1:5001) so Dify can proxy file access properly.
  • This configuration change resolved the issue with file preview URLs.

Next Steps:

  • Please confirm if this solution still works with the latest version of Dify or if you encounter any related issues.
  • If the issue remains relevant, feel free to comment to keep the discussion open; otherwise, I will close this issue automatically in 15 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Aug 27, 2025): Hi, @nikkoyuthinkcol. I'm [Dosu](https://dosu.dev), and I'm helping the Dify team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported that Dify v1.4.1 self-hosted via Docker had issues with file preview URLs returning 404 errors when using Azure Blob Storage. - The problem was due to FILES_URL being set directly to Azure Blob Storage, causing mismatched paths. - Maintainers recommended setting FILES_URL to the Dify API endpoint (e.g., http://127.0.0.1:5001) so Dify can proxy file access properly. - This configuration change resolved the issue with file preview URLs. **Next Steps:** - Please confirm if this solution still works with the latest version of Dify or if you encounter any related issues. - If the issue remains relevant, feel free to comment to keep the discussion open; otherwise, I will close this issue automatically in 15 days. Thank you for your understanding and contribution!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#14527
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?