ZimaOS v1.7.0 Release: The NAS Rabbit Hole Starts Here!

Announcements
22

My observations following this update are the same as @isanto1306 and more specifically for:
Point 1
I had already reported empty folders since v1.6.2

Point 3
URL ports for shortcuts are now set for both local and Reverse Proxy. It is no longer possible to modify them both through the “form” panel and through the YAML?

Others:
I still don’t understand the “WebUI rendering mode” button?

I appreciate:
The list of applications deployed in the application store.

Roadmap:
Will file sharing links be available again?
Is a native Firewall being considered (although we have the Lintux one) ?

Thank you for this great work and for following up on our comments.

23

Screenshot 2026-07-29 at 19.34.31
Screenshot 2026-07-29 at 19.34.312704×2132 812 KB

What I can consistently reproduce is that when I use Files for basic file transfers (both internal and external sources), the memory usage of the icewhale-files application continuously increases. My suspicion is that there is a memory leak.

At the moment, the server is becoming difficult to use because accessing it takes a very long time, most likely due to the excessive memory consumption. The only way to restore responsiveness is to restart the server, but this is only a temporary fix, as the issue eventually returns.

24

Hi there , i have start using ZimaOS few days back (testing stated on 1.6.2) and then install just day before final relase the 1.7.0 beta 2.

The new store is major improvment → in 1.6.2 in testing i hat problem with losig the Zima app after adding more app list and needed to manual fix.

1.7.0 looks good , I have tested lots of more other NAS system before finaly install Zima , my nas before was running on Arch and even that it vas stable and simple .. managin some stuff was pain in ass :smiley: = lots of stuff needed to be done manualy.

But for zimaOS i have two reqest. One please build Btop witout GPU support i have disable GPU and i thing i will not be only one … so the native in zima dont work and need to install another in app (container) …. i now disabling gpu driver is not easy to - i hat to build small container that check and wrtie the block list in cmdline every reboot so it will stay there even after update of system.

Second = why the backup proces use rclone ? rsync can make the same with much less computing power and faster → any specific reason ? Or thing about improvment in future like going from ext4 to btrfs (that i read in your release history).

Thanks :slight_smile:

EDIT : And qestion is there any plans for more “paid” special function (i dont now, like domein name for easy over internet acces or some other goodies ?)… i will gladly pay for the “plus” but for now the users and disk limit is fine for me → afer few more weaks of running if there will no be any problems and i will stay in zima i will gladly buy the licens for the price anyway = but promis of “cool” suff under payd wall comming will make my decision sooner .

25

Trying to fix the test server of Plex I had running under ZimaOS resulted in having the application files nuked when I deleted the linux-server Plex app from the Zima OS Apps section.

That was my fault for not knowing that your store worked more like the Package Manager under Synology DSM for a package install, instead of deleting only the container under Syno DSM in their Container Manager app.

I reset this bench system to a new install of ZimaOS with my flashdrive that had the 1.4.1 version ISO on it.

I used OBS Studio to show how I installed the linux-server Plex container to point to media on two different USB portable drives on a little Intel i3 signage PC, if that 20 minute recording is of interest as an unlisted YouTube upload.

The fresh Plex container spun up under 1.4.1, and I was able to claim the server by clicking on the Plex icon under Zima and also added a Plex media library from each portable drives.

My test servers only use public domain media.

It was a different issue after the 1.7.0 upgrade this time.

With my original install that was identical to this new one, the container started and Plex was running and accessible from Plex’s app.plex.tv webapp login, and media played fine after the 1.7.0 update.

I could not click on the Plex icon in Zima OS and somewhere there was a
error and the YAML tab looked totally foreign to the Docker Compose script that I use for Plex installed through Dockhand under Syno DSM, Ugreen’s UGOS, FygoOS, and a container install under any Ubuntu 24.04 based distro.

With this new install, the Plex container will not start at all.

SSH’ing in to run docker start plex returns…

WARNING: Error loading config file: open /DATA/.docker/config.json: permission denied

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post “http://%2Fvar%2Frun%2Fdocker.sock/v1.51/containers/plex/start”: dial unix /var/run/docker.sock: connect: permission denied

