Bottom Line: ZimaOS Sharing Controls Access, but the Current UI Does Not Document a Fixed Per-Folder Capacity Quota
The requirement was simple: give each employee one private folder and cap it at 4 TB. ZimaOS account/share permissions can control who sees a folder, but current public documentation does not expose a native “this shared folder may only consume X TB” control. Access control and storage quota are separate features.
For Hard Quotas, Use an Application That Owns User Storage
Nextcloud is the cleanest fit for this exact multi-user requirement. Its current admin manual supports per-user quotas, including custom values such as 5 TB. See the Nextcloud user quota documentation.
The Nextcloud hardware guide helps size database/app storage separately from the employee file pool. The ZimaOS SMB permissions guide is better when you only need folder permissions.
The Slow Array Was Not a Quota Problem
The RAID was simply rebuilding. Even an empty RAID must resync blocks across the member disks, so low CPU use does not mean storage work is finished. The current ZimaOS RAID guide notes that parity/rebuild work can reduce storage performance while the array initializes.
Verify Rebuild State Before Benchmarking or Migrating Data
cat /proc/mdstat
sudo mdadm --detail /dev/md0The mdadm manual is the upstream reference for array status. Do not judge normal transfer speed until resync reaches 100%.
Recommended Employee Storage Layout
- Need only private folders: ZimaOS users + SMB permissions.
- Need per-user capacity caps: Nextcloud users + quotas.
- Need filesystem-level quotas: advanced Linux tooling, but do not assume ZimaOS UI manages or preserves that configuration across updates.
That keeps the quota mechanism at the layer that actually owns the user-account storage model.
