mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-07 19:38:46 -05:00
[GH-ISSUE #21582] issue: File attachments show “No content” in UI and are not accessible to the model (0.8.3 / main/ dev) #58191
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 @MacJedi42 on GitHub (Feb 19, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21582
Check Existing Issues
Installation Method
Docker
Open WebUI Version
v0.8.3 main and dev braches
Ollama Version (if applicable)
No response
Operating System
Ubuntu 22
Browser (if applicable)
Chrome 145 , Firefox 147
Confirmation
README.md.Expected Behavior
The UI should display the file contents when opening the attachment.
The model should be able to access and use the attachment contents in its response.
Actual Behavior
The model responds that it can’t see the file / can’t access the attachment contents.
Clicking the attachment in the UI shows “No content” even though the file size is displayed (e.g. 1.8 KB).
Steps to Reproduce
Open a chat.
Attach a .txt file to the chat message and send it.
Ask the model to summarise or quote the file contents.
In the UI, click the attached file to view it.
Logs & Screenshots
2026-02-19 03:53:36.771 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 114.23.abc.xyz::0 - "GET /api/version HTTP/1.1" 200
2026-02-19 03:54:03.964 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 114.23.abc.xyz::0 - "GET /_app/version.json HTTP/1.1" 304
2026-02-19 03:54:52.143 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 114.23.abc.xyz::0 - "GET /api/version HTTP/1.1" 200
2026-02-19 03:56:48.275 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 114.23.abc.xyz:0 - "GET /_app/version.json HTTP/1.1" 200
2026-02-19 03:56:49.133 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 114.23.abc.xyz:0 - "GET /api/version HTTP/1.1" 200
2026-02-19 03:56:54.451 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 114.23.abc.xyz:0 - "GET /api/v1/users/5c102a5a-ba52-4620-8c6a-e196c550d7d2/profile/image HTTP/1.1" 200
2026-02-19 03:56:54.496 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 114.23.abc.xyz:0 - "GET /api/v1/tools/ HTTP/1.1" 200
2026-02-19 03:56:54.610 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 114.23.abc.xyz:0 - "GET /api/v1/chats/folder/f35d7657-c458-45b6-91db-c6d9133bf3f9/list?page=1 HTTP/1.1" 200
2026-02-19 03:56:54.610 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 114.23.abc.xyz:0 - "GET /api/v1/chats/folder/2b13d2e1-7f42-4452-b4ce-41d71996220c/list?page=1 HTTP/1.1" 200
2026-02-19 03:57:19.070 | INFO | open_webui.routers.files:upload_file_handler:230 - file.content_type: text/plain True
2026-02-19 03:57:19.083 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 114.23.abc.xyz:0 - "POST /api/v1/files/?process=true HTTP/1.1" 200
2026-02-19 03:57:19.136 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 114.23.abc.xyz:0 - "GET /api/v1/files/ee656815-82e5-4ab4-bdbd-171d3084baef/process/status?stream=true
Additional Information
Attached files (e.g. .txt) appear to upload (size is shown), but the UI displays “No content” when opened, and the model reports it can’t see/read the attachment contents.
This is happening on 0.8.3 and also on the dev branch (as of writing).
I previously commented in a knowledge collections issue ([#21299
(https://github.com/open-webui/open-webui/issues/21299) ). I’m now thinking that issue may be a symptom of the same underlying problem if knowledge ingestion uses the same attachment/file pipeline.
This seems to happen in both embedding and bypass RAG modes.
@Classic298 commented on GitHub (Feb 19, 2026):
cannot reproduce, usually only happens when file processing failed or file is still processing
cc @silentoplayz can you reproduce?
@Classic298 commented on GitHub (Feb 19, 2026):
Just tested again on latest dev - also does not appear there either. Just works.
Document extraction or RAG pipeline issue on your end most likely. Check your logs
@MacJedi42 commented on GitHub (Feb 19, 2026):
hey @Classic298 Thank you for your feedback, I have indeed found out the issue and it was the RAG pipeline that was the issue, it was unrelated. Thank you for trying to replicate this, I appreciate your time.