Iāve been having a look at the latest Nextcloud VM image, built by TechAndMe. It seems really solid, with a great setup script. During setup, one of the options is to install Libreoffice support - does this install Collobora Libreoffice Online server within the VM?
If so, are there any details on how to configure it to get it working? If not, is there a guide to the recommend way of setting up Collabora to work with the official VM?
Thanks.
@Ripper Thanks for your feedback!
During the setup script you are presented to install certain apps, Collabora is one of them. The script is still in BETA but should work. I canāt tell you 100% becuase we havenāt got any feedback from user yet as itās kind of new.
It would be super great if you could run the install script and see if it sets up properly and if not, please report the issue to Github: https://github.com/nextcloud/vm/issues/new
If you already have your VM setup, then just run sudo bash /var/scripts/collabora.sh
Thanks!
Thanks for getting back to me.
So, when I ran the setup, I selected the Libreoffice option. It asked me to ensure that port 443 was open, presumably for LetsEncrypt to do its thing. I gave it a subdomain name, and everything seemed to succeed.
Once setup was complete, I assumed the next thing to do was to enable the Collabora app. Having done so, clicking on a Libreoffice doc just brings up a page saying āaccess forbiddenā.
Looking in the admin settings, there is a field required for the URL and port of the Collabora server, but my guesses havenāt worked.
I havenāt previously setup a Collabora server, so I donāt have any knowledge about how to setup the integration, the subdomain, etc.
If you follow the instructions, you see that one subdomain is for the docker image and one is your cloud domain.
Did you get any error message during the script?
Yep - I followed the instructions. Entered both the main domain for Nextcloud, and the subdomain for Collabora, in the format required. No errors during script.
Itās possible that the Collobora server is running happily, but Iām just not successfully connecting it to Nextcloud. Can you tell me what to enter in the server field in the Collabora app? Is it in the format:
subdomain.domain.com:port number
I just noticed a few bugs in the script, and they are fixed now. Please download the script again and run it manually.
Then tell me the result.
Thanks!
I downloaded the new collabora.sh script from github, replaced the existing one in /var/scripts, and re-ran it. It throws a syntax error on line 5.
/var/scripts/collabora.sh: line 5: syntax error near unexpected token newline' /var/scripts/collabora.sh: line 5:!DOCTYPE htmlā
Ah, you need to download the RAW script. Press the RAW button and use that address.
You can also use wget to fetch it directly.
Doh!
Right, I sorted that out, and re-ran the script. Very different this time round - it took much longer, it downloaded a lot of files, and clearly was doing what it should have done the first time.
But, at the end of the process, it threw an error about apache. Now apache no longer seems to start, and Nextcloud is not accessible. Perhaps some complication from running the script a second time - would it make sense to start with a fresh installation?
I went ahead and fired up a new instance. I can still take a look at the old VM if you want to investigate anything.
The new setup went smoothly, and the collabora.sh script completed successfully. Both Nextcloud and the Collabora subdomain seemed to generate their LetsEncrypt certs successfully.
Logging in to Nextcloud, I enabled the Collabora app, then went into the admin settings and set the address to the subdomain. Now, when clicking on a document, the CODE interface opens, with the toolbar visible, but it gives this message:
āWell, this is embarrassing, we cannot connect to your document. Please try again.ā
Yup, added a few more checks and now Collabora installs as it should. Finally. 
Yeah, got that error message too, but it started to work after like 5 minutes or so, very strange. Give it some time and see if it sort it self, otherwise please help me investigate.
Thanks for your help!
First thing I did was to reboot the VM, and itās been running now for a couple of hours, but unfortunately the error remains. I assume thereās a log file or two I should look at?
Okay, yeah the logs could be useful.
Please post the output of https://docs.docker.com/engine/reference/commandline/logs/ and the Apache error log, and also the Apache access log.
Then if you hit inspect in Chrome (right click the mouse button) you can fire up the browser logs as well.
Letās hunt this bug!
FYI, I added a final PR after you wrote yesterday. Please fire up a new VM and try again to be sure you got all the latest stuff.
I fired up another VM. Iām using new extractions of the the same VM image archive I downloaded from TechAndMe a few days ago, but, as far as I can tell, itās downloading the latest scripts as part of the installation, so I assume thatās OK.
Still getting the same results.
The output you asked me to post in your previous response seems to be an unrelated web address - do you know what it should be for my local server?
During the setup script, I noticed a couple of error messages. During the main Nextcloud setup, I saw this:
Ok, now the last part - a proper SSL cert.
The following script will install a trusted
SSL certificate through Letās Encrypt.
Do you want to install SSL? ([y]es or [N]o): y
/var/scripts/activate-ssl.sh: line 22: git: command not found
However, the generation of the certificates seems to succeed, and the main Nextcloud server shows a valid SSL connection.
Then, during the collabora.sh script, I saw this:
Creating virtual environmentā¦
Installing Python packagesā¦
The directory ā/home/ncadmin/.cache/pip/httpā or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudoās -H flag.
The directory ā/home/ncadmin/.cache/pipā or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudoās -H flag.
Installation succeeded.
Again, after this, everything seems to succeed.
Yup, I know about those outputs.
So the Collabora works now?
Unfortunately not. As I said - same result.
āWell, this is embarrassing, we cannot connect to your document. Please try again.ā
Hmmā¦ I dināt have a good answer here. Check with the Collabora devs.
Would be great if we could find the cause for this behavoiur.
I seem to have found the problem. Looking at the docker log, I saw these errors:
ERR Unknown resource: /lool//ws/lool/https%3A%2F%2Fcloud.mydomain.com%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F37_ocae6u5q3hhs%3Faccess_token%3Duc6XUKZirEw0LrQcKhVm7MQkR612MNgD%26access_token_ttl%3D0%26permission%3Dedit/ws| wsd/LOOLWSD.cpp:1223
So, I trawled through the config files, to see if anything looked off. I found this in /etc/apache2/sites-available/office.mydomain.com.conf:
Main websocket
ProxyPassMatch ā/lool/(.*)/ws$ā wss://127.0.0.1:9980/lool//ws nocanon
It seems from looking at other peopleās configs, this is missing $1 between the slashes.
Main websocket
ProxyPassMatch ā/lool/(.*)/ws$ā wss://127.0.0.1:9980/lool/$1/ws nocanon
Having made that change, it works fine now. Iām puzzled how my setup yielded this syntax error, and yet for others it must be working?