Error: unsupported file type [80 75 3 4] from ollama create means the file in your Modelfile's FROM line is not a GGUF model, whatever its name says. The four numbers are the file's first four bytes in decimal; a real GGUF file starts with [71 71 85 70], the letters GGUF.

Point FROM at a real GGUF file, or build from a model Ollama already has (FROM qwen2.5:0.5b). On Hugging Face, download through the link with /resolve/ in its path, not the /blob/ page.

The error

PS> Get-Content .\Modelfile
FROM ./clinic-helper.gguf
PS> ollama create clinic-helper -f Modelfile
gathering model components
parsing GGUF
Error: unsupported file type [80 75 3 4]

Why it happens

Ollama decides what a file is by its content, not its extension. A GGUF file opens with the magic bytes GGUF; when the first four bytes are anything else, ollama create stops at "parsing GGUF" and prints the bytes it found. Read as characters, they usually name the culprit. In the test, four files all called clinic-helper.gguf gave:

  • [80 75 3 4]: PK and two control bytes, a zip archive.
  • [60 33 68 79]: <!DO, the start of an HTML page.
  • [67 108 105 110]: Clin, a plain text file.
  • A real GGUF cut off after 1,000,000 bytes passed the magic check and failed a step later with Error: error reading GGUF item 25: unexpected EOF.

The HTML case is the easiest one to meet by accident. A Hugging Face model page's /blob/ link is a web page: a HEAD request in the test answered Content-Type: text/html for it, and a 302 Found redirect to the file for the same path with /resolve/. Save the first one and you have a web page with a .gguf name.

The fix

PS> Format-Hex .\clinic-helper.gguf | Select-Object -First 1
00000000   43 6C 69 6E 69 63 20 68 65 6C 70 65 72 20 6E 6F  Clinic helper no
PS> Format-Hex .\qwen2.5-0.5b.gguf | Select-Object -First 1
00000000   47 47 55 46 03 00 00 00 22 01 00 00 00 00 00 00  GGUF....".......
PS> Get-Content .\Modelfile
FROM ./qwen2.5-0.5b.gguf
SYSTEM You answer in one short sentence.
PARAMETER temperature 0.2
PS> ollama create clinic-helper -f Modelfile
...
using existing layer sha256:c5396e06af294bd101b30dce59131a76d2b773e76950acc870eda801d3ab0515
creating new layer sha256:479ca8586a2a3b4d5bf32ec45f3f94a8d0b3e4b773b312eb08b5ecd55da00a44
creating new layer sha256:81c1dabb49a2d396200b91ae4ab60b882ac576dba062629e360980062253fd22
writing manifest
success
PS> ollama run clinic-helper "Reply with the single word ready."
ready

Check the first bytes before you blame Ollama: Format-Hex, or any hex viewer, should show GGUF at offset 0. The second way needs no file at all: build from a model the server already has, and the Modelfile only adds your settings. ollama show --modelfile prints the shape Ollama stores; it is cut after the template's first line here. 

PS> Get-Content .\Modelfile
FROM qwen2.5:0.5b
SYSTEM You answer in one short sentence.
PARAMETER temperature 0.2
PS> ollama create clinic-helper -f Modelfile
...
success
PS> ollama show --modelfile clinic-helper
# Modelfile generated by "ollama show"
# To build a new Modelfile based on this, replace FROM with:
# FROM clinic-helper:latest
FROM C:\...\models\blobs\sha256-c5396e06af294bd101b30dce59131a76d2b773e76950acc870eda801d3ab0515
TEMPLATE """{{- if .Messages }}
...
SYSTEM You answer in one short sentence.
PARAMETER temperature 0.2

How it was reproduced

On Windows 11 with Ollama 0.40.11 in Windows PowerShell 5.1, against a separate ollama serve on 127.0.0.1:15101 with its own models folder; that port and folder are the test's own. The four broken inputs were a 60-byte text file, a 144-byte zip made with Compress-Archive, a 125-byte file starting with <!DOCTYPE html>, and the first 1,000,000 bytes of a real GGUF, each with FROM ./clinic-helper.gguf. The working GGUF was the qwen2.5:0.5b blob from the test's own pull, copied out; its SHA-256 equals its blob name. The two Hugging Face requests were HEAD requests, so nothing was downloaded.

Frequently asked

What does 'unsupported file type' mean in ollama create?
The file in the FROM line does not start with the four bytes GGUF, so Ollama cannot read it as a model. The numbers in brackets are the bytes it found: 80 75 3 4 is a zip archive and 60 33 68 79 is the start of an HTML page.
How do I download a GGUF file from Hugging Face correctly?
Use the download link, whose path contains /resolve/, not the page link with /blob/. In the test the /blob/ link answered with an HTML page and the /resolve/ link with a redirect to the file. Then check that the file's first four bytes read GGUF.
Does the .gguf extension matter to Ollama?
No. Ollama reads the content: a zip, a web page or a text file renamed to .gguf failed the same way in the test, while a real GGUF worked. If you downloaded an archive, extract it and point FROM at the GGUF file inside.

More decoded errors in the Fixes category. When the FROM path does not exist at all, Ollama reads it as a model name instead: 'invalid model name' from a FROM path.