I believe this is the main reason many new users run into storage issues or failed app installs on a fresh ZimaOS install.
On a new ZimaOS setup, the system defaults AppData and Docker image storage to ZimaOS-HD (/DATA). On ZimaBoard and ZimaBlade, ZimaOS-HD is often the small internal eMMC (sometimes only around 17GB). As soon as you start installing apps (Nextcloud, Immich, Jellyfin, etc.), Docker images, layers and app databases begin filling /DATA very quickly.
What happens next is very common:
- OS disk fills up fast
- app installs hang or fail
- migrations can fail (destination not empty)
- large mounts (Dropbox etc) and caches can cause instability
I do not believe this is user error. It is simply the default storage layout.
The 1-minute fix I suggest every new user does (before installing apps)
Before installing any apps, I suggest doing this first:
- Go to Settings > Apps
- Open Migrating location
- Set these to your large HDD/SSD:
- App data location > select your HDD/SSD disk
- App image location > select the same HDD/SSD disk
- User database > select the same HDD/SSD disk
Then install your apps as normal.
This one change prevents most “disk full” problems and keeps the internal ZimaOS disk clean.
3 Likes
Great. I was doing the same thing. I think this important note should go to ZimaOS official documentation.
1 Like
I agree this is an important note and it would be very helpful to include it in the official ZimaOS documentation, especially for new users. On a fresh install, AppData and Docker storage can default to /DATA (ZimaOS-HD), and on ZimaBoard/ZimaBlade that is often the internal disk, which fills quickly once apps are installed.
I can definitely relate to this as it happened to me when I first installed ZimaOS. Once I moved AppData, Docker image storage, and the User Database to a large HDD/SSD early, everything became much smoother.
I believe adding a simple “Recommended first step after install” section in the docs would greatly improve the new user experience and prevent many common storage-related issues.
2 Likes
Definitely. I also learned the lesson hard way. This type of small but important tips and recommendations make our life easier with ZimaOS.
1 Like
I did exactly as you suggested. ZimaBoard 832. Fresh ZimaOS 1.54 install….
migrate all data through Settings→Apps; Migrated: App data, App image, User database to
4GB SATA drive (SDA1) ( it showed that location when I hit Recommended Location button).
Got this in terminal:
Tried to install Linkwarden and Syncthing from App Store. Got this errror during each install.
Is there something I did wrong?
Thanks for your help.
That error:
open /media/sda1/docker/tmp/...: input/output error
points to a disk issue on sda1, not a migration problem.
Your paths look correct, so the likely cause is:
- disk I/O error
- filesystem issue
- or connection/power problem
Quick check:
touch /media/sda1/testfile
If that fails, the disk isn’t healthy.
Also check:
dmesg | grep -i error
If you see I/O or EXT4 errors, that confirms it.
Your approach (moving AppData/Docker off /DATA) is correct — but the target disk must be stable, otherwise installs will fail like this.
If you can share the dmesg output, we can confirm exactly what’s happening.
Thanks for the quick reply!
I am rebootiing to see if it wakes up.
I was suspect of this SSD. I seemed too inexpensive for 4 Tb.
By the way. Your advice regarding Move AppData etc is right on and well delivered. Thanks
Thanks for sharing, this confirms it clearly.
You’ve got multiple:
I/O error, dev sda
EXT4 journal aborted
Buffer I/O error
And even a simple write fails:
touch /media/sda1/testfile > Input/output error
That means the SSD (sda1) is not healthy, this is not a ZimaOS or migration issue.
What to do
- Reseat the SATA + power cable first (quick check)
- If the errors persist > replace the SSD
That drive is currently not safe for Docker/AppData
Hardware today can be overpriced, but for a NAS setup it’s critical to use reliable, quality drives, otherwise you’ll run into exactly these types of issues.
Your approach was 100% correct, just unlucky with the target disk.
