Well, this is embarrassing

Actually this should not be a game trying to guess the right options.

I expect a documented way of getting this to work.

Besides that, what should I expect from a solution that works for some users and does not for others?
I don’t really think that - especially in my case - this is a configuration issue.

Otherwise it wouldn’t work for any user…

And it’s about how this solution is being pushed. Nowhere does it say this is an alpha version that may work if you’re lucky.
Not on this page:
https://nextcloud.com/collaboraonline/
and not on this one either:

It even calls this version 2.0.
Which to me sounds like the worst bugs should be fixed.

source: Support - Nextcloud

… perhaps someone wants “Enterprise suppor” :v:

We still have to remember that we can use all this for free !!!

No reason to be so upset.

1 Like

What’s the use of getting something for free - if it doesn’t work?

I mean from looking that collabora topic:


seems to me that instances where this works seem rather sparse.

1 Like

Maybe some of the problems come from the Collabora Office Docker Toy being intentionally crippled so that only x users may be able to use it or one may only open y documents?
I can understand that Collabora wants to earn money with their work.
But there is not even a declaration on where the limits are set.

Worked for me. Had the same problem till nextcloud 10 and collabora update.
Thank you.

Thanks for the tip it works well now.

Embarrassing indeed. I changed the line in my Apache config as mentioned and it works now. Please change this also in the documentation so others won’t stumble over it too!

Please create an issue on Issues ¡ nextcloud/documentation ¡ GitHub that it can be fixed. Pull request is as well welcome.

You have the correct documentation over here :

https://nextcloud.com/collaboraonline/

Thanks for updating the documentation.

In the Virtual Host configuration, for the Main websocket section use:
ProxyPassMatch “/lool/(.*)/ws$” wss://127.0.0.1:9980/lool/$1/ws nocanon

instead of previous:
ProxyPass /lool/ws wss://127.0.0.1:9980/lool/ws

Cool.
I’m not getting the ‘Well this is embarrassing’ message any more.
After the update as of today, I’m in fact not getting anything anymore.
If I click on an office document, all I get is a grey background.

This is all very discouraging.
My guess it has to do with these stupid limitations put into collabora office.
Of course we have several hundred users on our Nextcloud.
But if there is exactly one of them (me) trying to use Collabora Office, I think it has to work.
Or do these limitations apply to the number of users in the Nexcloud instance?
If more than ten then don’t work or something?

It might be the DNS of the container as many don’t think of it as a client, I didn’t anyway :slight_smile:
Docker just copies the resolv.conf of the host and with internal installs sometimes that just does not work

But some stuff to check and post, Nextcloud do, do support… But can run you through some stuff.

To check the DNS/Certs entry.
nslookup subdomain.example.com
openssl s_client -connect subdomain.example.com:443
Check from clients, server and container.
Docker, wasn’t very keen at first but actually become to like it.
docker ps -a #list all containers.
docker stop [container-id] #stop container
docker rm [container-id] #delete container
docker images #list all images
docker rmi [image-id] #delete image
docker exec -i -t [container-id] /bin/sh #run shell inside container
docker logs [container-id] #view log
docker info #environment setup

Docker info is a good place to start as it will also give distro and backend storage details as there is much variance in distro aufs support, post results here.

docker exec -i -t [container-id] /bin/sh allows you to enter a root shell in the container and you can install software such as dnsutils or nano to check things out and edit.

If you are behind a subnet DNS then 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

with --dns=192.168.1.2 making sure the container is pointing correctly at the right DNS server.

If its aufs that is the problem like on Debian or Ubuntu if sudo apt-get install -y --no-install-recommends
linux-image-extra-$(uname -r)
linux-image-extra-virtual
Hasn’t been run device-mapper does.

Might be aufs and an easy way is to swap to device-mapper instead.

Docker info will show Storage Driver: aufs and it doesn’t work and we can change to devicemapper

grep ExecStart /lib/systemd/system/docker.service

will return something like the below which we need to place in a system.d conf file
ExecStart=/usr/bin/dockerd -H fd://
mkdir /etc/systemd/system/docker.service.d
nano /etc/systemd/system/docker.service.d/execWithDeviceMapper.conf
Create like so (paste):
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd --storage-driver=devicemapper -H fd://

Dunno why it has a first blank ExecStart= but I copied it verbatim and it works.

systemctl daemon-reload
systemctl restart docker.service

docker logs [container-id] post here as much is outside the scope of the nextcloud logs.

openssl s_client -connect subdomain.example.com:443 run from client & container will also check certs at the same time as DNS and save installing dnsutils.

5 posts were split to a new topic: FTL Capability error

11 posts were split to a new topic: Collabora in docker on armbian

How do you write that line in nginx?
My current nginx-equivalent lines which don’t work are these:

location ~ /lool/(.*)/ws$ {
proxy_pass https://localhost:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “Upgrade”;
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;

some thoughts on fixing decoding issue:

add_header X-Download-Options open;

add_header X-Permitted-Cross-Domain-Policies all;

if ($request_uri ~* “/lool/(.*)/ws$”) {

proxy_pass https://localhost:9980/$uri;

proxy_pass http://tracking/webapp/$1;

}

#rewrite ^ $request_uri;
#rewrite ^/lool/(.*)/ws$ $1 break;
#return 400; #if the second rewrite won’t match
#proxy_pass http://127.0.0.1:82/$uri;
}

This topic was automatically closed after 2 days. New replies are no longer allowed.

I just cleaned this topic a bit. Please stay with the topic of @Kay. If you have other problems, please use your own threads.

Hello Kay,

While i was doing my collabora installation I also had the unauthorized WOPI host and i came to the conclusion that this error is due to inserting the wrong hostname into the sudo letsencrypt certonly --webroot --email your-email-address -d office.your-domain.com -w /usr/share/nginx/office/ command, so double check you have written the url of your Nextcloud server correctly.

Furthermore, i have collabora and nextcloud setup in two different ubuntu server, since i experienced alot of latency when i had both in the same ubuntu server.

Finally, i think your nigix config should look like this;

server {
  listen 443 ssl;
  server_name office.your-domain.com;
  root /usr/share/nginx/office;

  ssl_protocols TLSv1.1 TLSv1.2;
  ssl_certificate /etc/letsencrypt/live/office.your-domain.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/office.your-domain.com/privkey.pem;

  # static files
  location ^~ /loleaflet {
    proxy_pass https://localhost:9980;
    proxy_set_header Host $http_host;
  }

  # WOPI discovery URL
  location ^~ /hosting/discovery {
    proxy_pass https://localhost:9980;
    proxy_set_header Host $http_host;
  }

  # websockets, download, presentation and image upload
  location ^~ /lool {
    proxy_pass https://localhost:9980;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;
  }
}

I have used this configuration before with Nginx and it worked, but i definitely recommend using apache reverse proxy for better performance.

Saludos from Spain, Pablo.