[FIXED] Collabora new document creation doesn’t work but editing again work

ℹ️ Support 📄 Collabora
1

When I create a new document I get: Failed to load:

May 18 08:26:38 nextcloud loolwsd[27981]: kit-18536-27983 2020-05-18 06:26:38.053072 [ kitbroker_016 ] ERR  Failed to load: file:///user/docs/DdrGXFQmCYywPo3z/provadocumento.odt, error: Unsupported URL <https://FQDN/index.php/apps/richdocuments/wopi/template/15773?access_token=0R1TF5wfwjWcCfe6G3BkXjHRmxIWDma1>: "type detection failed"| kit/Kit.cpp:1670
May 18 08:26:38 nextcloud loolwsd[27981]: kit-18536-27983 2020-05-18 06:26:38.053156 [ kitbroker_016 ] ERR  Failed to get LoKitDocument instance for [file:///user/docs/DdrGXFQmCYywPo3z/provadocumento.odt].| kit/ChildSession.cpp:627
May 18 08:26:38 nextcloud loolwsd[27981]: kit-18536-27983 2020-05-18 06:26:38.053170 [ kitbroker_016 ] ERR  error: cmd=load kind=faileddocloading| ./common/Session.hpp:127
May 18 08:26:38 nextcloud loolwsd[27981]: wsd-27981-18545 2020-05-18 06:26:38.053260 [ docbroker_016 ] WRN  Document load failed: faileddocloading| wsd/ClientSession.cpp:1114
May 18 08:26:38 nextcloud loolwsd[27981]: kit-18536-27983 2020-05-18 06:26:38.053348 [ kitbroker_016 ] WRN  Document::ViewCallback. Session [-1] is no longer active to process [LOK_CALLBACK_ERROR] [{
May 18 08:26:38 nextcloud loolwsd[27981]:     "classification": "error",
May 18 08:26:38 nextcloud loolwsd[27981]:     "cmd": "load",
May 18 08:26:38 nextcloud loolwsd[27981]:     "kind": "network",
May 18 08:26:38 nextcloud loolwsd[27981]:     "code": "0x6b03(Error Area:Inet Class:Read Code:3)",
May 18 08:26:38 nextcloud loolwsd[27981]:     "message": ""
May 18 08:26:38 nextcloud loolwsd[27981]: }
May 18 08:26:38 nextcloud loolwsd[27981]: ] message to Master Session.| kit/Kit.cpp:1970
May 18 08:26:38 nextcloud loolwsd[27981]: wsd-27981-18545 2020-05-18 06:26:38.076404 [ docbroker_016 ] WRN  Client session [2c6] not found to forward message: o4765 disconnected:| wsd/DocumentBroker.cpp:2110
May 18 08:26:38 nextcloud loolwsd[27981]: kit-18536-27983 2020-05-18 06:26:38.076437 [ kitbroker_016 ] WRN  Skipping unload on incomplete view.| kit/ChildSession.cpp:105
May 18 08:26:39 nextcloud loolwsd[27981]: Document [/index.php/apps/richdocuments/wopi/files/19036_ocacsh529k91] has no more views, exiting bluntly.

but edit it again work.

system packages:

loolwsd 4.2.3-3
collaboraoffice6.2 6.2.10.12-12
nextcloud 18.04

OS:
debian buster 10.4

2

Hello,

same issue…
You have find something ?
the “file:///user/docs…” seems strange to me

 loolwsd[1632]: kit-02307-01645 2020-05-20 09:16:01.179598 [ kit_014 ] ERR  Failed to get LoKitDocument instance for [file:///user/docs/PK5SFRTEtMmOFRja/aaaqqq.odt].| kit/ChildSession.cpp:632
 loolwsd[1632]: kit-02307-01645 2020-05-20 09:16:01.179614 [ kit_014 ] ERR  error: cmd=load kind=faileddocloading| ./common/Session.hpp:125
 loolwsd[1632]: kit-02307-01645 2020-05-20 09:16:01.179655 [ kit_014 ] WRN  Document::ViewCallback. Session [-1] is no longer active to process [LOK_CALLBACK_ERROR] [{
[ kit_014 ]     "classification": "error",
v011063 loolwsd[1632]:     "cmd": "load",
v011063 loolwsd[1632]:     "kind": "network",
v011063 loolwsd[1632]:     "code": "0x6b03(Error Area:Inet Class:Read Code:3)",
v011063 loolwsd[1632]:     "message": ""
v011063 loolwsd[1632]: }

nc18.4 / collabora 6.2.10.12-12 / loolwsd 4.2.3-3

3

No I haven’t found a solution yet.

4

I went a little further in the tests, and I don’t see how it can work in the end …

Does anyone observe normal operation when creating a document and opening it automatically?

my observations if it can help:

restart of loolwsd, only one child-roots:

/opt/lool/child-roots/
└── [May 20 15:52]  EStM4jm0SY3FJXsk
    ├── [May 20 15:52]  dev
    ├── [May 20 15:52]  etc
    ├── [May 20 15:52]  lib
    ├── [May 20 15:52]  lib64
    ├── [May 20 15:52]  lo
    ├── [May 20 15:52]  opt
    ├── [May 20 15:52]  tmp
    ├── [May 20 15:52]  user
    ├── [May 20 15:52]  usr
    └── [May 20 15:52]  var

opening an existing file (existing.odt) -> OK:

so creation of a second “child-roots” (9O5r97z9dqGyLaDk) but the file will go into the first “child-roots” (EStM4jm0SY3FJXsk)
strange already, why create a second “child-roots” to use the first?
but hey it works …

/opt/lool/child-roots/
├── [May 20 15:58]  9O5r97z9dqGyLaDk
│   ├── [May 20 15:58]  dev
│   ├── [May 20 15:58]  etc
│   ├── [May 20 15:58]  lib
│   ├── [May 20 15:58]  lib64
│   ├── [May 20 15:58]  lo
│   ├── [May 20 15:58]  opt
│   ├── [May 20 15:58]  tmp
│   ├── [May 20 15:58]  user
│   ├── [May 20 15:58]  usr
│   └── [May 20 15:58]  var
└── [May 20 15:52]  EStM4jm0SY3FJXsk
    ├── [May 20 15:52]  dev
    ├── [May 20 15:52]  etc
    ├── [May 20 15:52]  lib
    ├── [May 20 15:52]  lib64
    ├── [May 20 15:52]  lo
    ├── [May 20 15:52]  opt
    ├── [May 20 15:52]  tmp
    ├── [May 20 15:58]  user
        ├── docs
        └── EStM4jm0SY3FJXsk
            └── existing.odt
    ├── [May 20 15:52]  usr
    └── [May 20 15:52]  var

Now creation of a new file and automatic opening in error -> NOK.

when closing the document (existing.odt) the child-roots (EStM4jm0SY3FJXsk) is deleted, remains on (9O5r97z9dqGyLaDk)

/opt/lool/child-roots/
└── [May 20 15:58]  9O5r97z9dqGyLaDk
    ├── [May 20 15:58]  dev
    ├── [May 20 15:58]  etc
    ├── [May 20 15:58]  lib
    ├── [May 20 15:58]  lib64
    ├── [May 20 15:58]  lo
    ├── [May 20 15:58]  opt
    ├── [May 20 15:58]  tmp
    ├── [May 20 15:58]  user
    ├── [May 20 15:58]  usr
    └── [May 20 15:58]  var

Creation of the new document (new.odt) and automatic opening in failure.
So already delete the previous child-roots and create a new one (1emvd6MMfKcFXs4L):

/opt/lool/child-roots/
└── [May 20 16:17]  1emvd6MMfKcFXs4L
    ├── [May 20 16:17]  dev
    ├── [May 20 16:17]  etc
    ├── [May 20 16:17]  lib
    ├── [May 20 16:17]  lib64
    ├── [May 20 16:17]  lo
    ├── [May 20 16:17]  opt
    ├── [May 20 16:17]  tmp
    ├── [May 20 16:17]  user
        ├── [May 20 16:17]  autotext
        ├── [May 20 16:17]  basic
        ├── [May 20 16:17]  config
        ├── [May 20 16:17]  database
        ├── [May 20 16:17]  extensions
        └── [May 20 16:17]  gallery

but it can’t work, because it will look for it in the old child-root deleted when the new document (new.odt) was created:
so here -> “/opt/lool/child-roots/EStM4jm0SY3FJXsk”/user/docs/9O5r97z9dqGyLaDk/new.odt

May 20 16:17:28 server loolwsd[6978]: kit-07063-06980 2020-05-20 14:17:28.940839 [ kit_002 ] ERR  Failed to load: file:///user/docs/9O5r97z9dqGyLaDk/new.odt, error: Unsupported URL <https://nextcloud.example.com/index.php/apps/richdocuments/wopi/template/1531?access_token=J4wdnRSynDf24RDMKXiqUfsRCkqu6cPh>: "type detection failed"| kit/Kit.cpp:1725

so we validate the error in the browser “Failed to load the document. Please ensure the file type is supported and not corrupted, and try again.”, we close lool, and we open the file new.odt
there a new child-root is created (dmGJytwk9apufiap) but the document is still this time in the previously created child-root (1emvd6MMfKcFXs4L) as it should have been when opened automatically.

/opt/lool/child-roots/
├── [May 20 16:17]  1emvd6MMfKcFXs4L
│   ├── [May 20 16:17]  dev
│   ├── [May 20 16:17]  etc
│   ├── [May 20 16:17]  lib
│   ├── [May 20 16:17]  lib64
│   ├── [May 20 16:17]  lo
│   ├── [May 20 16:17]  opt
│   ├── [May 20 16:17]  tmp
│   ├── [May 20 16:31]  user
        ├── [May 20 16:31]  docs
│           └── [May 20 16:31]  1emvd6MMfKcFXs4L
│               └── [May 20 16:31]  new.odt
│   ├── [May 20 16:17]  usr
│   └── [May 20 16:17]  var
└── [May 20 16:31]  dmGJytwk9apufiap
    ├── [May 20 16:31]  dev
    ├── [May 20 16:31]  etc
    ├── [May 20 16:31]  lib
    ├── [May 20 16:31]  lib64
    ├── [May 20 16:31]  lo
    ├── [May 20 16:31]  opt
    ├── [May 20 16:31]  tmp
    ├── [May 20 16:31]  user
    ├── [May 20 16:31]  usr
    └── [May 20 16:31]  var

Voilà, I think it deserves to declare an issue but at collabora or nextcloud?

Regards,
Greg

5

i got it working!
…/nextcloud/apps/richdocuments/lib/Controller/WopiController.php
need to comment out this code (lines 213-218. app ver 3.7.0)

/**             if ($wopi->hasTemplateId()) {
                        $templateUrl = 'index.php/apps/richdocuments/wopi/template/' . $wopi->getTemplateId() . '?access_token=' . $wopi->getToken();
                        $templateUrl = $this->urlGenerator->getAbsoluteURL($templateUrl);
                        $response['TemplateSource'] = $templateUrl;
                }*/
4 Likes
6

@DmDS Great ! good job !
I confirm that it works correctly after commenting on this block.
have you open an issue on https://github.com/nextcloud/richdocuments/issues ?

I don’t understand why so few people (apparently) have this problem …

1 Like
7

yes

8

I experienced identical issues. I believe the commented out lines in post 4 are a workaround not a fix.

For me the fix was two parts:

  1. Virus scanner was still using the default clamd binary path. I needed to change to using a socket. The official documentation does state that using the binary path can be slow.
  2. My libreoffice-online install had picked up a bad resolv.conf file which had an incorrect IP address for the first name server.

These two issues essentially caused timeouts in php processing which resulted in the symptoms described in the initial post. There are multiple steps in the new document creation / templates which made it more likely to suffer timeouts from slow processess than opening an existing document. Turning on the slow-php log and adjusting php timeouts finally helped to track it down.

9

I had the same problem. My issue was that although both nextcloud and collabora were behind https reverse proxies, nextcloud thought it was using http and was sending http urls to collabora. Setting overwrite protocol to https in config.php fixed it.

10

I believe this is the same issue that was reported and fixed here: https://github.com/nextcloud/richdocuments/pull/1169

Would be great if someone could confirm the fix in PR 1169 resolves the issue.

To do that, either upgrade to the latest NC release and manually apply that tiny fix, or checkout the latest code (that includes the fix) and test again. Either way, test on a non-production server!

Thanks

11

I’m on 19.04 and it did not fix it for me @ash

12

@Steven_S there is another patch that is relevant here: https://github.com/nextcloud/server/pull/23741

Let’s hope it resolves the case you (and others) are hitting.

1 Like
13

It did! Thanks for the follow up and the fix.