Documents don't open

Collabora and Nextcloud installed at different servers. When clicking at document, collabora opens, but can’t connect to document. And here are some errors in docker log:

Any issues?

With me that error was always DNS.

I am self hosting and the docker container is a client on the local subnet and it was always trying to find nextcloud on the public IP address but actually that was my router that would port forward those.

I think you will get corresponding errors in the apache log that will give you the url if the log level is set right.

docker exec -i -t (container-id) /bin/sh and run openssl s_client -connect and that will prob give you the info you need.

I am using DNSMasq for internal DNS and using docker run -t -d -p -e ‘domain=nextcloud\.vote4u\.org\.uk’ --dns= --restart always --cap-add MKNOD collabora/code
I could of used the normal docker run command and just placed the nextcloud local-ip into the containers /etc/hosts file.
I never tried it and I presume it exists and works :slight_smile:

With the addition --dns= of DNSMasq, but you can also do it with /etc/hosts without the need for an internal dns-server and also remember that the docker client will also need this.
–dns= will use the internal DNS server rather than external public one.

You will prob find if you put the url into a browser it will return the file json and its just the DNS of the docker container that is pulling from the wrong place.

For me it was just a split DNS problem, or that I hadn’t set up a mechanism for split DNS and the difference between public external DNS and local subnet DNS.

Here is what I’ve got using these commands:

[root@office ~]# docker exec -i -t 445ec47f1b0c /bin/sh

openssl s_client -connect

depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3
verify return:1
depth=0 CN =
verify return:1

Certificate chain
0 s:/
i:/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
1 s:/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3

Server certificate
issuer=/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3

No client certificate CA names sent

SSL handshake has read 3156 bytes and written 415 bytes

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 5F532C4DF74171EC6684FA517FCDF58DECE2ECB45BBB841AB2A6A5466EA18454
Master-Key: 0F5D0410BD805464E8A667BB125D6BA7141D8EE4BD23B01CF91920FD1C5B1AB35FA1DF1B32977AB3372634EF6330DFA7
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 83 6b 55 cb 6f d5 90 a5-56 9e ba e8 8f 9d 4a 80 .kU.o…V…J.
0010 - dd d7 a3 84 f4 86 89 ff-00 41 cd d1 a3 c8 51 57 …A…QW
0020 - b7 16 74 d4 7c 45 b8 4d-07 37 4b 2a ac 10 79 36 …t.|E.M.7K*…y6
0030 - 3d 2c 88 9b d7 47 95 1a-0a 9c 01 b9 2b cb 9f 57 =,…G…+…W
0040 - 65 8d 62 51 d4 2d d9 3f-7c 46 19 01 2b 41 cd fd e.bQ.-.?|F…+A…
0050 - 8d 0a b4 1f 34 16 74 b0-a2 26 26 9f 4a c1 22 e7 …4.t…&&.J.".
0060 - 03 77 11 d3 5e 37 1a b1-e4 40 de 5a bd 92 c2 43 .w…^7…@.Z…C
0070 - ad 8c 61 a1 9c 60 41 85-9f e0 f2 d2 7f cb 3f 9b …a…`A…?.
0080 - 48 89 f6 1a f4 c0 4d 17-d5 fe 6b bf 5d e4 95 5d H…M…k.]…]
0090 - f3 03 3a eb 90 a1 44 f4-96 24 25 82 f0 2a 38 39 …:…D…$%…89
00a0 - f4 2e 27 fc 8c ca 6c 2a-2b 78 ba dd 54 de 7a 5f …’…l

Start Time: 1485210959
Timeout   : 300 (sec)
Verify return code: 0 (ok)

Well your DNS and certs are OK.

What happens if you curl the full url request to nextcloud from inside the container?

If you up the reporting on the nextcloud logs it should end up in there.
I can not remember if they turn up in the apache or next cloud logs, think it was the apache logs.

I got that error because of DNS but its the same and what its expecting is the file json descriptor.

So if you pass the full request url via curl it give you an idea.

I did think it would be your DNS though.

There’s also an error in nextcloud log:

You could try adding the letsencypt intermediary certs onto the end of that ca bundle as they are just a copy of the Mozilla root certs I think, I wasn’t particularly sure why that bundle is there as they are usually handled by the host certificates ca.
Someone will tell me why they are included that way.

I guess its part of the OCC commands but not really sure why nextcloud is handling certs rather than system tools.

openssl will prob work because it validates against system install certs but on your system it would seem nextcloud is doing it.
does openssl s_client -connect work if you specify that CA bundle?
[-CApath directory] [-CAfile filename]
Do it on the server or container as I think the results will be the same.

I don’t know what that bundle is, so can not help you.