issue: Image uploads fail with “File type image/jpeg is not supported for processing” when no extraction engine is configured (videos alread

快速结论：该报错通常出现在 Open WebUI 未配置内容提取引擎（content extraction engine）时上传图片，后端因无法对图片做文本提取而直接判定失败。优先确认 rag.content_extraction_engine 是否为默认空值，以及文件处理分支是否已对图片做放行处理。

适用环境：Open WebUI v0.12.0 及当前 dev（revision 0b49167ae09c854dcb4a83f71b78e8a7487ef1e1）；Docker 部署（ghcr.io/open-webui/open-webui:v0.12.0 与 ghcr.io/open-webui/open-webui:dev）；Docker 宿主为 Ubuntu 26.04；Ollama 0.40.2（复现时并不需要）。

最快修复方案：暂无确认的一步修复方案。Issue 中报告者使用的本地做法是把图片与视频同等对待，即在该分支改为 if content_type.startswith(('video/', 'image/')):，并将日志文案改为 “Media file detected”。该做法由报告者自行以 build-time patch 方式验证有效，但尚未确认被官方合并。

注意事项：上述改动属于源码层修补，需要自行维护补丁并承担版本升级后的合并成本；它改变的是“无法提取文本时图片是否仍标记为 completed”的行为，不涉及对图片内容的实际解析。若官方后续以其他方式处理（例如按提取引擎派生允许的上传类型），该补丁可能与之冲突。

问题场景

在 Open WebUI 中使用默认内容提取配置（未接入任何外部提取引擎）时，通过 /api/v1/files/ 上传 JPEG 图片。上传请求本身可以完成，但后台文件处理阶段失败，文件记录被写成 status: failed，导致依赖图片文件引用的功能（例如视觉模型、内置 edit_image 工具）无法继续使用该文件。视频文件在同样配置下不受影响，因为代码里已对视频做了跳过文本提取的特殊处理。

报错原文

File type image/jpeg is not supported for processing

ERROR | open_webui.routers.files:_process_handler:260 - Error processing file: 9cbb323d-93d7-4894-9e0a-cdb5b31e401e
file.data: {"status":"failed","error":"File type image/jpeg is not supported for processing"}

原因分析

在 routers/files.py 的处理逻辑中，当 content_type 以 image/ 或 video/ 开头、且该媒体类型不被当前内容提取引擎支持时，视频分支会直接将文件标记为 completed 并跳过文本提取，而图片分支会落入 raise Exception(f'File type {content_type} is not supported for processing')。因此根本原因可能是：默认配置下没有可用的提取引擎，图片缺少与视频相同的“原样存储、跳过提取”放行路径。与之相关的 #14768 也指向同一上传/提取路径上图片 MIME 类型被拒绝的问题。

环境排查

确认 Open WebUI 版本：v0.12.0 或 dev（revision 0b49167ae09c854dcb4a83f71b78e8a7487ef1e1）。
确认部署方式为 Docker，镜像为 ghcr.io/open-webui/open-webui:v0.12.0 或 :dev。
确认配置项：rag.content_extraction_engine 为空字符串、rag.content_extraction.supported_media_mime_types 为 null（即默认值）。
确认上传文件的 content_type 确实为 image/jpeg。
查看服务端日志中是否出现 _process_handler 对应的 Error processing file 记录，并核对文件记录的 data 字段。

解决步骤

先按 Issue 的复现路径确认问题存在：以默认配置启动容器（例如 docker run -d -p 127.0.0.1:3091:8080 -v /tmp/owui:/app/backend/data ghcr.io/open-webui/open-webui:v0.12.0）。
创建管理员账号（POST /api/v1/auths/signup）并获取 TOKEN。
上传 JPEG：curl -H "Authorization: Bearer $TOKEN" -F "file=@photo.jpg;type=image/jpeg" http://127.0.0.1:3091/api/v1/files/。
查询处理状态：GET /api/v1/files/<id>/process/status，若返回 {"status":"failed"}，则与 Issue 描述一致。
若需要采用报告者的本地方案，可在源码中把该分支的条件改为 if content_type.startswith(('video/', 'image/')):，并将对应日志文案改为 “Media file detected”，使图片在无法文本提取时被原样存储并标记为 completed。
以 build-time patch 方式应用该改动后重新构建/部署镜像。
如果不想维护补丁，可关注该 Issue 的官方结论及关联的 #14768，等待上游给出正式处理方式。

验证方法

重新上传同一 JPEG 后，再次调用 GET /api/v1/files/<id>/process/status，确认返回 {"status":"completed"}；同时检查文件记录的 data 字段不再是 {"status":"failed","error":"File type image/jpeg is not supported for processing"}，服务端日志中也不再出现对应的 Error processing file。若能进一步在视觉模型或 edit_image 工具中引用该图片文件并正常工作，即可确认图片已按预期保留可用。