Ok, so I got rid of the snap and installed from the zip archive. Got it up and running, now on version 16.0.1. And I’m having the exact same problem with Collabora Online. The only difference I see is NextCloud now says “Failed to connect to Collabora Online Development Edition.” Not sure where the Development Edition came from? I’m using the same docker image as before.
Any ideas?
I tried rolling back the docker snap from the current stable version 18.06.1-ce to the previous stable 17.06.2-ce. Still does not work. I also tried running the Collabora docker using both the loopback 127.0.0.1 and the actual local IP. Neither worked.
Having tried this with two major Nextcloud versions and two major Docker versions as well as various other configuration changes, I’m stumped at this point and have about given up on Collabora unless anyone knows anything else to try.
I found out today that there’s an option to start collabora/code in docker without SSL, so I did that an ran a capture with tshark to see what was going on. When clicking apply on the collabora settings page in nextcloud, it queries capabilities from collabora. Among the response is a part that says something about convert to png and says available is false. Yet when I try to open or create a document, nextcloud makes a bunch of HTTP POSTs for that convert to png link, and collabora keeps sending it HTTP 403’s. Result is the same with and without the apache proxy.
Since they’re talking back and forth, this is obviously a software bug, although it’s not clear to me on what side. In any case, I don’t know what to do with it.
Hi KarlF12 & bertino,
do you try my recommendation with Quick setup? Do that work?
Do https://[FQDN-or-IP of your LOOL Server]/hosting/discovery on your config work?
Do you change the settings in the /etc/loolwsd/loolwsd.xml on your LOOL server, especially wopi storage and network settings?
What tell you the nextcloud log in data/nextcloud.log on your nc docker image?
Regards, Ralfi
NECESSARY LOOL configuration changes ABSTRACT /etc/loolwsd/loolwsd.xml
Section [logging]
Set log level to “debug” until everything works; Logging to file [file enable = “true”] makes sense
Section [net desc = “Network settings”]
host desc = “Host …”> [IP Address] …
It is essential to enter all IPv4 or IPv4 mapped IPv6 network addresses from which the LOOL host is to be accessed, and so on. also the public IPv4 address of the router or the Docker Gateway.
Section [ssl desc = “SSL settings”]
First value “Controls whether SSL encryption is enable …” set to “false” if you want to work without internal SSL in the LOOL VM (corresponds to the ENV variable “–o: ssl-enable = false” in the start syntax of the LOOL Docker containers). If Nextcloud accesses LOOL via https / ReverseProxy, this is not a security risk.
Section [Storage desc = “backend storage”]
Section, Allow / deny wopy storage
[host desc = “Nextcloud wopi host” allow = “true”> [FQDN of Nextcloud Instance]]
This value denotes the Nextcloud instance which accesses the services of the LOOL server as WOPI host. So for example the FQDN of the PC who Nextcloud is installed or the Internet FQDN. Corresponds to the ENV variable “domain =” F \ .Q \ .D \ .N "in the boot syntax of the LOOL Docker container
All other parameters can be taken over so far, no installation of additional software packages is necessary. As a result, a separate volume for /etc/lool / may be unnecessary.
I haven’t tried anything else with this recently, but to answer your question: I am not running Nextcloud in docker, nor do I have any plans to do so. I originally installed from snap and then found smbclient was not included in the snap. This was a deal breaker so I threw out the snap and installed from zip. It’s working fine on that end.
I have tried both Collabora and OnlyOffice following information found in a multitude of guides and tried a variety of configurations including with/without proxy and same/separate servers. There is zero possibility of a connection issue because I can do a packet capture and see them talking back and forth. None of it works.
I can see that Nextcloud is sending a bunch of commands to Collabora that Collabora doesn’t like (responds with HTTP 403). I have absolutely entered the Nextcloud server address correctly and have checked it many times and redone it many times. I would very much like to get it working, but I’m at a loss for what else I can do to troubleshoot it.
Hi KarlF12
i really understand your frusticated message, for me it take also a long time to set a really good working environment. But this is not caused by nc or lool, this is in fact really caused by many different ip-/network environments of the user or customer that makes it really difficult - or impossible - to write a universal working guide.
For me the look at the log files in my lool container (see above) AND the nextcloud instances with enhanced log level as described in the nextcloud docs brings me to my working configuration.
And as i say in another threads, first of all try this.
If this run (and its also run with nextcloud:latest and libreoffice-online:master) then if you like we can establish a bidirectional private help session with matrix / riot if you like.
Regards, Ralf
I tried this on my Nextcloud server (using a port other than 80) and the docker version of nextcloud connects with the collabora/code container. I tried it again, with and without SSL, with my production Nextcloud, and it does not work. So why does it work with the docker version of nextcloud but not the zip or snap versions? Ironically docker itself is running from a snap package.
I suppose I could try to migrate my Nextcloud installation to docker if that’s the only way I can get it to work… although I don’t look forward to the task.
Hi KarlF12,
the answer(s) of your questions are in the /etc/loolwsd/loolwsd.xml of the libreoffice-online / collabora-online docker image. You have to modify this file if you want to adapt it to your network config, esp. with your local docker production environment. Without mods its only work as described in the “Quick try” post.
Take a look at network and the backend storage section of the lool config file. IMHO the best way to set the config is an docker user container for /etc/loolwsd/ and also setting the debug log and debug log file modus in /etc/loolwsd/loolwsd.xml. Then you should. set your network environment specs in this file.
Also set the debug mode in your nextcloud config.php.
I looked at the loolwsd.xml file. Below are the unmodified network and storage sections.
<net desc="Network settings">
<proto type="string" default="all" desc="Protocol to use IPv4, IPv6 or all for both">all</proto>
<listen type="string" default="any" desc="Listen address that loolwsd binds to. Can be 'any' or 'loopback'.">any</listen>
<service_root type="path" default="" desc="Prefix all the pages, websockets, etc. with this path."></service_root>
<post_allow desc="Allow/deny client IP address for POST(REST)." allow="true">
<host desc="The IPv4 private 192.168 block as plain IPv4 dotted decimal addresses.">192\.168\.[0-9]{1,3}\.[0-9]{1,3}</host>
<host desc="Ditto, but as IPv4-mapped IPv6 addresses">::ffff:192\.168\.[0-9]{1,3}\.[0-9]{1,3}</host>
<host desc="The IPv4 loopback (localhost) address.">127\.0\.0\.1</host>
<host desc="Ditto, but as IPv4-mapped IPv6 address">::ffff:127\.0\.0\.1</host>
<host desc="The IPv6 loopback (localhost) address.">::1</host>
</post_allow>
<frame_ancestors desc="Specify who is allowed to embed the LO Online iframe (loolwsd and WOPI host are always allowed). Separate multiple hosts by space."></frame_ancestors>
</net>
<storage desc="Backend storage">
<filesystem allow="false" />
<wopi desc="Allow/deny wopi storage. Mutually exclusive with webdav." allow="true">
<host desc="Regex pattern of hostname to allow or deny." allow="true">localhost</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">172\.1[6789]\.[0-9]{1,3}\.[0-9]{1,3}</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">172\.2[0-9]\.[0-9]{1,3}\.[0-9]{1,3}</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">172\.3[01]\.[0-9]{1,3}\.[0-9]{1,3}</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">192\.168\.[0-9]{1,3}\.[0-9]{1,3}</host>
<host desc="Regex pattern of hostname to allow or deny." allow="false">192\.168\.1\.1</host>
<max_file_size desc="Maximum document size in bytes to load. 0 for unlimited." type="uint">0</max_file_size>
</wopi>
<webdav desc="Allow/deny webdav storage. Mutually exclusive with wopi." allow="false">
<host desc="Hostname to allow" allow="false">localhost</host>
</webdav>
</storage>
I used docker cp to get the file and again to put it back. It was throwing an error about the Nextcloud server IP being denied, so I added a line for it and was able to resolve that. Now I’m getting SSL errors.
wsd-00028-00038 2019-06-01 22:41:01.814680 [ websrv_poll ] ERR Socket #23 SSL BIO error: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca (0: Success)| ./net/SslSocket.hpp:281
wsd-00028-00038 2019-06-01 22:41:01.814788 [ websrv_poll ] ERR Error while handling poll for socket #23 in websrv_poll: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca| ./net/Socket.hpp:570
wsd-00028-00038 2019-06-01 22:41:02.527529 [ websrv_poll ] ERR Socket #21 SSL BIO error: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init (EAGAIN: Resource temporarily unavailable)| ./net/SslSocket.hpp:281
wsd-00028-00038 2019-06-01 22:41:02.527614 [ websrv_poll ] ERR Error while handling poll for socket #21 in websrv_poll: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init| ./net/Socket.hpp:570
wsd-00028-00122 2019-06-01 22:41:45.710640 [ docbroker_00d ] WRN Client session [0017] not found to forward message: o141 signaturestatus: 0| wsd/DocumentBroker.cpp:1798
According to the instructions at https://nextcloud.com/collaboraonline/ none of this editing and customizing should be necessary…
@KarlF12 if you can’t succeed and want to start over run one of the playbooks in a new installed ubuntu machine:
I distinctly don’t want to start over. I’ve already done that once moving from snap install to manual install after discovering smbclient can’t be used with the snap version, and had to fix all the devices and do a bunch of extra setup on the server that wasn’t necessary with the snap package.
I’m open to moving to docker if that will make life easier going forward, but I will want to migrate, not start over. It’s a good learning experience. I’ve found a guide on how to do this. I will have to learn some more about how to use docker and get comfortable with the way it stores the data. This was another thing I didn’t like about the snap package. Uninstalling the package apparently wipes all the user data too.
Since I have already installed mariadb on this server for the manual installation, it seems like I should be able to connect the docker nextcloud to my existing database and just migrate the user data into the container, or potentially even use the data folder as it sits. I’m still reading about this process. I’ve been using Ubuntu since version 8 but had never used docker before trying to set up collabora.
did you read the readme?
two commands on the command line + a bit of editing of one file. 20 minutes waiting. ready.
ok. i can’t promise that the smbclient will work. never tested that.
Hi KarlF12,
i tell you 12 day ago …
Section [ssl desc = “SSL settings”]
First value “Controls whether SSL encryption is enable …” set to “false” if you want to work without internal SSL in the LOOL VM (corresponds to the ENV variable “–o: ssl-enable = false” in the start syntax of the LOOL Docker containers). If Nextcloud accesses LOOL via https / ReverseProxy, this is not a security risk.
Section [Storage desc = “backend storage”]
Section, Allow / deny wopy storage
[host desc = “Nextcloud wopi host” allow = “true”> [FQDN of Nextcloud Instance]]
But you should never give up 
I think we need around six or seven steps to the solution …
And again, you need the two logfiles data/nextcloud.log with loglevel 3 and the loolwsd.log from the lool container …
Reiner_Nippes, I tried your Ansible setup. The certificate registration does not work, just ends up with a self-signed. This causes Collabora to also not work, although it does seem to be working when I disable the cert check.
I was hoping to get a look at the Apache config to see if something in there was different from what I was doing, but I see you’re not using Apache. According to Nextcloud, it’s a security issue to have Nextcloud installed at the web root when using other web servers.
Lastly, doing it this way would be fine for my own use, but for security reasons, some of the clients I may eventually install this for would want it done only using official methods. So if I’m going to take the time to learn this software, I really need to do it using the official installation methods.
since they use nginx in their examples i don’t think it’s unofficial and/or a security issue.
which playbook did you use? the docker one or the “bare-metal” one? did you use a “real” fqdn for your server? did you expose port 80&443 to the internet?
where to find the official installation method?
According to the documentation at https://docs.nextcloud.com/server/16/admin_manual/installation/source_installation.html
“When you are running the Apache HTTP server you may safely install Nextcloud in your Apache document root:
…
On other HTTP servers it is recommended to install Nextcloud outside of the document root.”
Just something I noticed. I don’t know what the safety concern involves.
The docmentation of the nginx setup you find here:
https://docs.nextcloud.com/server/16/admin_manual/installation/nginx.html
my nginx.conf
is a copy of
(more or less with some additions due to onlyoffice and collabora.)
I was able to setup a machine with selfsigned certificate on aws running collabora. of course you have to disable certificate validation.
What is your concern here?
For anyone dealing with this same issue, I was able to fix it. This setup still needs some refinement, but as it stands, everything appears to be working as expected. I’m not 100% sure the Coturn configuration is right. I did it with TLS and TCP only. I started a brand new setup on a different network using docker for everything except the apache reverse proxy running on the host. I ran into the same problems. The two sticking points here ended up being some combination of adding static host entries in the containers and running the whole setup in docker-compose. Even with the host entries and using the same docker container options, it still would not work when I had Collabora running with “docker run” and everything else running with docker-compose. Possibly some Docker inter-network issue that would not have applied to my original setup where the only Docker container was Collabora and everything else was on the host.
This is on an Ubuntu Server 18.04 virtual machine running on VMware ESXi. Docker was installed from the official packages, NOT from Ubuntu’s snap. The host is running the Apache proxy and certbot. Everything else is in Docker.
A few other notes about this setup. Certbot put Let’s Encrypt certs in my virtual hosts. I originally set up certbot before adding virtual hosts for Collabora, and so when I added it and reconfigured certbot, it added a subject alternate name for my Collabora domain. They both use the same cert. I also set up a read-only volume so the Coturn container can use the host certbot’s certificate for TLS. I have Nextcloud and MySQL both storing data in a folder on the host since I’m not quite comfortable with the idea of vital data being in a Docker container at this point. And finally, to make sure Coturn gets updated certificates, as a quick and dirty and very unprofessional fix, I set a cron job on the host to restart the Coturn container every Sunday at 4am.
My setup shows no warnings under Settings > Administration > Overview and scores an A rating on https://scan.nextcloud.com/ and A+ on https://www.ssllabs.com/ssltest/.
Here are my config files (with sensitive data replaced of course). This is my working docker-compose:
version: '3.7'
networks:
nextcloud:
services:
mariadb:
image: mariadb
container_name: nextcloud-mariadb
restart: unless-stopped
volumes:
- /var/lib/nextcloud/mariadb:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=mysqlpassword
- MYSQL_PASSWORD=mysqlpassword
- MYSQL_DATABASE=nextcloud
- MYSQL_USER=nextcloud
networks:
- nextcloud
redis:
image: redis
container_name: nextcloud-redis
networks:
- nextcloud
restart: unless-stopped
nextcloud:
# image: nextcloud
build: .
image: nextcloud:smbclient
container_name: nextcloud
networks:
- nextcloud
ports:
- 127.0.0.1:8080:80
volumes:
- /var/lib/nextcloud/html:/var/www/html
extra_hosts:
- "nxc.example.com:192.168.0.10"
- "nxc-office.example.com:192.168.0.10"
depends_on:
- mariadb
- redis
environment:
- NEXTCLOUD_TRUSTED_DOMAINS='nxc.example.com'
- MYSQL_DATABASE=nextcloud
- MYSQL_USER=nextcloud
- MYSQL_PASSWORD=mysqlpassword
- MYSQL_HOST=nextcloud-mariadb
- REDIS_HOST=nextcloud-redis
restart: unless-stopped
coturn:
image: instrumentisto/coturn
container_name: nextcloud-coturn
restart: unless-stopped
ports:
- 3478:3478/tcp
networks:
- nextcloud
volumes:
- /etc/letsencrypt:/etc/letsencrypt:ro
command: ["-n","--log-file=stdout","--external-ip=12.34.56.78","--min-port=49160","--max-port=49200","--realm=nxc.example.com","--no-udp","--use-auth-secret","--static-auth-secret=coturnsecret","--cert=/etc/letsencrypt/live/nxc.example.com/fullchain.pem","--pkey=/etc/letsencrypt/live/nxc.example.com/privkey.pem"]
collabora:
image: collabora/code
container_name: nextcloud-collabora
restart: unless-stopped
networks:
- nextcloud
ports:
- 127.0.0.1:9980:9980
extra_hosts:
- "nxc.example.com:192.168.0.10"
- "nxc-office.example.com:192.168.0.10"
environment:
- 'domain=nxc\\.example\\.com'
- 'dictionaries=en'
cap_add:
- MKNOD
tty: true
The Dockerfile I used to build Nextcloud is to add SMB external storage support. I used the example found here: https://github.com/nextcloud/docker/tree/master/.examples
Here are my virtual hosts. I started them off with the SSL vhosts using the default snakeoil cert and key and let Certbot replace them.
<VirtualHost *:80>
ServerName nxc.example.com
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
RewriteEngine On
RewriteRule ^/\.well-known/carddav http://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/caldav http://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
RewriteCond %{SERVER_NAME} =nxc.example.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
<VirtualHost *:443>
ServerName nxc.example.com
SSLEngine On
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
RewriteEngine On
RewriteRule ^/\.well-known/carddav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/caldav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/nxc.example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/nxc.example.com/privkey.pem
</VirtualHost>
<VirtualHost *:443>
ServerName nxc-office.example.com
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
SSLHonorCipherOrder on
AllowEncodedSlashes NoDecode
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off
ProxyPreserveHost On
ProxyPass /loleaflet https://127.0.0.1:9980/loleaflet retry=0
ProxyPassReverse /loleaflet https://127.0.0.1:9980/loleaflet
ProxyPass /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
ProxyPassReverse /hosting/discovery https://127.0.0.1:9980/hosting/discovery
ProxyPassMatch "/lool/(.*)/ws$" wss://127.0.0.1:9980/lool/$1/ws nocanon
ProxyPass /lool/adminws wss://127.0.0.1:9980/lool/adminws
ProxyPass /lool https://127.0.0.1:9980/lool
ProxyPassReverse /lool https://127.0.0.1:9980/lool
ProxyPass /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities retry=0
ProxyPassReverse /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities
SSLCertificateFile /etc/letsencrypt/live/nxc.example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/nxc.example.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
<VirtualHost *:80>
ServerName nxc-office.example.com
AllowEncodedSlashes NoDecode
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off
ProxyPreserveHost On
ProxyPass /loleaflet https://127.0.0.1:9980/loleaflet retry=0
ProxyPassReverse /loleaflet https://127.0.0.1:9980/loleaflet
ProxyPass /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
ProxyPassReverse /hosting/discovery https://127.0.0.1:9980/hosting/discovery
ProxyPassMatch "/lool/(.*)/ws$" wss://127.0.0.1:9980/lool/$1/ws nocanon
ProxyPass /lool/adminws wss://127.0.0.1:9980/lool/adminws
ProxyPass /lool https://127.0.0.1:9980/lool
ProxyPassReverse /lool https://127.0.0.1:9980/lool
ProxyPass /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities retry=0
ProxyPassReverse /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities
</VirtualHost>
And a list of Apache2 mods-enabled:
access_compat
alias
authn_core
authn_file
authz_core
authz_host
authz_user
auth_basic
autoindex
deflate
dir
env
filter
headers
mime
mpm_event
negotiation
proxy
proxy_http
proxy_wstunnel
reqtimeout
rewrite
setenvif
socache_shmcb
ssl
status
During the setup, I also had to set some extra variables in Nextcloud’s config due to being proxied. With it being in Docker, you do it like this:
docker exec -it -u www-data nextcloud php occ config:system:set trusted_proxies 1 --value='127.0.0.1'
docker exec -it -u www-data nextcloud php occ config:system:set overwritehost --value="nxc.example.com"
docker exec -it -u www-data nextcloud php occ config:system:set overwriteprotocol --value="https"
Hope all that helps someone.
Hi KarlF12,
YEAH!
Nothing else need to tell …
Regards,
Ralfi