When Docker refuses to start after a ZimaOS data migration, the last line in the log can be misleading. In this February 2026 source case, Docker eventually reported that the overlay2 storage driver was unsupported. Reading a few lines earlier reveals the real failure: Docker could not create temporary files or test overlay storage because the system disk had no space left on device.
The user had a 180 GB ZimaOS SSD and had accidentally left a growing Immich database on it. By the time they attempted migration, there was not enough free space for a clean move. After several attempts and manual log deletion, AppData appeared to migrate, but the system disk still reached 100% and Docker could no longer initialize after reboot.
Immich Filled the Small System SSD Before the Migration
The source user installed Immich without moving its database away from the system drive. As the photo stack grew, the disk filled and ZimaOS began reporting errors.
This matches current IceWhale guidance: application data should be placed on the main storage space rather than a small system disk because photo libraries, media metadata, document indexes, databases, and caches can grow quickly.
Migration Itself Needed Working Space
The user tried the ZimaOS migration workflow only after the system disk was already critically full. They said the first migration attempts failed because there was insufficient free space to buffer the operation.
This is an important operational lesson: move AppData before the system disk reaches the last few gigabytes, not after Docker and migration services are already starved for workspace.
The Docker Socket Message Was Only a Symptom
Applications reported:
Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
Is the docker daemon running?That message means the Docker daemon is unavailable. It does not identify why the daemon failed.
The Journal Revealed the Real Root Cause
The important lines were:
no space left on device
Failed to ensure default apparmor profile is loaded
mkdir /var/lib/docker/overlay2/check-overlayfs-support...: no space left on device
failed to start daemon: error initializing graphdriverDocker first failed because it could not write temporary data. The later driver not supported message was a consequence of the failed storage-driver initialization, not evidence that the running kernel suddenly lost overlay2 support after migration.
Why Restarting Docker Did Not Solve It
The user tried to restart docker.service and docker.socket manually and received Access denied. A community reply connected that to ZimaOS's appliance-style service controls.
Even if the service restart had been allowed, it would not create free disk space. The daemon would simply hit the same write failure again.
Deleting Docker Temp Files Did Not Recover Enough Space
The community suggested clearing temporary Docker files after first checking disk space. The original user tried that and replied that the system drive was still 100% full and Docker still would not start.
This negative result is useful: small temporary cleanup cannot repair a storage design where the system disk remains completely saturated.
The Source User Chose Backup and Factory Restore
After the cleanup attempt failed, the user decided to back up /DATA/AppData and reinstall/restore ZimaOS. The community responder recommended noting installed apps, using Factory System Restore, then migrating application-related storage to the large disk before reinstalling apps.
The public thread ends after the user said they would do that. It does not contain a post-restore confirmation, so the page should not label the reinstall as a verified final fix for this specific user.
Current ZimaOS Data Migration Is More Explicit About What Can Move
Current ZimaOS provides separate migration categories for:
- Docker Images;
- Docker Application Data;
- user databases such as Gallery, Downloads, Documents, Media, and Backup.
This is an important update to the older thread, where the discussion sometimes treated “AppData migration” as though it covered all Docker storage automatically.
Use the current ZimaOS Data Migration categories before a small system disk becomes critically full.
Prevent the Problem by Setting App Data Location Early
Current ZimaOS also exposes an app data location under Settings > Apps. IceWhale recommends pointing it at the storage array from the beginning rather than leaving all persistent app growth on the system device.
The current explanation of where ZimaOS apps store persistent data is the best preventive reference.
Check Both Capacity and Inodes
A filesystem can reject new files because it has no free blocks or because it has exhausted inodes. The source troubleshooting suggested checking both. The log in this case strongly points to normal capacity exhaustion, but checking both values is still a useful read-only diagnostic.
When Reinstall Becomes Reasonable
If the system disk has been 100% full, Docker storage metadata is damaged, the daemon cannot start, and safe cleanup cannot create enough working space, a controlled system restore can be faster and safer than manually editing Docker's overlay metadata.
Protect AppData and user data first, understand which disks the restore will touch, and avoid deleting the only copy of application databases.
Docker After Migration FAQ
Was overlay2 actually unsupported on the source hardware?
The logs first show that Docker could not create overlay2 test files because the disk was full. The driver message followed that failure.
Did clearing Docker tmp fix the source system?
No. The original poster said the OS drive remained 100% full.
Does current ZimaOS let you move Docker images separately from AppData?
Yes. Current Data Migration lists Docker Images and Docker Application Data as separate movable categories.
Was the factory restore confirmed successful in the thread?
No. The user said they would proceed with it, but the public thread ends before a post-restore result.
