github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-11 10:34:13 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #20263] issue: GGUF Model Upload via URL fails with TypeError in calculate_sha256 (expected str, not BufferedReader) #34668

New Issue
Closed
opened 2026-04-25 08:45:39 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-04-25 08:45:39 -05:00
Owner
Copy Link

Originally created by @a328929 on GitHub (Dec 30, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20263

Check Existing Issues

  • I have searched for any existing and/or related issues.
  • I have searched for any existing and/or related discussions.
  • I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

0.6.43

Ollama Version (if applicable)

No response

Operating System

Ubuntu 24.04

Browser (if applicable)

Chrome 100.0

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

When entering a valid direct download URL (e.g., a Hugging Face 'resolve' link) in the 'Upload GGUF Model' URL field, the system should successfully download and verify the model file. The backend should correctly handle the file stream during the SHA256 calculation instead of crashing with a 500 Internal Server Error (specifically a TypeError where calculate_sha256 receives a BufferedReader object instead of a file path).

Actual Behavior

When attempting to download a GGUF model using a valid direct URL (including Hugging Face 'resolve' links), the operation fails and results in a 500 Internal Server Error.
​The backend logs indicate a TypeError occurs during the download process. Specifically, in open_webui/routers/ollama.py, the download_file_stream function incorrectly passes a BufferedReader object to the calculate_sha256 function in open_webui/utils/misc.py. The calculate_sha256 function expects a file path (str, bytes, or os.PathLike), causing the application to crash.

Steps to Reproduce

Navigate to Admin Settings:
Click on the User Profile icon and select Admin Settings.
Open Connections:
Click on the Connections tab in the sidebar.
Access Ollama Settings:
Find the Ollama connection entry and click the Manage/Configure icon (usually a gear or edit icon) next to it.
Enable Experimental Features:
Look for and click on "Show Experimental Functions" (or "Experimental") to reveal hidden options.
Once enabled, two upload methods will appear: "Upload File" and "Enter URL".
Select URL Upload:
Choose the "Enter URL" (Upload via URL) option.
(Note: The "Upload File" method works correctly; the issue is specific to URL uploads.)
Enter URL & Download:
Paste a valid direct download link for a GGUF model (e.g., a Hugging Face resolve link).
Click the download button.
Observe the Failure:
Wait for the download progress bar to reach 100%.
Immediately after reaching 100%, the process fails with a 500 Internal Server Error.
The backend logs show a TypeError in calculate_sha256 at this point.

Logs & Screenshots

Logs & Screenshots
Include relevant logs, errors, or screenshots to help diagnose the issue.
Note: The log indicates that download_file_stream in ollama.py passes a file object (BufferedReader) to calculate_sha256, but calculate_sha256 in misc.py attempts to use open() on it, expecting a file path string.

Additional Information

Based on the server logs, the root cause is a type mismatch in the file verification logic during the URL download process.
​The Error Location:
The crash happens in open_webui/routers/ollama.py at line 1658, inside the download_file_stream function.
​The Code Defect:
The code calls hashed = calculate_sha256(file, chunk_size).
It passes the file variable, which appears to be a BufferedReader object (the active download stream).
​The Conflict:
The target function calculate_sha256 (in open_webui/utils/misc.py at line 340) expects a file path string, not a file object. It immediately tries to execute with open(file_path, "rb") as f:, which fails because it cannot "open" an already open BufferedReader object.
​Contrast with Working Method:
The "Upload File" (local upload) feature works correctly, likely because it saves the file to a temporary path first or handles the verification differently. The "Enter URL" method seems to lack this intermediate step or incorrectly reuses the SHA256 function without adapting for stream objects.
​Suggested Fix:
The download_file_stream function should either:
​Save the downloaded stream to a temporary file path first, and then pass that path string to calculate_sha256.
​Or, calculate_sha256 should be updated to check if the input is already a file-like object and read it directly without trying to open() it again.

Originally created by @a328929 on GitHub (Dec 30, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/20263 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version 0.6.43 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 24.04 ### Browser (if applicable) Chrome 100.0 ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior When entering a valid direct download URL (e.g., a Hugging Face 'resolve' link) in the 'Upload GGUF Model' URL field, the system should successfully download and verify the model file. The backend should correctly handle the file stream during the SHA256 calculation instead of crashing with a 500 Internal Server Error (specifically a TypeError where calculate_sha256 receives a BufferedReader object instead of a file path). ### Actual Behavior When attempting to download a GGUF model using a valid direct URL (including Hugging Face 'resolve' links), the operation fails and results in a 500 Internal Server Error. ​The backend logs indicate a TypeError occurs during the download process. Specifically, in open_webui/routers/ollama.py, the download_file_stream function incorrectly passes a BufferedReader object to the calculate_sha256 function in open_webui/utils/misc.py. The calculate_sha256 function expects a file path (str, bytes, or os.PathLike), causing the application to crash. ### Steps to Reproduce Navigate to Admin Settings: Click on the User Profile icon and select Admin Settings. Open Connections: Click on the Connections tab in the sidebar. Access Ollama Settings: Find the Ollama connection entry and click the Manage/Configure icon (usually a gear or edit icon) next to it. Enable Experimental Features: Look for and click on "Show Experimental Functions" (or "Experimental") to reveal hidden options. Once enabled, two upload methods will appear: "Upload File" and "Enter URL". Select URL Upload: Choose the "Enter URL" (Upload via URL) option. (Note: The "Upload File" method works correctly; the issue is specific to URL uploads.) Enter URL & Download: Paste a valid direct download link for a GGUF model (e.g., a Hugging Face resolve link). Click the download button. Observe the Failure: Wait for the download progress bar to reach 100%. Immediately after reaching 100%, the process fails with a 500 Internal Server Error. The backend logs show a TypeError in calculate_sha256 at this point. ### Logs & Screenshots Logs & Screenshots Include relevant logs, errors, or screenshots to help diagnose the issue. Note: The log indicates that download_file_stream in ollama.py passes a file object (BufferedReader) to calculate_sha256, but calculate_sha256 in misc.py attempts to use open() on it, expecting a file path string. ### Additional Information Based on the server logs, the root cause is a type mismatch in the file verification logic during the URL download process. ​The Error Location: The crash happens in open_webui/routers/ollama.py at line 1658, inside the download_file_stream function. ​The Code Defect: The code calls hashed = calculate_sha256(file, chunk_size). It passes the file variable, which appears to be a BufferedReader object (the active download stream). ​The Conflict: The target function calculate_sha256 (in open_webui/utils/misc.py at line 340) expects a file path string, not a file object. It immediately tries to execute with open(file_path, "rb") as f:, which fails because it cannot "open" an already open BufferedReader object. ​Contrast with Working Method: The "Upload File" (local upload) feature works correctly, likely because it saves the file to a temporary path first or handles the verification differently. The "Enter URL" method seems to lack this intermediate step or incorrectly reuses the SHA256 function without adapting for stream objects. ​Suggested Fix: The download_file_stream function should either: ​Save the downloaded stream to a temporary file path first, and then pass that path string to calculate_sha256. ​Or, calculate_sha256 should be updated to check if the input is already a file-like object and read it directly without trying to open() it again.
GiteaMirror added the bug label 2026-04-25 08:45:39 -05:00
GiteaMirror commented 2026-04-25 08:45:41 -05:00
Author
Owner
Copy Link

@owui-terminator[bot] commented on GitHub (Dec 30, 2025):

🔍 Similar Issues Found

I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:

  1. #16153 issue: GGUF model import fails
    by thanos-k • Jul 30, 2025 • bug

  2. #19519 issue: Base64 encoded images included in API responses
    by luke-wren • Nov 26, 2025 • bug

  3. #19264 issue: Uploaded file hash remains in database even when OCR fails, causing false duplicate detection
    by flefevre • Nov 18, 2025 • bug

  4. #19701 issue: knowledge can not multiple upload file
    by willy808 • Dec 03, 2025 • bug

  5. #11602 issue: GGUF load by url is broken
    by morgan55555 • Mar 12, 2025 • bug

Show 5 more related issues

  1. #13173 issue: Unable to create GGUF based model via interface
    by ErroneousBosch • Apr 23, 2025 • bug

  2. #17446 issue: file upload bug from 0.6.23
    by K7cl • Sep 14, 2025 • bug

  3. #1124 Impossible to upload your GGUF model
    by zaperda • Mar 10, 2024

  4. #16758 issue: Upload to S3-compatible Storage fails with XAmzContentSHA256Mismatch
    by KIT-philip-hoyer • Aug 20, 2025 • bug

  5. #12272 issue:
    by Mozartuss • Apr 01, 2025 • bug

💡 Tips:

  • If this is a duplicate, please consider closing this issue and adding any additional details to the existing one
  • If you found a solution in any of these issues, please share it here to help others

This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.

<!-- gh-comment-id:3699628858 --> @owui-terminator[bot] commented on GitHub (Dec 30, 2025): 🔍 **Similar Issues Found** I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions: 1. [#16153](https://github.com/open-webui/open-webui/issues/16153) **issue: GGUF model import fails** *by thanos-k • Jul 30, 2025 • `bug`* 2. [#19519](https://github.com/open-webui/open-webui/issues/19519) **issue: Base64 encoded images included in API responses** *by luke-wren • Nov 26, 2025 • `bug`* 3. [#19264](https://github.com/open-webui/open-webui/issues/19264) **issue: Uploaded file hash remains in database even when OCR fails, causing false duplicate detection** *by flefevre • Nov 18, 2025 • `bug`* 4. [#19701](https://github.com/open-webui/open-webui/issues/19701) **issue: knowledge can not multiple upload file** *by willy808 • Dec 03, 2025 • `bug`* 5. [#11602](https://github.com/open-webui/open-webui/issues/11602) **issue: GGUF load by url is broken** *by morgan55555 • Mar 12, 2025 • `bug`* <details> <summary>Show 5 more related issues</summary> 6. [#13173](https://github.com/open-webui/open-webui/issues/13173) **issue: Unable to create GGUF based model via interface** *by ErroneousBosch • Apr 23, 2025 • `bug`* 7. [#17446](https://github.com/open-webui/open-webui/issues/17446) **issue: file upload bug from 0.6.23** *by K7cl • Sep 14, 2025 • `bug`* 8. [#1124](https://github.com/open-webui/open-webui/issues/1124) **Impossible to upload your GGUF model** *by zaperda • Mar 10, 2024* 9. [#16758](https://github.com/open-webui/open-webui/issues/16758) **issue: Upload to S3-compatible Storage fails with XAmzContentSHA256Mismatch** *by KIT-philip-hoyer • Aug 20, 2025 • `bug`* 10. [#12272](https://github.com/open-webui/open-webui/issues/12272) **issue:** *by Mozartuss • Apr 01, 2025 • `bug`* </details> --- 💡 **Tips:** - If this is a duplicate, please consider closing this issue and adding any additional details to the existing one - If you found a solution in any of these issues, please share it here to help others *This comment was generated automatically by a bot.* Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
GiteaMirror commented 2026-04-25 08:45:42 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Dec 30, 2025):

https://github.com/open-webui/open-webui/pull/20281

<!-- gh-comment-id:3700323362 --> @Classic298 commented on GitHub (Dec 30, 2025): https://github.com/open-webui/open-webui/pull/20281
GiteaMirror commented 2026-04-25 08:45:43 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Dec 31, 2025):

6351077958

<!-- gh-comment-id:3701623757 --> @tjbck commented on GitHub (Dec 31, 2025): 635107795800441347c42ad65365047ff78589f1
GiteaMirror commented 2026-04-25 08:45:44 -05:00
Author
Owner
Copy Link

@de1eted-user commented on GitHub (Apr 8, 2026):

For anyone else seeing GGUF URL downloads stuck at 100%, you can work around it by putting ollama run hf.co/{username}/{repository}:{quantization} in the "Pull a model from Ollama.com" field under Settings -> Admin -> Models -> Manage. See https://docs.openwebui.com/features/workspace/models/#model-management

<!-- gh-comment-id:4208525916 --> @de1eted-user commented on GitHub (Apr 8, 2026): For anyone else seeing GGUF URL downloads stuck at 100%, you can work around it by putting `ollama run hf.co/{username}/{repository}:{quantization}` in the "Pull a model from Ollama.com" field under Settings -> Admin -> Models -> Manage. See https://docs.openwebui.com/features/workspace/models/#model-management
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#34668
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?