Keep Ollama From Eating Your Linux Disk: Move Model Storage and Prune Safely

If you run Ollama on Linux for more than a weekend, disk pressure usually arrives before model fatigue does.

A few model pulls, a couple of larger variants, maybe an embedding model you meant to test once and forgot about — and suddenly your root filesystem is carrying far more weight than you planned for.

This guide is the practical fix:

• find where Ollama is storing models
• measure what it is using
• move model storage to a better location
• make the change persistent with systemd
• remove models you no longer need
• verify everything before you trust it

No magic. No vague “just symlink it” advice.

What the docs say

According to the Ollama FAQ:

• on Linux, models are stored by default under /usr/share/ollama/.ollama/models
• you can move them by setting the OLLAMA_MODELS environment variable
• when Ollama runs as a Linux service, environment variables should be set with a systemd override
• the Ollama service account needs read/write access to the new directory

That gives us a clean, supported path. So that is what we will use.

Why this article is a different angle

I have already written about building a self-hosted AI stack and automating local AI workflows. This one is intentionally narrower:

• it is not about deploying Ollama from scratch
• it is not about reverse proxies, web UIs, or agent orchestration
• it is about operational hygiene on a Linux host that is already running Ollama

If your root disk is getting crowded, this is the part that matters.

Step 1: Measure what Ollama is using right now

Start by checking the current model directory size.

sudo du -sh /usr/share/ollama/.ollama/models

If you want a slightly more detailed view:

sudo du -h --max-depth=2 /usr/share/ollama/.ollama/models | sort -h

Why du? Because it reports recursive disk usage for directories, and --max-depth lets you avoid drowning in output.

Then list the models Ollama knows about:

ollama ls

And check whether any models are currently loaded into memory:

ollama ps

That last check matters. If a model is actively loaded, stop it before moving files around.

Step 2: Pick a better storage location

Common choices:

• a larger secondary SSD such as /srv/ollama-models
• a dedicated data mount such as /mnt/ai/ollama-models
• fast local NVMe if you care about pull and load speed

I would avoid putting model storage on a slow or unreliable network mount unless you have tested the latency and failure behavior. Local storage is simpler and usually faster.

For this example, I will use:

/srv/ollama-models

Create it and hand ownership to the ollama service account:

sudo install -d -o ollama -g ollama -m 0755 /srv/ollama-models

If you prefer to create it another way, this is equivalent:

sudo mkdir -p /srv/ollama-models
sudo chown -R ollama:ollama /srv/ollama-models
sudo chmod 755 /srv/ollama-models

Step 3: Stop Ollama cleanly

Stop the service before copying or moving model data.

sudo systemctl stop ollama

Confirm it is really stopped:

systemctl is-active ollama

Expected result:

inactive

Step 4: Move the existing model store

Use rsync first so you get a safer, restartable copy path.

sudo rsync -aHAX --info=progress2 /usr/share/ollama/.ollama/models/ /srv/ollama-models/

Then verify the copy size:

sudo du -sh /usr/share/ollama/.ollama/models /srv/ollama-models

If the sizes look right, keep the original as a temporary rollback point for now. Do not delete it yet.

Step 5: Persist the new location with systemd

The supported Linux way is a systemd override.

Open the override editor:

sudo systemctl edit ollama

Add this:

[Service]
Environment="OLLAMA_MODELS=/srv/ollama-models"

If you prefer to write the file directly:

sudo mkdir -p /etc/systemd/system/ollama.service.d
sudo tee /etc/systemd/system/ollama.service.d/override.conf >/dev/null <<'EOF'
[Service]
Environment="OLLAMA_MODELS=/srv/ollama-models"
EOF

Reload systemd and start Ollama again:

sudo systemctl daemon-reload
sudo systemctl start ollama

Step 6: Verify Ollama is using the new path

First, inspect the effective service definition:

systemctl cat ollama

You should see the override with:

Environment="OLLAMA_MODELS=/srv/ollama-models"

Then check the service environment more directly:

systemctl show ollama --property=Environment

You want output that includes:

OLLAMA_MODELS=/srv/ollama-models

Now verify normal behavior from Ollama itself:

ollama ls

And optionally test a model start:

ollama run gemma3 "Reply with: storage path test successful"

If the service starts normally and your existing models are visible, the move worked.