Error: failed to start containers: plex

There’s no way to capture the full Plex container log with a screenshot, so heres a copy and paste of it.

plex  | [migrations] started
plex  | [migrations] no migrations found
plex  | ───────────────────────────────────────
plex  | 
plex  |       ██╗     ███████╗██╗ ██████╗
plex  |       ██║     ██╔════╝██║██╔═══██╗
plex  |       ██║     ███████╗██║██║   ██║
plex  |       ██║     ╚════██║██║██║   ██║
plex  |       ███████╗███████║██║╚██████╔╝
plex  |       ╚══════╝╚══════╝╚═╝ ╚═════╝
plex  | 
plex  |    Brought to you by linuxserver.io
plex  | ───────────────────────────────────────
plex  | 
plex  | To support LSIO projects visit:
plex  | https://www.linuxserver.io/donate/
plex  | 
plex  | ───────────────────────────────────────
plex  | GID/UID
plex  | ───────────────────────────────────────
plex  | 
plex  | User UID:    1000
plex  | User GID:    1000
plex  | ───────────────────────────────────────
plex  | Linuxserver.io version: 1.43.3.10828-00f62d37d-ls316
plex  | Build-date: 2026-07-27T12:31:44+00:00
plex  | ───────────────────────────────────────
plex  |     
plex  | **** creating group groupfyf5 with id 28 ****
plex  | **** adding /dev/dri/card0 to group groupfyf5 with id 28 ****
plex  | **** creating group groupcflg with id 107 ****
plex  | **** adding /dev/dri/renderD128 to group groupcflg with id 107 ****
plex  | **** Server is unclaimed, but no claim token has been set ****
plex  | Docker is used for versioning skip update check
plex  | [custom-init] No custom files found, skipping...
plex  | Starting Plex Media Server. . . (you can ignore the libusb_init error)
plex  | Connection to localhost (127.0.0.1) 32400 port [tcp/*] succeeded!
plex  | [ls.io-init] done.
plex  | Critical: libusb_init failed
plex  | Dolby, Dolby Digital, Dolby Digital Plus, Dolby TrueHD and the double D symbol are trademarks of Dolby Laboratories.

I’d like to be able to help my friend update to the latest ZimaOs without breaking her production Plex Server install on an older Intel 9th gen Dell Optiplex.

My install was just a test install to support other Plex Server owners using ZimaOS for Plex based on my recommendation that it’s a great headless option for a small Plex server.

If need be, I can reset again to try the BigBear container, although I always use the linux-server container and would definitely need further instructions to help my friend and others swap containers if that image survives the new OS update.

Accidentally deleting my previous Plex application files was not expected without first receiving a warning, but it is what it is and now I’ve learned something new.

Thank you in advance.

26

Thanks for your feedback. Did you preview any HEIC photos during this process? We are trying to reproduce the issue, so we would like to confirm a few more details:

  1. Did the issue occur when using the copy feature inside Files, or when uploading files?
  2. Approximately how many files were being transferred, and what was the total size?
  3. Were the files being transferred into an encrypted folder?
  4. If both the source and destination are on the internal storage, meaning no external USB drive, cloud drive, or LAN is involved, does the issue still occur?

This information will help us reproduce and identify the issue more quickly. Thanks for your help.

27

Thanks for your feedback. Currently, ZimaOS does not preserve custom GRUB configurations during system upgrades. We plan to add support for this feature in a future release.

For the current situation:

  1. If the system can still boot normally, please run the following command first:
sudo update-grub
  1. If the system can no longer boot, you will need to connect the drive to another computer, mount the original system partition, and then regenerate the GRUB configuration.
28

Thanks for the detailed description. Could you please send us the screen recording?

I tried installing linuxserver/plex:1.32.8 on ZimaOS 1.4.1, claimed the Plex Server, and added a library. After upgrading to 1.7.0, Plex still worked normally.

For the permission error, you can try running the following command:

sudo docker start plex

Also, the app data under the mapped path being deleted when uninstalling the app is indeed an issue. We will fix this in the next version.

29

What I’ve found so far…

Removing the
manually from the YAML tab once I found it allows the linux-server Plex container to start normally on my original hardware configuration with my test Plex Server under ZimaOS, after updating to version 1.7.0.

My second newer ZimaOS hardware install survived the update to version 1.7.0 when only using a Plex media folder located on the boot drive.

I have not tested the success of the new OS update for a Plex container pointed at a local shared media folder.

The Plex Server container install through a Docker compose script pointed at local media survived the update too, while I haven’t tested that install option with USB media.

I normally prefer a Docker compose script install of Plex through Dockhand or Portainer, but it’s too easy to point at USB media drives when installing the linux-server Plex container through ZimaOS’s app store.

That’s the easier install option for people new to a NAS OS and Plex Server, which is why I highly recommend Zima OS as the perfect headless Plex Server option for someone with a few portable drives.

If you’d like, I can reset one of my bench systems once you have a fix for the
issue in the next update, or reset now to see if a path to shared media folder from another NAS survives the update.

I’d appreciate knowing if there’s anything my Plex friend can do to prep her ZimaOS set up with a portable storage drive before updating to the latest version, or whether she should wait for the next update to roll out.

I’m confident now that I can get her by this current issue if she experiences the same
error in her Plex YAML that I did.

We’re three US States apart so I can never be fully hands on while helping her.

Here’s my findings in this 21 minute video.

30

I reset ZimaOS on the HP Prodesk PC with the same two USB media drives that were plugged into the Seneca signage PC, and had a successful update to ZimaOS 1.7.0 with a Plex container installed the same as it was previously, which eliminates my previous theory that the USB drives were an issue.

I had temporarily removed one of the two 4GB RAM stick from the signage PC with it’s 11th gen i3 processor a few days before the initial update on that system to version 1.7.0.

Resetting to the older version of ZimaOS with 8GB’s of RAM in the system and a new identical Plex Server install with the same USB media then upgraded perfectly fine to version 1.7.0 without an issue on the original system..

I kind of feel like I’ve been wasting your resources, but if you can recreate the issue on 4GB’s of RAM, then maybe I won’t feel as bad!

31

Test Report

Hardware

  • External drive: 2 TB Seagate USB 3.0 HDD connected to the front USB 3.0 port of a Microforum N5 with 32 GB RAM.

  • Internal storage:

    • Multiple 12 TB HDDs (various brands) configured as the main storage pool.

    • Three SSDs used for the OS, temporary files, and Docker data.

    • One internal SanDisk USB flash drive used for testing.

Software

  • ZimaOS 1.7 (upgraded from 1.6 → 1.7 Beta 1 → 1.7 Beta 2 → 1.7 release).

  • Safari browser for accessing the Files app.

Baseline

On ZimaOS 1.6, the Files app worked correctly without any issues.

Test Dataset 1

Using “Get Info” in the Files app

  • 3 directories

  • 330 MP3 files

  • Total size: 2.83 GB

Test Dataset 2

Using “Get Info” in the Files app

  • 109 directories

  • 4,270 FLAC files

  • Total size: 573 PB - this must be a mistake from the Files-app

Test 1 – Copy files from External HDD to Temporary SSD

Source: External USB HDD
Destination: Temporary SSD
Method: Files app

Result

  • Copy starts at approximately 20 MB/s.

  • Memory usage continuously increases until all available RAM is consumed.

  • As memory fills up, the operating system becomes almost completely unresponsive.

  • If the ICE-Whale-Files process is terminated before memory usage reaches approximately 80%, memory growth stops and the system remains the same.

Test 2 – Copy files from Network Share (Samba) to Temporary SSD

Source: Samba network share
Destination: Temporary SSD
Method: Files app

Result

  • No issues observed.

  • Memory usage remains stable.

Test 3 – Copy files from Temporary SSD to Main Storage Pool

Source: Temporary SSD
Destination: Main storage pool
Method: Files app

Result

  • No issues observed.

  • Memory usage remains stable.

Memory Usage – Dataset 1

When copying from the external USB drive to the temporary SSD:

  • Files app starts with approximately 101 MB of memory usage.

  • Memory usage gradually increases to approximately 10 GB.

  • After the copy completes, the Files app continues to use 10 GB of RAM instead of releasing it.

  • On a system with 32 GB RAM, this occupies approximately 35% of total system memory.

Moving the same files from the temporary SSD to the main storage pool increases the Files app’s memory usage by only about 0.6%.

Memory Usage – Dataset 2

When copying the larger dataset from the external USB drive:

  • Files app starts at approximately 101 MB of memory usage.

  • Memory usage steadily increases beyond 20 GB during the copy.

  • Memory usage continues to grow while copying is in progress.

  • After aborting the copy, the operating system remains responsive, but the Files app continues to occupy approximately 20 GB of RAM instead of releasing the allocated memory.

When terminating the program icewhale-files: /user/bin/icewhale-files (using BTOP++) the allocated memory gets released.

Update:
When writing from the storage pool to the extenal drive there is no increase of memory usage.

1 Like
32

I just sent you a private message, please check your inbox

33

Why not just drop the file in ZimaOS-HD/.ota/offline? Every time I have done a manual ZimaOS update I just downloaded the .raucb file from the GitHub repo, dropped it into that directory, and updated through the UI. I suppose I could do it via SSH, but that offline update process is already documented by IceWhale. I just figured that is how you are supposed to do it since it is in their documentation.

34

Normally, that’s exactly how I do it, and it usually works. Unfortunately, this time it didn’t.

In general, I’ve found the offline update process isn’t always reliable for me, so I use my own method instead. It’s faster, simpler, and has been more consistent in my experience.

35

Ahh, okay. Thanks for the explanation. Most of the time I just wait for the update to be offered to my server, but there have been four or five major updates that I have done manually using the offline process. I actually did the offline update for 1.7.0, so it is interesting that it didn’t work for you. Thanks for the info, though. Now I have another way to do it if I ever have an issue. Cheers!

1 Like
36

You’re welcome!

I normally use the offline update method as well, and it has worked for me in the past. This was actually the first time it failed, so I switched to updating via SSH instead. I’ve found it to be quicker and more reliable for me.

Another advantage is that I keep both the latest release and the full release packages stored locally. That way I can easily upgrade or roll back to any version whenever I want, without having to download it again.

It’s always good to have another option when something doesn’t go as expected. Cheers!

1 Like
37

For sure! Although, I would probably limit it to the last five releases or something like that. It will start taking up a lot of storage when the .raucb files start piling up.

By the way, do you happen to know what the “Web UI Rendering Mode” setting does in the v1.7.0 update? I came back to this thread to see if anyone had mentioned it because I asked back on the release day (I think I was the first comment, actually). It was not mentioned in the release notes. I figured it would affect the resolution or animations of the UI, but I have toggled back and forth between “Performance” and “Standard” and I cannot see any difference. It seems like it doesn’t do anything. It is not critical, I am just curious.

38

I have to admit I only used v1.7.0 for a few hours. In my experience it was still too buggy, so I rolled back to a stable version because I rely on my NAS every day.

Because of that, I unfortunately can’t answer your question about the Web UI Rendering Mode. I simply didn’t use v1.7.0 long enough to test that feature.

1 Like
39

This update v1.7.0 caused a lot of damage to our servers in production.
All this for an aesthetic of the application store?
I too am waiting for emergency corrections or a downgrade to v1.6 which worked better.
If all the malfunctions generated by this new version cannot be corrected, I should go with another stable system. Other people here have made this same comment.

1 Like
40

I understand your frustration. I had a similar experience, which is why I rolled back to a stable version. I rely on my NAS every day, so stability is much more important to me than new features or UI changes.

I really hope IceWhale releases fixes soon because ZimaOS has a lot of potential. But for production systems, reliability has to come first.

2 Likes
41

Thank you for your suggestions. We are planning a brand-new DashBoard 2.0, which will fully support Dark Mode.

3 Likes