Je opent een DOCX-bestand in Nextcloud, ONLYOFFICE laadt normaal, je brengt een wijziging aan en vervolgens meldt de editor: "Document kon niet worden opgeslagen." De voor de hand liggende conclusie is dat de browser het bestand kwijt is geraakt of dat ONLYOFFICE zelf niet naar de schijf kan schrijven. Bij een Nextcloud-integratie is dat echter vaak niet het juiste startpunt.
Het belangrijkste detail is hoe het opslaan werkt. Nextcloud geeft ONLYOFFICE Docs een document-URL en een retourpad callbackUrl. ONLYOFFICE downloadt het bestand, host de bewerkingssessie en roept later Nextcloud terug, zodat Nextcloud het bijgewerkte bestand kan ophalen en de opgeslagen versie kan vervangen. De officiële ONLYOFFICE-integratiedocumentatie beschrijft deze callback-uitwisseling expliciet. Dat betekent dat de editor succesvol kan openen, terwijl het retourpad dat wordt gebruikt voor het opslaan niet werkt. Actie: behandel het openen en opslaan als twee afzonderlijke netwerktests.
Volgens de huidige officiële integratiedocumentatie maakt de Nextcloud-connector van ONLYOFFICE gebruik van een server-naar-server-workflow: de documentserver moet bereikbaar zijn vanuit Nextcloud, en Nextcloud moet ook bereikbaar zijn vanuit de documentserver. Wanneer het bewerken is voltooid, stuurt ONLYOFFICE een POST-verzoek naar de callback-URL; Nextcloud downloadt vervolgens het bewerkte document en vervangt de vorige versie. Zie de officiële ONLYOFFICE Nextcloud-integratiehandleiding en de ONLYOFFICE API-beschrijving van de Nextcloud-integratie .
Geverifieerd: een onjuist of onbereikbaar callbackpad kan een opslagfout veroorzaken, zelfs wanneer de editor geopend is. De documentatie voor probleemoplossing van ONLYOFFICE adviseert beheerders specifiek om de DocService-logboeken te controleren en te verifiëren of de callback-URL bereikbaar is wanneer er een opslagfout optreedt. Actie: begin niet met het opnieuw installeren van de editor of het wissen van de browsercache; test eerst het server-naar-serverpad.
Voer op de Nextcloud-host de ONLYOFFICE-connectorcontrole uit als de webservergebruiker. Op een typische Debian- of Ubuntu-installatie:
cd /var/www/nextcloud
sudo -E -u www-data php occ onlyoffice:documentserver --checkHet exacte Nextcloud-pad en de HTTP-gebruiker kunnen verschillen per distributie of containerconfiguratie. De beheerdershandleiding van Nextcloud zelf raadt aan om occals HTTP-gebruiker te werken, zodat het eigenaarschap van bestanden consistent blijft. ONLYOFFICE documenteert dit occ onlyoffice:documentserver --checkals de verbindingstest voor de connector.
Wat dit bewijst: het kan een duidelijke configuratie- of verbindingsfout in de documentenserver aan het licht brengen. Wat het niet bewijst: elke callback die tijdens een echte bewerkingssessie wordt gegenereerd, zal succesvol zijn via elke proxy, DNS-route en authenticatielaag. Actie: als de controle slaagt maar het opslaan nog steeds mislukt, ga dan verder naar de callback en de logboeken in plaats van de integratie als gezond te verklaren.
Open in Nextcloud Instellingen → Beheer → ONLYOFFICE . Het hoofdadres van ONLYOFFICE Docs moet bruikbaar zijn voor de relevante clients en services. Als de openbare URL's intern niet bereikbaar zijn vanwege Docker-netwerken, NAT, split-horizon DNS of firewallbeleid, vouw dan de geavanceerde serverinstellingen uit.
De officiële connector biedt aparte interne adressen voor precies deze situatie:
Twee containers op hetzelfde Compose-netwerk kunnen bijvoorbeeld intern servicenamen gebruiken, terwijl browsers nog steeds openbare HTTPS-hostnamen gebruiken. Kopieer dit patroon niet blindelings: de namen moeten daadwerkelijk in uw netwerk worden opgelost. Actie: test beide richtingen vanaf de machine of container die het verzoek initieert.
Die conclusie is niet betrouwbaar. De browser, Nextcloud en ONLYOFFICE Docs zijn drie verschillende netwerkdeelnemers. De browser kan wel verbinding maken met office.example.comde Document Server, terwijl de container die verbinding niet kan maken cloud.example.com. Evenzo kan Nextcloud ONLYOFFICE bereiken via een interne hostnaam, terwijl de callback verwijst naar een onbereikbaar publiek adres.
Actie: ga naar de ONLYOFFICE-container of -host en test het Nextcloud-adres dat deze naar verwachting zal gebruiken. Een standaard HTTPS-verzoek aan de Nextcloud-host kan de DNS/TCP/TLS-bereikbaarheid bevestigen, maar onthoud dat een succesvol status.phpverzoek de daadwerkelijke callback-autorisatie of POST-afhandeling niet valideert.
JWT is een andere veelvoorkomende bron van verwarring. Vanaf ONLYOFFICE Docs 7.2 is JWT standaard ingeschakeld en wordt er automatisch een geheime sleutel gegenereerd. De officiële instructies vereisen dezelfde geheime sleutel op de documentserver en in de Nextcloud ONLYOFFICE-connector. De huidige connectordocumentatie beschrijft ook de instelling voor de autorisatieheader voor installaties die de standaardheader niet gebruiken.
Geverifieerd: het gedeelde geheim moet overeenkomen. Implementatieafhankelijk: de exacte locatie waar u dit beheert, hangt af van of ONLYOFFICE is geïnstalleerd vanuit pakketten, op Windows of in Docker. Bij Docker-implementaties JWT_SECRETwordt meestal een omgevingsvariabele gebruikt; de daadwerkelijke serverconfiguratie kan ook worden gecontroleerd in /etc/onlyoffice/documentserver/local.json.
Actie: vergelijk de effectieve geheime en header-instellingen aan beide zijden en herstart vervolgens de ONLYOFFICE-services of de container na de wijzigingen aan de serverzijde. Los het probleem niet op door JWT permanent uit te schakelen; dat verwijdert een beveiligingsmaatregel in plaats van de configuratie te corrigeren. Meer informatie vindt u in de JWT-configuratiehandleiding van ONLYOFFICE .
ONLYOFFICE raadt aan om de DocService-logboeken te controleren op opslagfouten. Voor Linux- en Docker-installaties bevinden de Document Server-logboeken zich in de map /var/log/onlyoffice/documentserver; Docker-gebruikers kunnen de uitvoer van de container ook volgen met docker logs -f <container>. Als meer details nodig zijn, beschrijft ONLYOFFICE een tijdelijke debugmodus via DS_LOG_LEVEL=DEBUGof de log4js-configuratie. Zie de officiële handleiding voor debuglogboekregistratie .
Op Nextcloud bevindt het standaard logbestand zich normaal gesproken nextcloud.login de geconfigureerde data-directory. Je kunt het actieve pad vinden met:
sudo -E -u www-data php occ log:fileNextcloud documenteert ook log:tailwanneer log:watchde Log Reader-app beschikbaar is. Actie: reproduceer een mislukte opslagpoging, noteer het tijdstempel en vergelijk vervolgens beide kanten. Een netwerkweigering, TLS-fout, 401/403-respons, 5xx-respons of opslaguitzondering wijst op zeer verschillende oplossingen.
Een zelfondertekend of privé uitgegeven certificaat kan HTTPS-verbindingen tussen servers verbreken als de bijbehorende certificeringsinstantie (CA) niet wordt vertrouwd. De connector heeft een optie 'Certificaatverificatie uitschakelen (onveilig)' , maar ONLYOFFICE beschrijft deze expliciet als onveilig en adviseert het certificaat te vervangen door een certificaat dat is uitgegeven door een vertrouwde CA. Actie: gebruik het omzeilen van certificaatverificatie alleen als een korte diagnostische stap in een gecontroleerde omgeving; de permanente oplossing is een geldige certificaatketen die door beide servers wordt vertrouwd.
Als er een reverse proxy voor ONLYOFFICE staat, controleer dan of deze het verwachte schema, de host en het upgradegedrag behoudt. ONLYOFFICE publiceert specifieke richtlijnen voor reverse proxy's, inclusief doorgestuurde headers en WebSocket-gerelateerde instellingen. Zie de configuratiehandleiding voor Nextcloud reverse proxy's van ONLYOFFICE .
Implementatieafhankelijk: de exacte Nginx-, Apache-, Traefik-, HAProxy-, ingress-controller- of CDN-configuratie kan niet alleen uit de opslagfout worden afgeleid. Actie: vergelijk uw proxyconfiguratie met het voorbeeld van de leverancier voor uw topologie en controleer de HTTP-status die tijdens de callback is vastgelegd voordat u willekeurig time-outs of headers wijzigt.
Zodra de logboeken aantonen dat de callback Nextcloud succesvol heeft bereikt, ga je verder in de stack. Nextcloud moet het nieuwe document kunnen ophalen en de opgeslagen versie kunnen vervangen. Lokale bestandsrechten, een alleen-lezen mount, een volle schijf, quotabeperkingen, niet-beschikbare externe opslag of een applicatie-/opslagfout kunnen allemaal voorkomen dat de laatste schrijfbewerking plaatsvindt.
Wat bekend is: de callback-statuswaarden van ONLYOFFICE maken onderscheid tussen een document dat klaar is om op te slaan en een document met een opslagfout. De callback bevat een URL naar het bewerkte document, zodat de opslagservice het kan ophalen. De officiële documentatie van de callback-handler definieert status 2 als 'klaar om op te slaan' en status 3 als een opslagfout.
Wat niet duidelijk is uit het browserbericht alleen: of de fout is opgetreden in ONLYOFFICE, op het netwerkpad, in Nextcloud of in de onderliggende opslag. Actie: wijzig niet recursief het eigenaarschap van bestanden in een Nextcloud-gegevensmap alleen omdat de editor aangeeft dat opslaan niet mogelijk is. Controleer eerst of er een fout aan de opslagzijde is in het Nextcloud-logboek.
Een andere misvatting is dat elke keer dat je op ' Opslaan' klikt , het bestand dat in Nextcloud is opgeslagen direct wordt vervangen. De connector kan een optie voor tussentijds opslaan of geforceerd opslaan gebruiken. De officiële integratiehandleiding geeft aan dat wanneer ' Tussentijdse versies behouden tijdens bewerken (geforceerd opslaan)' is ingeschakeld, het klikken op 'Opslaan' de wijzigingen direct naar de opslag verzendt; anders worden de wijzigingen in de editorcache bewaard en vindt de normale workflow voor definitief opslaan later plaats.
Dit is belangrijk voor het oplossen van problemen. Als alleen het geforceerd opslaan mislukt, maar het normaal sluiten en opslaan wel lukt, of andersom, dan vormen de tijdstempels en callback-statussen waardevol bewijsmateriaal. Actie: reproduceer de fout in één duidelijk gedefinieerde workflow en leg de logboeken van die poging vast in plaats van handmatig opslaan, het sluiten van de browser en meerdere gelijktijdig geopende editortabbladen te combineren.
| Symptoom | Meest nuttige volgende controle | Ga niet uit van aannames. |
|---|---|---|
| De editor zal helemaal niet openen. | URL van de documentserver, JWT, bereikbaarheid van browser/server | Dat het een probleem is dat alleen bij het opslaan voorkomt |
| De editor wordt geopend, maar het opslaan mislukt. | Bereikbaarheid van callbacks en DocService-logboeken | Die succesvolle opening bewijst de terugweg. |
| 401/403-foutmeldingen in verband met terugbel- of commandoverkeer. | JWT-geheim en autorisatieheader | Dat een proxy-time-out de oorzaak is. |
| TLS/certificaatvalidatiefouten | Certificeringsketens en vertrouwenswinkels | Dat het uitschakelen van de verificatie een permanente oplossing is. |
| De callback bereikt Nextcloud, maar het bestand blijft ongewijzigd. | Nextcloud-logboek, opslagkoppeling, quota, schrijffouten | Dat ONLYOFFICE de bewerking is kwijtgeraakt |
| Fouten treden alleen op achter een proxy/NAT. | Geavanceerde interne URL's en doorgestuurde routering | Dat openbare URL's binnen containers identiek werken. |
Gebruik een klein test-DOCX-bestand in een niet-kritieke map. Open het in ONLYOFFICE, typ een unieke regel, zoals een tijdstempel, wacht tot de editor de wijziging als opgeslagen meldt en sluit de editor vervolgens normaal. Heropen het bestand vanuit Nextcloud en controleer of de tekst aanwezig is. Controleer vervolgens de versiegeschiedenis (indien uw implementatie deze gebruikt) en de serverlogboeken voor dezelfde periode.
Voer vervolgens de connectorcontrole opnieuw uit:
sudo -E -u www-data php occ onlyoffice:documentserver --checkEen goed resultaat is niet simpelweg "de editor opent". De volledige test is: Nextcloud kan ONLYOFFICE bereiken, ONLYOFFICE kan het callback-adres op Nextcloud bereiken, de authenticatie slaagt, Nextcloud kan het bijgewerkte bestand ophalen en de opslagbackend accepteert de vervanging.
Als geen van de logbestanden een duidelijke fout laat zien, verhoog dan tijdelijk de logboekregistratie voor ONLYOFFICE en Nextcloud tijdens één gecontroleerde reproductie, en zet het logniveau daarna weer terug naar normaal. Nextcloud waarschuwt dat DEBUG-logboekregistratie uitgebreid is en de prestaties kan beïnvloeden, dus het moet een diagnostische maatregel zijn en geen permanente instelling voor productieomgevingen. Raadpleeg de documentatie over logboekregistratie van Nextcloud voordat u de logniveaus wijzigt.
Bewaar op dat moment de exacte tijdstempels, HTTP-statuscodes, connectorversie, Nextcloud-versie, ONLYOFFICE Docs-versie, topologie en de relevante geanonimiseerde logregels. Deze gegevens zijn veel nuttiger dan het algemene bericht van de browser: "Document kon niet worden opgeslagen".
Verbind ONLYOFFICE Desktop Editors met uw eigen cloudserver, meld u aan, open cloudbestanden, beheer de verbinding en los veelvoorkomende installatieproblemen op.
Troubleshoot high Collabora Online CPU usage by identifying busy kit processes, checking metrics and logs, tuning concurrency and cleanup, and verifying fixes safely.
Leer hoe je ONLYOFFICE Docs kunt personaliseren met een logo in de header en interfacekleuren, inclusief licentielimieten, het instellen van thema-JSON, Docker-paden en testen.
Verbeter de leesbaarheid van tekst in LibreOffice Calc door het thema van de app, het lettertype en de opvulkleuren van de cellen, de stijlen en de voorwaardelijke opmaak te controleren en vervolgens de afdruk te verifiëren.
Verwijder de waarschuwing voor vergrendeling door onbekende gebruiker in LibreOffice op een veilige manier. Controleer actieve sessies, beveilig een kopie, verwijder alleen een geverifieerde, verouderde vergrendeling en test het document.
Corrigeer Arabische of Hebreeuwse tekst die niet goed doorloopt, uitgelijnd is of vermengd is met Engels in LibreOffice Writer. Schakel de complexe tekstlay-out in, stel de alinearichting in en controleer het resultaat.
Learn VLOOKUP and XLOOKUP in LibreOffice Calc, including exact matches, left lookups, not-found results, reverse search, INDEX/MATCH alternatives, and common errors.
Los problemen met de WOPI-bewijsvalidatie van Collabora Online op door de ontdekkingssleutels, sleutelrotatie, proxy-URL's, tijdstempels en host-whitelists te controleren.
Schakel 'Wijzigingen bijhouden' in voor iedereen in een ONLYOFFICE-document, zorg ervoor dat deze functie actief blijft na het opnieuw openen en begrijp de beperkingen van een algemene standaardinstelling.
Vergelijk de time-outs per weergave, onscherpte, inactieve documentstatus, automatisch opslaan en proxy-time-outs van Collabora Online, en kies en controleer vervolgens de instellingen voor uw implementatie.
