Hello,
I updated to 1.5.4 and created an encrypted folder in Files, copied large files and then had to find out that the transfer speed broke in 0.
Is this problem known?
Can anyone help?
Encrypted folders in 1.5.4 are still in testing, so performance issues under heavy write load are possible.
When transfer speed drops to 0, it’s usually one of three things:
- Encryption layer hitting CPU limits
- Underlying disk/RAID I/O blocking
- Files container stuck on a write operation
A few quick checks:
- Does CPU spike during the transfer?
- Are you writing to SSD or HDD/RAID?
- Does the same file copy normally to a non-encrypted folder?
If it works fine outside the encrypted folder, then it’s very likely related to the current encryption implementation in 1.5.4.
If reproducible, it’s worth reporting with logs so the IceWhale team can review, especially since this feature is still flagged as experimental.
Let us know your storage setup and we can narrow it down.
Hello, outside of the encrypted folder it works perfectly.
I write on 3.5" hdd.
CPU utilization increases to 10-15%.
Hardware: CPU Ryzen 5600g, am4 socket, msi Main board.
Thanks, that helps.
If:
- Outside encrypted folder > works perfectly
- CPU only 10–15% (Ryzen 5600G is more than enough)
- Writing to 3.5" HDD
Then this is very unlikely to be a CPU bottleneck.
What’s probably happening is write blocking at the encryption layer on top of the HDD. Large sequential writes to encrypted folders can stall if the underlying filesystem or encryption process waits on sync/flush operations.
A few quick checks:
- Is the HDD standalone or part of RAID (especially BTRFS RAID)?
- Does it freeze permanently, or resume after some time?
- What filesystem is the disk (ext4 / btrfs)?
Also check kernel messages right after it drops to 0:
dmesg | tail -n 50
If outside encrypted folders everything is stable, this strongly suggests an issue with the new encrypted folder implementation in 1.5.4 rather than your hardware.
Since this feature is still marked as testing, it would be good to report this with:
- Filesystem type
- RAID or single disk
- Output of dmesg
That gives the team something concrete to reproduce.
1.) 1x hdd dir the System 1 Tb
2 hdd on raid 0
-
Not to resume the world.
-
Must btrfs system
Where do I enter the command?
Thanks, BTRFS + RAID0 is important here.
If it never resumes and only happens inside the encrypted folder, this strongly points to a BTRFS + encryption interaction in 1.5.4.
To run the command:
- Open the ZimaOS Web UI
- Go to Terminal (left sidebar)
— or SSH into your ZimaOS box from another PC
Then run:
dmesg | tail -n 50
Press Enter.
Copy the output here.
We are specifically looking for:
- BTRFS errors
- I/O errors
- “blocked for more than 120 seconds” messages
- encryption related warnings
This will tell us whether the RAID layer is stalling or if the encrypted folder feature is hanging the write process.
Here’s the terminal log.
I hope it’s helpful.
[ 22.623552] loop2: detected capacity change from 0 to 2184
[ 22.708556] loop3: detected capacity change from 0 to 416
[ 22.709855] loop4: detected capacity change from 0 to 9184
[ 22.711589] loop5: detected capacity change from 0 to 2184
[ 22.779873] audit: type=1130 audit(1770540118.696:84): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=unconfined msg=‘unit=systemd-sysext comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
[ 29.661340] audit: type=1130 audit(1770540125.577:85): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=unconfined msg=‘unit=systemd-journal-flush comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
[ 29.893831] audit: type=1130 audit(1770540125.810:86): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=unconfined msg=‘unit=systemd-tmpfiles-setup comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
[ 29.896150] audit: type=1334 audit(1770540125.812:87): prog-id=8 op=LOAD
[ 29.969600] audit: type=1130 audit(1770540125.886:88): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=unconfined msg=‘unit=nfs-blkmap comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
[ 29.973023] audit: type=1130 audit(1770540125.889:89): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=unconfined msg=‘unit=nfsdcld comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
[ 30.058387] audit: type=1305 audit(1770540125.975:90): op=set audit_enabled=1 old=1 auid=4294967295 ses=4294967295 subj=unconfined res=1
[ 30.058394] audit: type=1300 audit(1770540125.975:90): arch=c000003e syscall=44 success=yes exit=60 a0=3 a1=7ffc813a2e20 a2=3c a3=0 items=0 ppid=734 pid=740 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=“auditd” exe=“/usr/sbin/auditd” subj=unconfined key=(null)
[ 30.058398] audit: type=1327 audit(1770540125.975:90): proctitle=“/sbin/auditd”
[ 30.885609] systemd-ssh-generator[886]: Binding SSH to AF_UNIX socket /run/ssh-unix-local/socket.
[ 30.885617] systemd-ssh-generator[886]: → connect via ‘ssh .host’ locally
[ 31.046684] Adding 9449080k swap on /DATA/.swapfile. Priority:-2 extents:11 across:298770432k
[ 31.112864] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 31.322251] Loaded X.509 cert ‘sforshee: 00b28ddf47aef9cea7’
[ 31.322357] Loaded X.509 cert ‘wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600’
[ 32.588244] md127: detected capacity change from 15627544576 to 0
[ 32.588249] md: md127 stopped.
[ 32.631570] md: md0 stopped.
[ 32.690294] md0: detected capacity change from 0 to 15627544576
[ 32.702493] BTRFS: device fsid ea8e33f9-2d50-99f2-c39b-0875c94e20f3 devid 1 transid 1029 /dev/md0 (9:0) scanned by zimaos-local-st (954)
[ 32.702757] BTRFS info (device md0): first mount of filesystem ea8e33f9-2d50-99f2-c39b-0875c94e20f3
[ 32.702766] BTRFS info (device md0): using crc32c (crc32c-intel) checksum algorithm
[ 32.702771] BTRFS info (device md0): using free-space-tree
[ 34.980238] Generic FE-GE Realtek PHY r8169-0-2a00:00: attached PHY driver (mii_bus:phy_addr=r8169-0-2a00:00, irq=MAC)
[ 35.139495] r8169 0000:2a:00.0 eth0: Link is Down
[ 35.367014] Loading iSCSI transport class v2.0-870.
[ 35.503926] r8169 0000:2a:00.0: invalid VPD tag 0xff (size 0) at offset 0; assume missing optional EEPROM
[ 37.662325] Rounding down aligned max_sectors from 4294967295 to 4294967288
[ 38.076812] r8169 0000:2a:00.0 eth0: Link is Up - 1Gbps/Full - flow control off
[ 42.764137] systemd-ssh-generator[1827]: Binding SSH to AF_UNIX socket /run/ssh-unix-local/socket.
[ 42.764142] systemd-ssh-generator[1827]: → connect via ‘ssh .host’ locally
[ 46.115733] systemd-ssh-generator[2067]: Binding SSH to AF_UNIX socket /run/ssh-unix-local/socket.
[ 46.115737] systemd-ssh-generator[2067]: → connect via ‘ssh .host’ locally
[ 46.123571] NFSD: Using nfsdcld client tracking operations.
[ 46.123574] NFSD: no clients to reclaim, skipping NFSv4 grace period (net f0000000)
[ 49.067348] loop6: detected capacity change from 0 to 416
[ 49.101883] loop7: detected capacity change from 0 to 2184
[ 49.144016] loop0: detected capacity change from 0 to 9184
[ 49.175636] loop0: detected capacity change from 0 to 416
[ 49.177130] loop1: detected capacity change from 0 to 2184
[ 49.178688] loop2: detected capacity change from 0 to 9184
[ 66.156403] Initializing XFRM netlink socket
[ 66.468315] systemd-journald[315]: Time jumped backwards, rotating.
[ 85.281746] tun: Universal TUN/TAP device driver, 1.6
[367061.666918] systemd-ssh-generator[4074938]: Binding SSH to AF_UNIX socket /run/ssh-unix-local/socket.
[367061.666922] systemd-ssh-generator[4074938]: → connect via ‘ssh .host’ locally
And here I’ve added another screenshot; this is how it stops and doesn’t continue.
Your dmesg output shows no BTRFS or RAID errors, the array is healthy.
Since:
• Transfers work normally outside encrypted folders
• CPU is not saturated
• No kernel I/O errors appear
• RAID0 is stable
This strongly points to the encrypted folder feature itself hanging the write process in 1.5.4.
It does not look like a hardware or RAID issue.
Given that encrypted folders are still marked as testing, this may be a bug, especially on BTRFS RAID.
I would recommend reporting this to the IceWhale team with:
- ZimaOS version (1.5.4)
- BTRFS RAID0
- Reproducible stall during large file copy
This should be reproducible on their side.
What do I need to add?
And what address do I have to send it to?
Just reply in this forum thread and include the following details so the IceWhale team can reproduce it:
Please add:
• ZimaOS version: 1.5.4
• Storage layout: 1x system HDD (1TB) + 2x HDD in RAID0 (BTRFS)
• Encrypted folder created in Files
• Large file copy starts normally, then drops to 0 MB/s and never resumes
• Works perfectly outside encrypted folder
• CPU only 10–15%
• No BTRFS or I/O errors in dmesg
That’s enough technical context for them.
If you want to escalate it formally, you can email:
But normally posting full details in the forum thread is sufficient, the team monitors it.
This looks reproducible, which is the important part.