ZimaOS Disk Became Full; Migration Stuck 5%

[timothy]

After running Resilio sync on 30TB of data, I think the indexing files have taken up a lot of space and filled up the ZimaOS partition that came with the Cube. Unfortunately this has caused some glitches/corruptions. The NAS functions are all working fine though (SMB, Finder, etc is all good).

I’ve manually deleted some files through Finder, but either the space didn’t clear up or it was quickly filled.

I’ve restarted several times but it’s not resolving the situation.

I did get Migration of data files to begin, but it’s stuck on 5% for two hours:

Whenever the dashboard page logs me out, I can log in and view the normal dashboard where there’s a warning about the ZimaOS partition.

But at this point the Migration section is either blank with no options available, or shows 14GB of App Data available to move, which means the original migration never worked.

I’m not sure how to clear up space from the ZimaOS partition? Or how to “reset” it or reinstall ZimaOS? What’s the safest way to fix this without risking the RAID database? My RAID etc is all working normally. (Which is funny after the disconnect/crash issues I had the last few days.)

Update:
The second migration option showed the GB amount and I began the migration.

At first it was progressing, but now it’s stuck at 45% for an hour…

I will let it sit overnight and see what happens.

Update 2:
Overnight it went up to 49%… I guess I’ll just leave it alone and see what happens.

[neat.ocean]

Did you ever resolve this i am having a similar problem

[timothy]

I did.

Eventually, the migration from the SSD to RAID completed, which allowed the OS to run normally. I don’t remember how long it took, but it was probably more than a day. For whatever reason the RAID or ZimaOS is very slow when there are tons of tiny files. I believe I also stopped Resilio from indexing or turned off the Docker or something, to stop it from trying to fill up the SSD.

However, I ended having a horrible experience with Resilio where it was renaming my files and made them invisible to ZimaOS, and I personally do NOT recommend Resilio … unless you check their “acceptable characters” documentation and are certain your filenames fit into those restrictions.

Otherwise Resilio will rename them and it can cause files to appear like they’re missing. This experience freaked me out. I thought I had lost hundreds of files. Zima updated ZimaOS to show uncommon characters, but I really don’t like how Resilio went about changing filenames against my intentions. At first I thought ZimaOS deleted or lost all the data and misplaced the blame on Zima, but no, Resilio hijacked my files.

So that’s just my rant against Resilio.

As for solving your specific problem, what exactly are you experiencing? Just a migration issue, or an issue with Resilio filling up the SSD, or something else?

[neat.ocean]

My problem was partly not paying attention i had loaded a large LLM to the onboard drive of the zimaboard 2. I then got locked out because of the full drive so i started a migration (it got stuck at 13% )and my sudo over ssh stopped working so i made possibly a silly decision i got in to the root terminal via kvm and deleted the offending data for the LLM docker container from /DATA/AppData/big-bear..ect to media/SSD-Storage/big-bear ..ect and am still stuck at 13% i have al my vital data backed up and am prepared to reinstal unless you have a thought or i havent been clear enough(long day).

[gelbuilding]

I think the issue here is that the ZimaOS-HD (system disk) became full, and because of that the migration from ZimaOS-HD > Cube stalled. Migration needs temporary working space, and when the system drive is at 100% it can’t move data properly, so it just sits at 5–50% even though nothing is progressing.

From what I see, the most likely cause is that an app (I believe Resilio, or possibly an LLM/Docker image) was writing into ZimaOS-HD instead of the Cube storage. When that happens, the OS partition slowly fills, and once it is full, normal functions like Docker, migrations, and UI updates struggle.

I also think the problems this user saw with long migration times and partial progress lines up with this, the system had nowhere to buffer files, so the migration could not complete.

Resilio in particular can cause trouble because it may rename or duplicate content, and if it is pointed at the wrong volume, it can easily fill the system disk. The member above mentioned exactly this: once they stopped Resilio from touching ZimaOS-HD, the system returned to normal.

What I suggest:

Free some space on ZimaOS-HD first (for example, stop/delete the offending app or remove unused images), then retry the migration. Even a couple of GB free should allow the process to finish.

I believe it’s also worth confirming that all app storage paths point to Cube (/DATA) moving forward, not ZimaOS-HD. If the migration still doesn’t work after space is cleared, reboot and try again. If that still fails, sharing logs or contacting IceWhale support would be helpful.

In short, the migration didn’t break; it likely paused because there was no free space on ZimaOS-HD for it to continue.

---

[timothy]

It’s good that you have your data backed up, as that honestly may be the fastest route. Otherwise you’d have to leave the migration alone and see if it nudges forward over time.

But if you’re on a Zimaboard without a huge RAID5 setup like I have, then I wonder if it stalling at 13% is not the same as what I experienced. I believe my slow migration was purely due to the large quantity of small files. Migrating an LLM and some docker files is quite different. The OS might really just be ‘crashed’ at 13%, which is what I was concerned about in my case. But over the course of a few days my migration continued to progress.

Just to emphasize, make sure you do have all your data backed up that’s currently on your drives/RAID. In the case of the ZimaCube, losing/erasing/damaging/swapping the OS SSD would make the RAID setup inaccessible. When I had my Cube replaced I could swap the OS SSDs and my RAID swapped over to the new Cube just fine. But I don’t want to mess up the OS SSD again and am looking forward to when it’s possible to back it up in a future update.

Anyway, if corrupting a RAID isn’t your concern, then it’s probably fastest to just start fresh. It really did take days for what I went through.

Edit:

@gelbuilding

the system had nowhere to buffer files

This makes sense. Everything came to a standstill. My migration probably would’ve happened quicker, even without thousands of small files, if there were buffer space.

[crankyoldyank]

Me too!

[crankyoldyank]

“acceptable characters” … I also have those issues with Jellyfin - playback error. It would be nice if someone wrote a batch file that would parse directories to “fix” bogus characters. “Real” programmers have already learned these during their experience in CS. Please help us “mere mortals” who have media files collected from god knows where thru the years….