mirror of
https://github.com/langgenius/dify-official-plugins.git
synced 2026-07-21 17:45:23 -04:00
Gemini Plugins cannot upload file #822
Reference in New Issue
Block a user
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?
Originally created by @rty813 on GitHub (Nov 20, 2025).
Self Checks
Dify version
v1.8.1
Plugin version
0.6.3
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
I passed a file into "Vision", but got an error when using it:
Run failed: [google] Error: req_id: 41b1902800 PluginInvokeError: {"args":{"description":"[models] Error: 'Failed to create file. Upload URL did not returned from the create file request.'"},"error_type":"InvokeError","message":"[models] Error: 'Failed to create file. Upload URL did not returned from the create file request.'"}Below is my plugin configuration
✔️ Error log
No response
@dosubot[bot] commented on GitHub (Nov 20, 2025):
The error "Failed to create file. Upload URL did not returned from the create file request" in the Gemini plugin usually means the plugin couldn't get a valid upload URL from the backend, so the file upload couldn't proceed. In self-hosted Docker setups, this is often caused by misconfiguration of the FILES_URL or network accessibility issues.
The Gemini plugin fetches files from the Dify file store using the configured FILES_URL, then uploads them to Google GenAI. If the file isn't accessible at the specified URL, or if the GenAI SDK doesn't return a valid upload URL, you'll see this error. Double-check that your FILES_URL (and INTERNAL_FILES_URL, if set) is reachable from inside your Docker network and uses the correct protocol, host, and port. Also, make sure your API key and endpoint settings are correct and that there are no firewall or reverse proxy issues blocking access to the file server.
Recent code and merged PRs do not indicate a bug in the plugin itself, so the most likely cause is configuration or network-related. If you adjust your FILES_URL and ensure all services can reach it, the upload should work as expected. For more details on how the plugin handles file uploads, see the relevant code logic here.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@rty813 commented on GitHub (Nov 21, 2025):
@dosu How should I fill in FILES_URL? I've already entered the domain name of the Dify website, but it doesn't seem to work.
@dosubot[bot] commented on GitHub (Nov 21, 2025):
For a self-hosted Dify (Docker) setup, FILES_URL should point to the internal API service so plugins can fetch files directly. In most Docker Compose deployments, set
FILES_URLin your.envfile tohttp://api:5001(not just your website domain). Make sure port 5001 is exposed in yourdocker-compose.yamlfile—if it's missing, addports: - "5001:5001"to the API service and restart your containers. This allows the Gemini plugin to access files without redirect or timeout errors. If you deploy outside Docker Compose, usehttp://<your-host-ip>:5001instead. More details and examples are available in the plugin docs and related issues (example, code reference).If you still have trouble, share your current FILES_URL value and Docker setup details.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@rty813 commented on GitHub (Nov 21, 2025):
@dosu I have set FILES_URL to http://api:5001, but the same error still persists
@dosubot[bot] commented on GitHub (Nov 21, 2025):
If you've set
FILES_URLtohttp://api:5001but the Gemini plugin still can't upload files, the most common cause is that port 5001 isn't exposed in yourdocker-compose.yamlfile. Make sure your API service includesports: - "5001:5001"—otherwise, the plugin can't reach the file server, even if the URL is correct. After updating, restart your containers for changes to take effect. This fix has resolved similar issues for other users in self-hosted Docker setups (details).If the error persists, try setting
FILES_URLtohttp://host.docker.internalin your.envfile and restart Docker. This workaround has helped in cases where inter-container networking was problematic (details).Also, check if you have an
INTERNAL_FILES_URLvariable—if so, set it to the internal Docker API URL (http://api:5001). This ensures plugins use the correct address inside the Docker network.If none of these work, review your plugin and API container logs for more detailed error messages. Let me know if you need help checking your Docker config or environment variables.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@IAn2018cs commented on GitHub (Dec 20, 2025):
Is the problem solved? I also encountered this problem.