Some vendor Docker installers assume they can create application directories directly under the Linux root filesystem. That conflicts with ZimaOS's appliance-style design when an installer insists on a host path such as /app.
This January 2026 thread eventually reached a better solution than making the ZimaOS root filesystem writable: configure ONLYOFFICE Workspace to use persistent storage under /media and explicitly select the Community installation type.
Do Not Make the ZimaOS Root Writable Just to Satisfy an Installer
The original deployment consisted of multiple containers for database, search, documents, mail, communications, and management services. The vendor installer expected /app, while the user wanted the real data stored on a large ZimaOS data drive.
The community correctly steered the discussion away from permanently modifying the ZimaOS base filesystem. Appliance OS updates can replace or invalidate unsupported changes under the root filesystem.
The Vendor Installer Had a Configurable Base Directory
After the installer scripts were inspected, the user learned that the storage location was not actually hard-coded. The base directory could be changed from the default root-level path to a persistent location under the ZimaOS data drive.
That is a safer architecture because containers and application data remain on writable storage while the ZimaOS system image stays managed by the operating system.
Explicitly Select the Community Installation Type
The user later reported a second issue: after changing the base directory, the installer could fall back to the Enterprise edition. After working with the software supplier, they confirmed that the Community deployment needed the appropriate installation-type selection.
Current ONLYOFFICE instructions still expose separate Community and Enterprise installation types. Before changing an old downloaded script, confirm which script parameters select Workspace Community in the current installer.
Use the Current ONLYOFFICE Script, Not the Historical Forum Filename
The 2026 forum reply referenced an older installer filename. Current ONLYOFFICE Workspace instructions now publish workspace-install.sh for Docker deployments and document the supported parameters separately.
The current upstream process and system requirements are described in the maintained Workspace Community Docker installation flow.
Docker Compose Remains a More Transparent Alternative
The community discussion also considered deploying the stack from Compose instead of relying on a large installer script. That approach makes image editions, volume paths, networks, and persistent storage easier to review before deployment.
If you import a multi-container stack into current ZimaOS, standard runtime settings belong in Docker Compose. The current explanation of how ZimaOS handles Docker Compose configuration helps keep vendor storage paths separate from ZimaOS app metadata.
ONLYOFFICE on ZimaOS FAQ
Do I need to make the ZimaOS root filesystem writable?
No solution in the final thread required that. The better approach was to put the vendor's base directory on writable persistent storage.
Was /app truly mandatory?
The user's supplier ultimately confirmed that the installer base directory could be changed, so the host did not need to store the application under the root-level /app path.
Why did the wrong edition appear?
The user found that changing the base directory exposed an installer behavior that defaulted to Enterprise. They reported that explicitly selecting the Community installation type solved that part.
Should I copy the 2026 forum commands exactly?
No. ONLYOFFICE's current installer filename and parameters should be checked against its maintained instructions before deployment.