Step 7: Remove the old copy only after verification

Once you are satisfied that Ollama is reading from the new location, you can remove the original model directory contents.

I strongly recommend renaming first, waiting a day, and only then deleting.

sudo mv /usr/share/ollama/.ollama/models /usr/share/ollama/.ollama/models.backup-$(date +%F)

If everything still works after a safe waiting period, remove the backup:

sudo rm -rf /usr/share/ollama/.ollama/models.backup-2026-04-10

Adjust the date suffix to whatever your host actually created.

If you prefer a more cautious flow, leave the backup in place until after your next reboot and model pull.

Step 8: Prune models you no longer need

Relocating storage helps. Removing dead weight helps even more.

List models:

ollama ls

Remove one you do not need:

ollama rm mistral

Remove another tagged variant:

ollama rm qwen2.5:14b

Then re-check disk usage:

sudo du -sh /srv/ollama-models

A quick review workflow

I like this simple loop:

ollama ls
sudo du -sh /srv/ollama-models
ollama ps

That tells you:

• what is installed
• how much space the store is using
• what is currently loaded

Optional: keep a tiny audit trail

If this is a shared homelab or a server you will revisit later, write down the change.

For example:

sudo mkdir -p /etc/ollama
printf '%s
' \
  'Model storage moved to /srv/ollama-models on 2026-04-10' \
  'Configured via /etc/systemd/system/ollama.service.d/override.conf' \
  | sudo tee /etc/ollama/storage-note.txt >/dev/null

That is not required by Ollama, but future-you will appreciate it.

Troubleshooting

Ollama starts, but no models appear

Usually one of these:

• OLLAMA_MODELS points to the wrong directory
• the copy step was incomplete
• permissions do not allow the ollama user to read the new path

Check:

systemctl show ollama --property=Environment
sudo ls -lah /srv/ollama-models
sudo namei -l /srv/ollama-models

That last command is useful because directory permissions on parent paths can break access even when the final directory looks correct.

Permission denied on the new directory

Fix ownership:

sudo chown -R ollama:ollama /srv/ollama-models

Then restart:

sudo systemctl restart ollama

You changed the path but forgot to reload systemd

That is a classic one.

Run:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Root filesystem is still full

Remember that moving the live store does not free space until you remove the old copy.

Check both paths explicitly:

sudo du -sh /usr/share/ollama/.ollama /srv/ollama-models
df -h /

A safer pattern than symlinks

You can find people recommending symlinks for this. I would rather use the documented OLLAMA_MODELS environment variable.

Why?

• it is the supported mechanism documented by Ollama
• it is visible in the service definition
• it is easier to audit later
• it avoids “what does this path actually point to?” surprises during troubleshooting

Symlinks can work, but clean service configuration is easier to reason about.

Final checklist

If you want the short version, this is it:

# inspect current usage
sudo du -sh /usr/share/ollama/.ollama/models
ollama ls
ollama ps

# prepare new location
sudo install -d -o ollama -g ollama -m 0755 /srv/ollama-models

# stop service and copy data
sudo systemctl stop ollama
sudo rsync -aHAX /usr/share/ollama/.ollama/models/ /srv/ollama-models/

# persist new storage path
sudo mkdir -p /etc/systemd/system/ollama.service.d
sudo tee /etc/systemd/system/ollama.service.d/override.conf >/dev/null <<'EOF'
[Service]
Environment="OLLAMA_MODELS=/srv/ollama-models"
EOF

# reload and verify
sudo systemctl daemon-reload
sudo systemctl start ollama
systemctl show ollama --property=Environment
ollama ls

That is the whole move in a form you can audit.

References

• Ollama FAQ — model storage location, OLLAMA_MODELS, Linux service environment configuration: https://docs.ollama.com/faq
• Ollama Linux docs — recommended systemd service setup and customization via systemctl edit: https://docs.ollama.com/linux
• Ollama CLI reference — ollama ls, ollama rm, ollama ps: https://docs.ollama.com/cli
• Ollama API intro — default local API base URL: https://docs.ollama.com/api
• GNU du manual page — recursive disk usage and --max-depth: https://man7.org/linux/man-pages/man1/du.1.html

If you run local models on a small root disk, this is one of those five-minute cleanups that prevents an annoying weekend later.