[FIX] ZimaOS Backup filling up System Drive or eMMC? Move Rclone cache to NVMe/HDD

Operating System ZimaOS
1

If you are using the built-in Backup app in ZimaOS, you may find your system drive filling up unexpectedly. In my case, a 64GB eMMC was nearly maxed out by hidden data. This is often caused by the Rclone cache (located at /DATA/.cache/rclone), which stores temporary “chunks” during cloud syncs.

Since the ZimaOS UI doesn’t allow you to change the Backup parameters or the cache location directly, here is a persistent fix using a symbolic link.

The Requirement

You will need a secondary storage drive (NVMe, SSD, or HDD) that is permanently mounted via the ZimaOS Storage Manager.

[!CAUTION]

Do not use a temporary USB stick or a drive that isn’t auto-mounted at boot. If the drive is missing when the backup starts, Rclone may bug out or default back to filling your system drive.

The Solution: Persistent Symlinking

1. Locate your Storage Path

Find where your large drive is mounted. In ZimaOS, these are usually found under:

/DATA/.media/your_drive_name

2. Create the new Cache folder

Run this in the terminal (replace your_drive_name with your actual path):

mkdir -p /DATA/.media/your_drive_name/rclone_cache

3. Wipe the bloated system cache

Make sure no backups are currently running in the UI.

sudo rm -rf /DATA/.cache/rclone

4. Create the Symbolic Link

This redirects the system to use your large drive instead of the internal storage:

ln -s /DATA/.media/your_drive_name/rclone_cache /DATA/.cache/rclone

To confirm the redirection is active, run:

ls -ld /DATA/.cache/rclone

The output should show an arrow pointing from the system path to your storage drive. Your system drive should now show a significant increase in free space!

Why this works

  • Persistence: Because /DATA is a persistent partition on ZimaOS, this link survives reboots.

  • Drive Health: Moving the cache to a secondary drive prevents unnecessary wear and tear on your internal system drive.

  • Seamlessness: The Backup app continues to work as intended, unaware that the data is actually living on your secondary storage.

Text was produced with ai, because I am not really good with English.
Note: last time Backup filled my entire drive (EMMC 64GB) and stopped working (+ Google Drive link was broken). Tmp fix: wipe the rclone cache.

2 Likes
2

Solid write-up :+1: This is a legit fix, and you’ve correctly identified the real culprit: rclone cache growth outside the UI’s control.

A few confirmations + small clarifications for others reading:

  • /DATA/.cache/rclone is persistent on ZimaOS and will happily fill eMMC/NVMe during large or stalled cloud syncs
  • The Backup app does not expose cache limits or cache path, so symlinking is currently the cleanest solution
  • Using /DATA/.media/<drive> is correct as long as the disk is auto-mounted at boot

Extra safety notes worth highlighting:

  • Stop the Backup task before deleting the cache (as you said)
  • Do not point the symlink to removable or flaky USB storage
  • If the target disk is missing at boot, rclone may recreate a real directory and start filling system storage again

Optional verification (for peace of mind):

df -h /DATA
du -sh /DATA/.cache

Bottom line:
This is a practical, reboot-safe workaround until IceWhale exposes rclone cache controls in the Backup app. Nice catch.

2 Likes
3

I’ve tryed clearing the cash but I got no message back and my boot ssd is still full.

Then I tried creating the symbolic link and this is the error I got back:

“ln: failed to create symbolic link ‘/DATA/.cache/rclone’: Permission denied”.

Why am I denied permission? I’m the admin.

4

Hey mate, this is the same core issue you’ve been hitting in your other thread, and it’s not about being “admin” in the UI.

On ZimaOS, the web UI admin user is not the same as having full system permissions in the filesystem.

That “permission denied” error is happening because the path you’re trying to modify is owned by root, and your current shell user doesn’t have rights to change it.

Also important here, the fix Valentyn posted assumes two things are true:

  1. The original cache folder was actually removed
  2. The command is being run with sufficient permissions

Right now neither of those are confirmed in your case.

The bigger issue though is this, and I’ll be straight with you so we don’t keep going in circles.

You’re running commands, not checking what actually exists on disk, and then jumping to the next step. That’s why it feels like nothing is working.

Before doing anything else, you need to verify the state of the system first, otherwise every step after this is guesswork.

At minimum you need to confirm:

Does /DATA/.cache/rclone still exist as a real folder
Who owns it
What permissions it has

If that folder still exists and is owned by root, the symlink command will always fail exactly like you’re seeing.

So the short answer to your question is:

You’re denied permission because you’re not running the command with the required system-level privileges, and the target path is protected.

Until that’s handled properly, the symlink step will never work.

If you want to continue troubleshooting this properly, you need to slow it down and check each step instead of skipping ahead. Otherwise you’ll keep hitting the same wall.

1 Like