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 example.com:443/url and that will prob give you the info you need.
I am using DNSMasq for internal DNS and using docker run -t -d -p 127.0.0.1:9980:9980 -e ‘domain=nextcloud\.vote4u\.org\.uk’ --dns=192.168.1.2 --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 
With the addition --dns=192.168.1.2 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=192.168.1.2 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 cloud.devra.ru:443
CONNECTED(00000003)
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 = cloud.devra.ru
verify return:1
Certificate chain
0 s:/CN=cloud.devra.ru
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
-----BEGIN CERTIFICATE-----
MIIFFDCCA/ygAwIBAgISA7RvCGrDREJQRzfp2TKGgn2uMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzAxMTgxOTQwMDBaFw0x
NzA0MTgxOTQwMDBaMBkxFzAVBgNVBAMTDmNsb3VkLmRldnJhLnJ1MIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4eAWwEz1WEKMHNqWqtuttCGEq4EI38tg
vyNtCTCZ8OLytS5qN2+1ow1bpPIJj/V6sg/HNBpNqxVCBuT2WoZMJkPNBryc4OO+
1bDqHJ3pkkNbUPct/bEfCthHou1PPTaJobH+G8w4tnEBOhXa7RfjxDPEg3LmEuHN
XRXHzJBW6sj3eHL+5e10li27RNzidBDQShYDbKjMuI6+or9C/HpakBAWTwqFPwjb
yRo2HX46SOo3oAEpvZ/96elArTYR0HlHwPvZthKmJQylD+8lxoL32frEJN1vbEuV
CQmahan0cmbmgZXixz96xU/BdOqlG7l0Q8INrnb/xqKBbnIUnKn6EwIDAQABo4IC
IzCCAh8wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
BQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQ1lyd2RIPbkUEff7HhStQdHUmS
DjAfBgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBwBggrBgEFBQcBAQRk
MGIwLwYIKwYBBQUHMAGGI2h0dHA6Ly9vY3NwLmludC14My5sZXRzZW5jcnlwdC5v
cmcvMC8GCCsGAQUFBzAChiNodHRwOi8vY2VydC5pbnQteDMubGV0c2VuY3J5cHQu
b3JnLzAtBgNVHREEJjAkgg5jbG91ZC5kZXZyYS5ydYISd3d3LmNsb3VkLmRldnJh
LnJ1MIH+BgNVHSAEgfYwgfMwCAYGZ4EMAQIBMIHmBgsrBgEEAYLfEwEBATCB1jAm
BggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwgasGCCsGAQUF
BwICMIGeDIGbVGhpcyBDZXJ0aWZpY2F0ZSBtYXkgb25seSBiZSByZWxpZWQgdXBv
biBieSBSZWx5aW5nIFBhcnRpZXMgYW5kIG9ubHkgaW4gYWNjb3JkYW5jZSB3aXRo
IHRoZSBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9sZXRzZW5j
cnlwdC5vcmcvcmVwb3NpdG9yeS8wDQYJKoZIhvcNAQELBQADggEBACRUr0Ob0is0
pMcdoBx0kuyZjzxTrtSByCrTUUC8UxkH7dcbUxrl2C8y8uYZAT5MKJA7ilF4/8LN
WBjIodExvfPDIXERmV+FJFZrJ1nhreow+q4SNCIhe5EYnJcswJTBO7gT1FoMaaXA
B7sFeN+3IRVBD3gE84EO4qdLD/sE4LiUKJFarcABtiU5AkaL+FVBh+tq3agtYP0/
ZDSFtP4LBxlxDQ/F1joA5C6POcab9ySntCXt9UXvq9GUkrSOBSg5KMiP71EuyAuu
StmpiPmZh29HmGVyYSeqZLB5trC07pZBB244HeihkrHcW5GlTWnjD3H0n+v3wLGZ
qkjGAycV1B4=
-----END CERTIFICATE-----
subject=/CN=cloud.devra.ru
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
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 5F532C4DF74171EC6684FA517FCDF58DECE2ECB45BBB841AB2A6A5466EA18454
Session-ID-ctx:
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+x…T.z_
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.
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.