Logging into ZimaOS over SSH and finding that system folders are read-only does not mean your account is broken. ZimaOS deliberately protects most of its operating-system filesystem from normal writes, even when a user elevates privileges. The February 2026 source thread started as an SSH-permission question but quickly revealed a more useful goal: automatically pull phone photos from OneDrive into NAS storage and then make those files available to Immich.
The important design lesson is to separate the immutable system layer from writable data. Use SSH or the web terminal for administration, keep user-created scripts, configuration, and application data under /DATA or another managed storage location, and avoid trying to turn ZimaOS into a conventional Ubuntu server by installing packages into the protected root filesystem.
Read-Only SSH Access Is Normal ZimaOS Behavior
The original user could authenticate with their normal ZimaOS username and password but could not write where they expected or install rclone as if the host were Debian or Ubuntu. A first reply suggested sudo or sudo -i, but another community participant correctly distinguished privilege from filesystem mutability: becoming root does not make a read-only system image writable.
Current IceWhale CLI guidance now confirms this behavior directly: most system folders are read-only even when logged in as root, while user and application data live under /DATA.
Use the current ZimaOS CLI filesystem model before treating a failed write under /usr, /app, or another system path as a permissions bug.
sudo Changes Privilege, Not the Root Filesystem Design
sudo is still useful when a command requires elevated privileges, but it cannot override a filesystem that ZimaOS intentionally mounts read-only. This explains why “try root” can be the wrong answer when the error is Read-only file system rather than Permission denied.
For durable customization, place scripts and state on writable storage. Do not build a workflow that depends on manually modifying the base operating-system image, because updates can replace or invalidate those changes even if a workaround temporarily succeeds.
Current ZimaOS Enables SSH from Developer Mode
SSH itself remains a supported administration path. Current ZimaOS exposes an SSH Access toggle under Settings > Developer Mode and also provides a browser terminal.
Follow the current SSH and web-terminal setup instead of assuming that read-only system folders mean SSH is only partially enabled.
The Source User Wanted OneDrive → NAS → Immich
The user's intended workflow was:
- upload a small batch of phone photos and videos to the free OneDrive space;
- regularly transfer those files from OneDrive to the NAS;
- make the local destination available to Immich;
- after confirming the transfer, remove the cloud copies so the limited OneDrive quota can be reused.
This is more than ordinary backup. It includes a destructive final step: deleting the source after successful transfer.
The February 2026 Backup App Was Described as Copy/Sync, Not Move
In the source thread, the user noticed that the built-in Backup app copied OneDrive data but did not empty the cloud folder afterward. A community reply said that was intentional and described the Backup app as non-destructive, without a delete-after-copy option in that UI.
That statement belongs to the February 2026 source environment. It was a community explanation rather than an IceWhale staff reply in the thread, so it should not be frozen into a permanent claim that “ZimaOS can never move cloud files.”
Current ZimaOS Files Can Move Cloud Data to Local Storage
Current IceWhale documentation now shows OneDrive, Google Drive, and Dropbox mounted directly in Files. It also documents selecting cloud content, choosing a local storage space, starting a move, and verifying the completed transfer.
For occasional or manually supervised migration, use the current cloud-to-local transfer workflow in Files. This is simpler than building an rclone container when the transfer does not need unattended scheduling.
Backup and Move Have Different Failure Semantics
A backup should preserve the source. A move can remove the source after transfer. That difference matters when the source is the only cloud copy of phone photos.
If the goal is to reclaim OneDrive space automatically, the automation should not delete a cloud file merely because a copy command returned without an obvious error. A safer workflow verifies that the local file exists and is readable, then deletes the source only after the success condition is explicit.
For Scheduled Delete-After-Transfer Automation, Isolate rclone from the Host OS
The source community recommended running rclone in Docker rather than trying to install it into the ZimaOS root filesystem. That architecture matches the broader ZimaOS design: the container holds the tool, while its configuration and destination folders are mapped to writable ZimaOS storage.
If you build that workflow, keep the rclone configuration and scripts on persistent storage such as /DATA/AppData or another managed data folder. Map only the local directories the job needs instead of giving the container broad access to the entire NAS.
The exact rclone move command was community guidance, not an IceWhale-authored command in this thread, so test it on disposable files before allowing any automation to delete cloud originals.
Keep the Transfer Folder Separate from Immich's Managed Library When Appropriate
The source user described using the downloaded directory as an Immich import location. Immich can consume external-library or upload-style data in different ways depending on the version and deployment. Do not simply point a destructive move job at Immich's internal database or application-data folders.
Use a normal media/import folder on managed NAS storage, then configure the current Immich package to read that folder using the storage method supported by the version you run.
Current Backup Still Has a Different Purpose from Cloud Migration
Current ZimaOS Backup is designed around scheduled, resumable copies and versioned restore points across Cloud, LAN, USB, and Zima storage. IceWhale explicitly distinguishes cloud sync from backup because destructive mirroring can propagate mistakes.
If the goal is protection rather than quota recycling, the current ZimaOS backup workflow is a better fit than delete-after-transfer automation.
A Safer OneDrive Photo Workflow
- Connect OneDrive through current ZimaOS Files or a dedicated container.
- Choose a writable local destination on managed storage, not a system folder.
- Transfer a small test batch first.
- Verify file counts, sizes, and a few actual photos/videos locally.
- Confirm Immich can see the local content using the intended import method.
- Only then remove cloud originals if reclaiming quota is the goal.
- Keep an independent backup of irreplaceable photos; moving the only cloud copy to one NAS is not a 3-2-1 backup.
ZimaOS SSH Read-Only FAQ
Why can I SSH into ZimaOS but not create files in system folders?
Most ZimaOS system folders are read-only by design. Writable user and app data belongs under managed data storage such as /DATA.
Will sudo make the ZimaOS root filesystem writable?
No. Elevated privileges do not change a filesystem that is intentionally mounted read-only.
Can current ZimaOS access OneDrive without manually installing rclone?
Yes. Current ZimaOS Files can connect OneDrive directly and move selected cloud content to local storage.
Was automatic delete-after-copy available in the source Backup UI?
The February 2026 community thread said it was not exposed there. Treat that as a historical Backup-app limitation, not a permanent statement about every current cloud-transfer workflow.
