Why the Nextcloud built-in CODE server fails and how to isolate the cause
When documents will not open, the fastest way to isolate the cause is to decide whether the built-in CODE app is failing to start on the Nextcloud host, or starting but failing to connect from the browser or from Nextcloud. Those two states point to different checks, and treating them as one problem wastes time. The built-in server is a convenience component inside Nextcloud Office, built on Collabora Online. It is meant for evaluation, home use or small teams, and Collabora describes its free CODE edition as not recommended for production. CODE is also a rolling release, published on average once a month, so a server that worked after one update can behave differently after the next. Teams should expect to outgrow the built-in option when user numbers, uptime expectations or change control rise, at which point a dedicated Collabora Online server becomes the better fit.
This page covers four failure families. The first is hostname reachability, where the CODE process runs but the browser, Nextcloud or a proxy cannot reach the address it was given. The second is FUSE and AppImage execution problems, where the host lacks the kernel or user-space support that the packaged server needs to run. The third is slow first start, where the server appears broken because it is still preparing its components. The fourth is the decision to move to a dedicated server, which depends on the scale and support needs your organization has, not only on whether the app runs. Before changing anything, record the Nextcloud version, the Office app version and the Collabora version reported in the admin settings, and confirm which of these you actually control, because the fix for an out-of-date app differs from the fix for a network path.
Which symptom points to which cause
When the app is enabled but the editing server never starts, the failure usually happens on the host before Nextcloud can reach anything. The built-in server depends on platform features that a hardened or containerized host may not provide, so check the environment first and move to Nextcloud settings only after that.
- FUSE support: Confirm that the host kernel and any container runtime allow FUSE mounts. AppImage packaging commonly relies on it, so a host without it can fail at launch.
- AppImage execution: Confirm that the packaged server file is executable by the account that runs Nextcloud and that the host has the libraries it expects. Permission denied and missing library messages point here.
- Container privileges: If Nextcloud runs in a container, check the device and capability settings the orchestrator grants, because a default restricted container often blocks the mount.
- Nextcloud log entry: Open the logging section of the Nextcloud administration settings and read the entries from the failed enable or start. They record the app's own error message.
Check the FUSE and AppImage conditions on the host, then match the logged error to one of them before you change any Nextcloud setting.
When the editor opens but reports a connection error, the browser, Nextcloud and the editing server do not agree on where the server is or how to reach it. Hostname reachability and protocol mismatch cause most of these cases, and both are set in the Office section of Nextcloud's administration settings.
- Hostname reachability: The browser must load the server URL that Nextcloud is configured with, and the Nextcloud server must reach that same address for WOPI callbacks. A name that resolves only on an internal network breaks one side or the other.
- Protocol mismatch: The Nextcloud Office configuration guidance recommends that the editing server URL use the same protocol as Nextcloud, preferably HTTPS. A mixed HTTP and HTTPS setup can fail even when both services are healthy.
- Certificate trust: If the address uses a certificate that the Nextcloud host does not trust, server-side requests fail while the browser may still load the page. Test the address from the Nextcloud host, not only from a workstation.
- Allow list after a change: If the server address or the Nextcloud host's IP address changed, the WOPI allow list may no longer include the caller. Check it after any network move.
Compare the configured server URL with the address the browser loads, then test that address from the Nextcloud host before changing anything else.
A first document open that takes much longer than later opens usually points to start-up work and shared resource pressure. The document eventually loads, so the connection is working, and the investigation should focus on performance during the first open.
- Start-up work after restart: The first open after enabling the app or restarting the host can be slow while the editing engine initializes. Repeat opens in the same session should be faster, so time two consecutive opens.
- Shared CPU and memory: The built-in server shares the host with Nextcloud, the web server and the database. Watch host CPU and memory during the slow open, and confirm the minimum resources for your version with the vendor.
- Storage latency: Documents are read from storage on each open. Slow disks under the Nextcloud data directory lengthen the wait, so measure read latency on that volume.
- Reference sizing: The Collabora Online Helm chart README recommends 8 CPU cores and 8000 MiB of memory per pod for production, with requests of 4 cores and 6000 MiB. Those figures apply to dedicated pods, so use them as a reference for sizing a dedicated server, not as a minimum for the built-in app.
Time two consecutive opens, then compare host CPU, memory and storage latency during the slow one before deciding that the app needs more capacity.
When only some users see a failing document, the server is usually healthy and the difference lies in the user's group membership, session, network path or the file itself. Start with group restrictions, because Nextcloud Office can limit which groups may use the editor and which may edit or only view.
- Group restrictions: Check the group settings in Nextcloud Office and confirm the affected user's group membership. A user who is excluded from the editor will see a failure that looks like a server fault.
- Stale session or cache: A user added to a group after signing in may keep an older session. Ask them to sign out, sign back in and clear the cache for the Nextcloud address before a wider investigation.
- Network path: Users on a VPN, a proxy or a different network may resolve the server name differently. Compare the address each affected browser loads with the address in the Nextcloud settings.
- File or share type: Files shared through external storage or stored under unusual permissions can open differently for recipients. Test the same file as an administrator and as the affected user.
Filter the Nextcloud log by the affected user's account and compare their group membership, session and network path with a working user before changing server configuration.
How to check hostname reachability from Nextcloud and the browser
This sequence confirms which Collabora server URL Nextcloud is configured to use, then proves that both the Nextcloud host and a user's browser can reach that address over the expected port and protocol. It ends with a matched configuration that the built-in CODE app can rely on.
Record the configured Collabora server URL
A Nextcloud administrator opens the Office settings in the Nextcloud admin area and copies the Collabora Online server URL exactly as entered, including the scheme, hostname, port and any path. Write it down before changing anything, because every later check compares against this value. Done means you have one written URL and you know whether the built-in CODE app or an external server is handling it. If the field is empty or points to a different host than you expect, record that as a failure and resolve it before continuing.
Confirm the URL uses the same protocol as Nextcloud
Compare the scheme of the Collabora URL with the scheme of your Nextcloud instance address. The Nextcloud administration manual recommends the same protocol for both, preferably HTTPS, so an HTTP Nextcloud paired with an HTTPS Collabora URL, or the reverse, is a configuration mismatch to correct. Pass means both URLs use HTTPS (or both use HTTP only in a deliberately isolated test network). Fail means the schemes differ, and you should align them in the Nextcloud settings and the reverse proxy before testing connectivity.
Resolve the hostname from the Nextcloud server
Log in to the Nextcloud host, or the container or pod that runs Nextcloud, and resolve the Collabora hostname with a tool such as
nslookuporgetent hosts. Run the lookup from inside the same runtime that PHP uses, since container networks often resolve names differently from the host. Pass means the name returns the IP address you expect, which is the address of the server running the built-in CODE app or the reverse proxy in front of it. Fail means no answer, a stale address, or a private address that does not match your DNS records, and you should fix DNS or host entries before moving on.Test the port and TLS from the Nextcloud server
From the same Nextcloud runtime, open a connection to the Collabora host and port with a tool such as
curl -vagainst the discovery path of the URL. A successful TCP connection followed by a valid TLS handshake, and an HTTP response from the discovery endpoint, is a pass. Connection refused or timeouts point to a firewall, a stopped service, or the wrong port. Certificate errors point to a certificate that does not match the hostname or to a missing internal CA in the Nextcloud trust store, which you should confirm with your certificate owner before changing the trust configuration.Resolve and reach the URL from a user's browser
From a workstation on the network where users work, open a browser to the same Collabora URL and load the discovery endpoint in a new tab. Repeat from a network segment that users reach through VPN or remote access if your organization uses one. Pass means the discovery document loads without a certificate warning. Fail means the name does not resolve on that network, the request is blocked, or a split-DNS record gives the browser a different address than the server received. Browsers must reach the hostname directly for document windows to load, so this check is required even when the server test passed.
Compare the admin settings with the tested URL
Return to the Nextcloud Office settings and confirm that the URL is identical to the one you tested from the server and the browser, with the same scheme, hostname, port and path. Check for trailing spaces, a missing port, or a path that the discovery endpoint does not use. If you changed anything, save the settings and repeat the browser test in a fresh session to avoid cached results. Pass means every tested address matches the saved configuration. Fail means at least one value differs, and the next step is to correct the saved value and retest.
Document the verified endpoint and recheck after changes
Save the verified URL, the resolved IP address, the port, the protocol and the date of the check in your operations record, along with the names of the Nextcloud and CODE hosts. Repeat this sequence after DNS changes, certificate renewals, firewall updates, Nextcloud upgrades, or moving the built-in CODE app to a new host. If the checks keep failing across networks or the single host cannot support the expected load, confirm with your team whether a dedicated Collabora Online server is the better fit, since that decision depends on your own sizing and support requirements.
FUSE and AppImage issues that stop the built-in server starting
The built-in CODE server ships as an AppImage-style binary that needs a working FUSE layer, executable permissions and a host that can run it. When it fails to start, the cause is usually one of the host or runtime conditions below, and each leaves a different trace in the logs. Work through these checks in order before changing Nextcloud settings.
Missing FUSE support on the host
The AppImage format mounts its contents through FUSE, so a host or container without FUSE support cannot launch the server. Look for mount or fusermount errors in the Nextcloud log and the process start output, then confirm that the FUSE kernel module is loaded and that the fusermount or fusermount3 binary is installed. In containers, check whether the runtime exposes /dev/fuse and grants the capabilities FUSE needs. Confirm the exact requirements with the current documentation for the Built-in CODE Server app, since they can change between releases.
AppImage execution restrictions
Some hardened distributions and security policies block executing binaries from user-writable paths, or require a specific mount option such as noexec to be absent. The symptom is usually a permission denied error on the bundled binary even though the file exists and the web server user can read it. Check the mount options on the app data directory with findmnt and confirm the binary carries the execute bit for the user that runs Nextcloud. Verify the supported execution model with the app's documentation before changing mount options.
Permissions on the app data directory
The app needs to write its runtime files, sockets and temporary data under the Nextcloud data and app directories. When the web server user does not own those paths, the server fails early with errors about creating files or directories. Compare ownership and mode on the app directory with the user that runs PHP-FPM or Apache, and check that the path is not on a volume mounted read-only. Fix ownership with the Nextcloud occ tooling or your standard file ownership process rather than widening permissions on the whole tree.
Missing shared libraries
The bundled server depends on system libraries that minimal base images often omit. A missing library shows up as a loader error that names a .so file, and the server exits before it opens its listening port. Run ldd against the extracted binary to list unresolved dependencies, then install the matching packages from your distribution. Because library names and versions differ across distributions, confirm the package list against the current app documentation and test on the same base image you deploy to.
SELinux or AppArmor denials
Mandatory access control can stop the server without any error in the application log. The denial appears in the kernel audit log, typically as an AVC message for SELinux or a DENIED line for AppArmor, and the process fails to create sockets, map memory or execute a helper. Check ausearch or journalctl for the denial, and only then decide whether to adjust the policy for the Nextcloud web server context. Keep any policy change narrow and record it in your change log so security teams can review it.
Kernel and distribution differences
The same app image can behave differently on an older kernel, a distribution with a different default FUSE version, or an architecture that is not covered by the build. Record the kernel version, distribution release, CPU architecture and container runtime version for every environment, then compare a working host with the failing one. Differences that matter most are FUSE version, user namespace support and seccomp profiles. Confirm which platforms the app supports with its current documentation before you commit to a host image.
Why the first start is slow and what counts as normal
A slow first start is usually normal on a freshly configured built-in CODE server, but a server that never becomes ready is not. The first document open after the app starts has to launch the Collabora Online process pool, load the LibreOffice-based rendering components, and build caches for fonts and document templates. Later opens reuse those warm components, so the gap between first and subsequent opens is expected. Initialization of the font cache is a common reason the first render takes longer, particularly where the host has many fonts installed or where fonts are read from a slow disk. Ask Collabora or your Nextcloud Office documentation which startup steps are expected for the version you run, since the built-in app bundles its own server build.
Resource contention on small hosts is the other common cause. The built-in server runs on the same machine as Nextcloud, PHP-FPM, the database and any caching layer, so a first start can compete with those services for CPU and memory. Watch the load average, memory pressure and swap use on the host during the first open, and compare them with a second open a few minutes later. If the second open is fast and resource use returns to baseline, the start was slow but healthy. Look in the Nextcloud log and the Collabora Online log for steps that advance over time, such as a progressing sequence of load messages, rather than a single error that repeats without change.
Treat a start as stuck when it produces no progress for an extended period, when the log repeats the same error, or when CPU and memory stay flat while the editor never loads. Repeated failures usually point back to hostname reachability, the WOPI allow list or FUSE and AppImage problems covered elsewhere on this page. If the delay persists after you rule out host contention and configuration faults, collect the Nextcloud version, the Nextcloud Office app version, the host specifications and the log excerpts, then ask the vendor which startup timings are expected for that build and document size. Do not assume a fixed number from a forum post, because startup time depends on hardware, storage and font set.
Built-in CODE server or dedicated Collabora Online server
This table compares the Built-in CODE Server app inside Nextcloud with a dedicated Collabora Online server across the factors that affect troubleshooting, updates and production readiness. Read each row against your own risk tolerance and staffing, and use the main takeaway as a starting point: the built-in option suits testing and small teams, while production use usually calls for a dedicated, supported deployment.
| Factor | Built-in CODE server app | Dedicated Collabora Online server |
|---|---|---|
| Where it runs | On the same host or container as Nextcloud, started by the app | On separate servers or containers that you deploy and place on your network |
| Who maintains it | The CODE edition is maintained by Collabora as a free rolling build | Collabora Online is maintained by Collabora; Business and Enterprise plans add support and security updates |
| Update cadence | CODE is released on average once a month as a rolling release | Branch-based releases with point releases, such as the 25.04 and 26.04 branches |
| Suitability for production | CODE is not recommended for production according to Collabora | Business and Enterprise plans are positioned for production use with support |
| Resource isolation | Shares CPU, memory and disk with Nextcloud, so load on one can slow the other | Runs on its own resources, which you size for expected concurrency |
| Troubleshooting access | Logs and processes are tied to the Nextcloud host, which limits direct access to the Collabora side | Full access to coolwsd logs, configuration and processes on its own host |
| Operational control | Limited control over the bundled version and startup behavior; confirm current app behavior with your Nextcloud version | You choose the version, the hostname, the reverse proxy and the update window |
| When it fits | Evaluation, home use or a small team with low concurrency and no uptime commitment | Multi-user production, regulated environments or any setup that needs a support path |
How to move from the built-in server to a dedicated Collabora server
This sequence moves document editing from the Nextcloud built-in CODE app to a separate Collabora Online server you run, with the WOPI settings, Office configuration and group permissions verified at each stage before the built-in app is switched off.
Size and place the dedicated server
Decide where the Collabora Online server will run and how many users it must serve, then confirm that Nextcloud can reach it over the protocol you intend to use. Work with your platform team to agree the host, the public hostname and the network path between the two servers. The reference Helm chart lists production resource limits per pod, but the figures for a non-Kubernetes host must come from Collabora's documentation and your own load testing. This step is done when you have a written hostname, a sizing note and a firewall request approved for the path from Nextcloud to the new server.
Install Collabora Online on the new host
Install Collabora Online using the method your team supports, such as Docker images or system packages, and start the service with TLS configured for the public hostname. Confirm the version you install against the release notes for the branch you choose, and check that the server answers on its discovery endpoint from a machine outside the host. Test the discovery page directly in a browser before involving Nextcloud, because a failure here is easier to diagnose in isolation. This step is done when the discovery page loads over HTTPS and shows the expected version.
Configure the WOPI allow list and protocol
Restrict WOPI requests so that the dedicated server accepts only the Nextcloud addresses you control, and make the Collabora server URL use the same protocol as Nextcloud, preferably HTTPS. Record the Nextcloud egress address or addresses before you change the allow list, since a mismatch here is a common cause of refused requests. Confirm that the reverse proxy passes WebSocket connections through to the server. This step is done when a request from the Nextcloud host to the Collabora discovery endpoint succeeds and the allow list contains only the addresses you recorded.
Point Nextcloud Office at the new URL
In the Nextcloud administration settings for Nextcloud Office, choose the option to use your own Collabora Online server and enter the URL of the new server. Make sure the protocol and hostname match what you configured in the previous step. Keep the built-in CODE app enabled at this point so you can fall back if the test fails. This step is done when the Office settings page shows the new server as the active connection and no error appears after you save.
Set group permissions for editing and use
In the same Nextcloud Office settings, limit which groups can use the editor and which groups can edit rather than only view. Map these to the groups your organization already uses, and confirm the membership of each group with the people who manage directory access. Document the decision so the audit trail shows who was allowed to edit before and after the change. This step is done when the group settings match the approved access list and a test account in each group sees the behavior you expect.
Test with a document from each user group
Ask one test user from each group to open a document in the new server, make a visible edit, save it and reopen it in a separate session. Include a sample file in each format your users rely on, such as docx, xlsx and pptx, and check that the document loads, edits and saves without an error. Note any fonts or layout differences for later review. This step is done when every group completes the test on every sample format and the results are recorded with the file names and the versions tested.
Disable the built-in CODE app
Once every group has passed testing, disable the built-in CODE Server app in Nextcloud so that new sessions can only use the dedicated server. Keep the app installed for a short period so you can re-enable it if a regression appears, and watch the Nextcloud and Collabora logs for connection errors over the first days. Remove the app only after your team agrees the new server is stable. This step is done when the built-in app shows as disabled, a new document opens through the dedicated server, and the logs show no new connection errors.
Security points to keep in view while troubleshooting
Troubleshooting the built-in CODE server tempts teams to open ports, relax protocols and collect everything in one pass. Each of the points below is a control that should survive the fix, and each one gives you a check to run before you close the ticket.
Restrict WOPI requests to known addresses
The Nextcloud administration manual recommends limiting WOPI requests to the IP addresses of the Collabora servers. When a built-in server fails to connect, the request may come from a different address than the one you allowed, so the fix is to confirm the source address the server actually uses and add that address deliberately. Check the allow list after every network change, and remove entries that no longer match a running server.
Match protocol and TLS
The Nextcloud administration manual recommends using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. Mixed HTTP and HTTPS settings are a common cause of connection failures that look like network faults. Confirm the configured URL, the scheme the browser uses and the certificate chain the browser trusts before changing any firewall rule.
Keep the app on a supported release
The built-in app runs inside a Nextcloud release that has a defined support window. Nextcloud supports each major version for one year through monthly maintenance releases, so an unsupported server version can leave you without fixes for the components that handle documents. Check the Nextcloud version and the app version together, and plan any upgrade one major version at a time with a backup taken first.
Avoid ad hoc firewall openings
Opening a port or allowing a broad address range to see whether a fault clears leaves an exposure that outlasts the test. Each opening should trace to a documented flow between Nextcloud and the Collabora process, with a named owner and a removal step. Record the rule, the reason and the date, then remove temporary rules as soon as the diagnosis is complete.
Collect logs without document content
Logs from both Nextcloud and the Collabora process help isolate connection and startup faults, but they can capture file names, paths and snippets of content if verbosity is high. Share only the lines that show the error, the timestamp, the host and the status code. Strip document identifiers before sharing logs outside your team, and raise log levels only for the window you are testing.
Track advisories and patch promptly
Collabora publishes security advisories for Collabora Online. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623, and that package signing keys were updated for RPM and DEB users. When a fault turns out to be a known defect, check whether a fixed point release exists before changing configuration, and confirm that your signing keys are current.
Questions teams ask before fixing or replacing the built-in server
What does fixing the built-in CODE server cost in effort?
Effort depends on which fault you are chasing, not on the app itself. A hostname that does not resolve or a firewall rule is usually a short change. A FUSE or AppImage problem on a host with unusual kernel or container settings can take longer, because each fix needs a restart and a retest. The cost components are internal staff time for logs and configuration, any change windows on the Nextcloud host, and, if you engage a partner, the fixed-scope work agreed in writing. Nothing here is recurring unless you move to a supported server. Ask any quote to list the expected test cases, the environments covered and whether retesting after a fix is included.
How long does diagnosis usually take, and what changes it?
Diagnosis time is set by how quickly you can reproduce the failure and by how much access you have to both sides of the connection. A clear error in the Nextcloud log and a reachable hostname usually narrows the cause fast. Slow cases involve intermittent first starts, mismatched protocols between Nextcloud and the server, or logs that live on a host nobody on the team can read. The Nextcloud administration manual covers the Nextcloud Office configuration you should check first, including the recommendation to use the same protocol for the server URL as for Nextcloud, preferably HTTPS. Ask for a diagnosis estimate that depends on access and reproduction steps, not a fixed duration.
What must our team provide before troubleshooting starts?
Troubleshooting moves fastest when the team provides four things in advance:
- Nextcloud version, the Nextcloud Office app version and the hostname and URL configured for the server
- Access to the Nextcloud and server logs for a failing session, with a timestamp
- Network details: DNS records, proxy or firewall rules between users and the server, and any outbound restrictions
- A small test document set in docx, xlsx and pptx, plus one OpenDocument file, so fidelity and open errors can be checked
Also confirm who may change production configuration and when. Keep test documents free of personal data unless your data handling rules allow them in test environments.
Can our internal staff fix the built-in server without outside help?
Yes, if they have Linux administration skills, access to the Nextcloud host and the authority to change DNS, firewall and reverse proxy settings. Many connection and hostname faults are solvable in-house by working through the Nextcloud log and the Nextcloud administration manual. Outside help becomes more useful when the failure involves the kernel, container runtime or AppImage execution, or when the same fault recurs after each fix. The decision depends on your team's capacity and on whether the people who can change the host are available during the window you need.
When does a partner add value to this kind of troubleshooting?
A partner adds the most value when the fault crosses several teams, such as Nextcloud administration, network, identity and the document server, or when the same symptom returns after every fix. A partner can also document the reproduction steps, test the fix against your sample documents and write the runbook your staff will use next time. Ask for the scope in writing before work starts, including which logs are reviewed, which environments are tested and what the deliverable is. DeployOpen implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the work stays in your environment.
What does a dedicated Collabora server change about cost and support?
A dedicated server moves the document editing service out of the Nextcloud host, which typically changes sizing, patching and who owns support. You take on a separate host, its own updates and its own monitoring, so the ongoing cost is infrastructure and staff time that recur. Commercial support is a separate decision. Collabora's pricing page lists the Business plan at 3 euros per user per month for up to 99 users, which includes long term support, a service level agreement, signed security updates and customer portal access, according to that pricing page. Collabora's free CODE edition is rolling and Collabora says it is not recommended for production. Confirm current terms directly with Collabora before you budget.
Should we replace the built-in server or keep fixing it?
Keep fixing it when the failure is a configuration issue you can reproduce and close, and when the Nextcloud host can carry the editing load for your user numbers. Plan a dedicated server when you need support terms your procurement team can sign, when the built-in app blocks upgrades you need, or when repeated faults make the built-in app a recurring cost. The Nextcloud release schedule is also relevant: Nextcloud publishes major versions every four months and supports each for one year, so your Nextcloud upgrade plan should be checked against any server change.
How DeployOpen scopes a built-in server fix or migration
A fixed-scope engagement for the Built-in CODE Server app starts with a review of the Nextcloud installation and the host it runs on, before anyone changes a setting. The review covers the Nextcloud version and its release status, the PHP and web server stack, the reverse proxy in front of Nextcloud, the hostname and DNS records that the Collabora server URL depends on, and the app's own logs and the Nextcloud log. It also records whether the host allows the FUSE and AppImage components the bundled server needs, and whether the server is in a container, a virtual machine or a bare metal host. Operators often find that the symptom sits in a different layer from the one they first suspected, so this inventory is what keeps the rest of the work short.
Next, the failure is reproduced on a copy or a maintenance window, not only described from memory. Reproduction establishes which step fails: the app does not start, the server starts but cannot be reached at the configured hostname, or the first document open takes long enough to look like a failure. Each outcome points to a different fix and a different cost. The output is a short written finding that names the root cause or the open questions, and it is shared with the client before any build or configuration work is scoped. The client then decides with DeployOpen whether to repair the built-in server or to move to a dedicated Collabora Online server, which changes the deliverables, the change window and the operations the client will own afterward. Scope, deliverables and timelines are agreed in writing before work starts, and ongoing support can be added as a retainer if the client wants help with upgrades or monitoring after handover.
How DeployOpen works on this
DeployOpen approaches troubleshooting the built-in CODE server as a bounded piece of work inside your own Nextcloud environment, starting from the symptoms your users and logs show. We agree the scope in writing, make changes in your infrastructure, and hand over what was checked and what should change next.
How we scope
- We confirm your Nextcloud version, hosting model, and whether the built-in CODE app is the only Collabora path in use.
- We collect the exact error text, the hostname Nextcloud uses for the Collabora URL, and access to server and Nextcloud logs.
- Engagements are fixed-scope, so the written scope states which symptoms are covered and which decisions, such as a dedicated server, are excluded.
How we build
- We check hostname resolution and reachability from the Nextcloud server and from client networks before changing any app settings.
- We verify the runtime prerequisites for the built-in server on your host, including how FUSE and AppImage execution are handled in your environment.
- We test each fix on a sample document in a staging copy where possible, then repeat the test on production with recorded results.
How we hand over
- We document the root cause for each issue, the change made, the configuration values involved, and the test used to confirm the fix.
- We record a short runbook for restarts, first-start expectations and the log locations your team should check first.
- We set out, in writing, the conditions under which we recommend moving from the built-in server to a dedicated Collabora Online server, and what that move would require.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the initial fixes are in place.
- Retainer coverage is agreed in writing, so you can confirm response expectations and included upgrade work before signing.
- We can review Nextcloud and Collabora Online release notes with your team when a new version changes behavior you depend on.
