The systemplate directory [/opt/cool/systemplate] is read-only, and at least [/opt/cool/systemplate//etc/hosts] is out-of-date. Will have to clone dynamic elements of systemplate to the jails. To restore optimal performance, make sure the files in [/opt/cool/systemplate/etc] are up-to-date.| common/JailUtil.cpp:587
sorry dude, no idea what that is… looks like a host issue though
figured… check your blocklists and whitelist collabora subdomain?
you could test if its a DNS issue by disabling the Pihole for a couple of minutes (use the Pihole interface for that) and che if collabora works… then you’ll know if you need to whitelist something.
its always DNS…
ahh… okay double safety double trouble, kids in da house 
okay, so lets get back to basics… what are you forwarding in “swag”? I use NPM and only forward WSS (see wiki-md/NEXTCLOUD.snap--configure-CODE-in-docker-for-nextcloud-snap.md at scubamuc-wiki · scubamuc/wiki-md · GitHub). You need to forward “Websockets support”.
Here’s my swag:
services:
swag:
image: ghcr.io/linuxserver/swag
container_name: swag
cap_add:
- NET_ADMIN
environment:
- PUID=1001
- PGID=100
- URL=XXXXXXXXXX.duckdns.org
- DUCKDNSTOKEN=XXXXXXXXXXXXXXXXXXX
- SUBDOMAINS=wildcard
- VALIDATION=duckdns
- EMAIL=XXXXXXXXXXXXXXXXXXXX
- DOCKER_MODS=linuxserver/mods:swag-dashboard
volumes:
- /srv/dev-disk-by-uuid-c3060981-d75c-4ea9-8285-2333c24522df/swag:/config
- /etc/localtime:/etc/localtime:ro
ports:
- 444:443
- 82:80
- 81:81
restart: unless-stopped
The ports are chosen like that due to conflicts. I am able to access all of my subdomains happily currently, mealie, nextcloud, heimdall etc.
My forwarding is set up accordingly in Pfsense with pure NAT rules:
Is there something I can curl to check the DNS issue?
Thanks again!
oh my, you’ve lost me now 
! hang ten and see if someone else has any ideas… I’m bailing out now 
No stress. Basically external 443 is forwarded to internal 444 to make it to my reverse proxy… Something else was using internal 443. I think OMV was using 80 and 443.
Proxy confs are set up for each subdomain so that I can access these over the internet without issue.
So far I have done this from inside the container:
coolconfig update-system-template
which has removed the systemplate errors.
I have also added local dns entries for my domain in adguard and pihole (I know…) which I think? has cleared some of the dns errors. When I create a file now I get a different timeout:
[richdocuments] Error: cURL error 28: Resolving timed out after 5001 milliseconds (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://collabora.xxxxxxxxxxxxxx.org/hosting/discovery
GET /apps/richdocuments/settings/check
from 192.168.1.1 by rowan at Jan 7, 2025, 5:10:09 PM
Please review DNS resolution from inside of the container. But your config with custom ports is definitely not suited to setup splitbraindns as direct internal connections without router port forwarding will hit port :443 which is not in use 
as long you don’t want to adjust internal port to default you have through the rabbit hole: route internal traffic through the internet, troubleshoot DNS issues and resolve them…
I see, thank you. I just don’t understand why I have never had these issues in the past with all of my other services?
Would you be able to help advise how I can check dns? I have run:
curl -v https://collabora.mydomain.tld and curl -v https://nextcloud.mydomain.tld from inside my collabora container and both return the same IP and wildcard cert.
Hello,
I have now returned to mapping 443:443 as I completely forgot the service that required that, I don’t use anymore. I have gone to create a new file and the DNS errors are still persistent:
[richdocuments] Error: cURL error 28: Operation timed out after 5002 milliseconds with 0 bytes received (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://collabora.xxxxx.org/cool/extract-document-structure?filter=contentcontrol
GET /ocs/v2.php/apps/files/api/v1/templates
from 192.168.1.1 by rowan at Jan 8, 2025, 9:15:13 AM
When I curl collabora.xxxxxxx.org from inside my nextcloud container, it seems to go via port 80, whereas the other way around it goes through 443:
root@2cab92a4380e:/# curl -v collabora.xxxxx.org
* Host collabora.xxxxxxxx.org:80 was resolved.
* IPv6: (none)
* IPv4: mycorrectIP
* Trying mycorrectIP:80...
* Connected to collabora.xxxxxxxx.org (mycorrectIP) port 80
* using HTTP/1.x
> GET / HTTP/1.1
> Host: collabora.xxxxxxxx.org
> User-Agent: curl/8.11.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Wed, 08 Jan 2025 09:18:20 GMT
< Content-Type: text/html
< Content-Length: 162
< Connection: keep-alive
< Location: https://collabora.xxxxxxxx.org/
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host collabora.xxxxxxxx.org left intact
I’ve sanitised the above a bit to hide my publicIP and domain.
as long you can successfully check CODE URL and XML content from Nextcloud and NC URL from CODE container everything seems fine. as you stated initially the problem seems intermittent and you might be unable to see the error all the time. you must be running curl or any other tool to check the DNS resolution exactly at the moment the error occurs - likely you will see the error then.
is checking plain http:// likely there is no difference but please test curl https://collabora..
The error is different now
it looks the system can resolve DNS but doesn’t get any data back.
Ah of course, my mistake. Thank you.
I re-ran curl -v https://collabora.xxxxx.org from inside my nextcloud container, and it could not resolve.
If I curl https://nextcloud.xxxxx.org, it resolves, then if I curl collabora again, it resolves:
* Host collabora.xxxxx.org:443 was resolved.
* IPv6: (none)
* IPv4: xxxxx
* Trying xxxxx:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey
* ALPN: server accepted http/1.1
* Server certificate:
* subject: CN=*.xxxxx.org
* start date: Dec 3 01:13:17 2024 GMT
* expire date: Mar 3 01:13:16 2025 GMT
* subjectAltName: host "collabora.xxxxx.org" matched cert's "*.xxxxx.org"
* issuer: C=US; O=Let's Encrypt; CN=E5
* SSL certificate verify ok.
* Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* Connected to collabora.xxxxx.org (xxxxx) port 443
* using HTTP/1.x
> GET / HTTP/1.1
> Host: collabora.xxxxx.org
> User-Agent: curl/8.11.1
> Accept: */*
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 200 OK
< Server: nginx
< Date: Wed, 08 Jan 2025 09:40:16 GMT
< Content-Type: text/plain
< Content-Length: 2
< Connection: keep-alive
< Last-Modified: Wed, 08 Jan 2025 09:40:16
< Strict-Transport-Security: max-age=63072000
< Referrer-Policy: same-origin
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
<
* Connection #0 to host collabora.xxxxx.org left intact
And now if I do it again, it cannot resolve! Very confusing!
sounds you are close to isolate the problem… maybe DNS resolution takes longer (sometimes)… I’m not sure which tools you have available in the linuxserverio container at the last resort you can use php directly
php -r "var_dump(dns_get_record('nextcloud.com', DNS_A ) ) ;"
php -r "var_dump(dns_get_record('nextcloud.com', DNS_AAAA ) ) ;"
Try get rid of the DNS problem. with valid splitbraindns DNS should resolve to your internal reverse proxy IP.
Interesting, I’m no expert on these things so it will be a bit of a struggle haha!
Here’s the type A output:
root@2cab92a4380e:/# php -r "var_dump(dns_get_record('xxxxxxx.org', DNS_A ) ) ;"
array(1) {
[0]=>
array(5) {
["host"]=>
string(16) "xxxxxxx.org"
["class"]=>
string(2) "IN"
["ttl"]=>
int(24)
["type"]=>
string(1) "A"
["ip"]=>
string(13) "mycorrectpublicIP"
}
}
Interestingly for AAAA:
root@2cab92a4380e:/# php -r "var_dump(dns_get_record('xxxxxxx.org', DNS_AAAA ) ) ;"
array(0) {
}
What does this mean? I assume this is because there WAS a response for A?
Again, thank you for the support here, I wouldn’t be able to get this far myself.
I have looked in my pihole logs and in some cases I see BOGUS (refused upstream which indicates a DNSSEC issue right? I have taken steps to ensure my pihole and containers are all using the system time. I don’t think this will be the issue however.
Is it wise to turn off DNSSEC in this case?
I have also realised which action is causing the issue. Before it was something to do with using templates/viewing thumbnails or previews of a file. Probably this is what the /convert-to/png error is.
The new issue occurs when I re-click “save” in the nextcloud office admin settings.
Logs:
[richdocuments] Error: cURL error 28: Resolving timed out after 5002 milliseconds (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://collabora.xxxxxxx.org/hosting/discovery
GET /apps/richdocuments/settings/check
from 192.168.1.1 by rowan at Jan 8, 2025, 10:50:15 AM
Admin page:
Could not establish connection to the Collabora Online server.
Failed to connect to the remote server: cURL error 28: Resolving timed out after 5002 milliseconds (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://collabora.xxxxxx.org/hosting/discovery
Ok, so turning off DNSSEC in PiHole settings seems to have resolved this for me. I had a lot of BOGUS (refused upstream) showing in my PiHole logs. This has also stopped my heimdall loading slowly which is great!
For some reason, the signatures done seem to be like by the upstream server? Maybe this is because I had ONLY cloudflare as an upstream DNSSEC capable server. I might try adding a handful more to see if they are able to work with my domain.
Thanks a lot for the support so far. If you could spare some time to help me understand the above a bit better that would be great!
However, curl -v https://collabora.xxxxx.org from inside my nextcloud container is still intermittent
So is
php -r "var_dump(dns_get_record(xxxxxxx.org', DNS_A) ) ;"
My pihole seems to be getting NODATA issues for https:
