richdocumentscode: NC 19 unable to Use Build in Code Server

Same problem for me, on 19 released this morning. I can’t even connect to the built-in CODE

Apche log : tons of PHP Warning: fsockopen(): unable to connect to localhost:9982 (Connection refused) in /var/www/nextcloud/apps/richdocumentscode/proxy.php on line 246PHP

Server details Operating system: Debian Buster

Web server: Apache2

Database: MySQL

PHP version: PHP7.4-fpm

Nextcloud version: 19

Version of the richdocuments app 3.7.0

Version of Collabora Online 4.2.403

@MrReSc @pheiduck: OK, after a long struggle, I’ve finally managed to reproduce this & find out what is the root of the problem: It is that the apache is running on :80 inside the docker, but mapped to :8080 from the outside. So the check that we do inside fails because it tries to reach the :8080 from inside - which returns a 404 of course.

We have a solution in mind, but it’ll take a bit of time to implement I fear; let’s see…

Seems to be semi-working in 20.0.6 - but new bug has arised!

https://github.com/nextcloud/server/issues/25339

So I was also getting

[03-Jun-2020 19:51:14 Europe/Berlin] PHP Warning: fsockopen(): unable to connect to localhost:9982 (Connection refused) in /var/www/server/htdocs/apps/richdocumentscode/proxy.php on line 246

and the lack of any documentation is really frustrating, I had hoped after the onlyoffice debacle with NC18 that wouldn’t repeat, at least the news entry for NC19 states that it’s only for personal use.

So there are a few prerequisites which looks like they aren’t mentioned anywhere - README.md (?).

There’s a Collabora_Online.AppImage executable residing in apps/richdocumentscode/collabora.

After trying to manually launch it su -c "./Collabora_Online.AppImage" -s /bin/bash www-nextcloud

I first got

dlopen(): error loading libfuse.so.2

AppImages require FUSE to run. 
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information

so that’s the first prerequisite.

After I installed fuse2 it wouldn’t of course run since my kernel didn’t include fuse support. fuse: device not found, try 'modprobe fuse' first so recompiling the kernel…

Next I got Failed to load /tmp/.mount_Collabj8lnLI/opt/collaboraoffice6.2/program/libmergedlo.so: libfontconfig.so.1: cannot open shared object file: No such file or directory after installing fontconfig I could finally launch the AppImage and afterwards it also worked fine from within Nextcloud.

Note: Somewhere along the line I also had to add /proc/1/cgroup to my open_basedir and I also installed the php proxy module, not sure if those are actually required though.

I opened the developer console and found an error that’s relevant:

Mixed Content: The page at 'https://cloud.domain.com/apps/files/?dir=/Documents&fileid=122' was loaded over HTTPS, but requested an insecure form action 'http://cloud.domain.com/custom_apps/richdocumentscode/proxy.php?req=/loleaflet/ed4f732/loleaflet.html?WOPISrc=https%3A%2F%2Fcloud.domain.com%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F126_ocbttb0r5cs1&title=Welcome%20to%20Nextcloud%20Hub.docx&lang=en&closebutton=1&revisionhistory=1'. This request has been blocked; the content must be served over HTTPS.

(I replaced my domain). Any ideas? I’m using the built-in CODE server and I’m updated to 19.0.2. This seems like a bug.

Same Issue with Collabora Online - Built-in CODE Server (4.2.406)

I opened the developer console and found an error that’s relevant:

Mixed Content: The page at 'https://cloud.domain.com/apps/files/?dir=/Documents&fileid=122' was loaded over HTTPS, but requested an insecure form action 'http://cloud.domain.com/custom_apps/richdocumentscode/proxy.php?req=/loleaflet/ed4f732/loleaflet.html?WOPISrc=https%3A%2F%2Fcloud.domain.com%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F126_ocbttb0r5cs1&title=Welcome%20to%20Nextcloud%20Hub.docx&lang=en&closebutton=1&revisionhistory=1'. This request has been blocked; the content must be served over HTTPS.

(I replaced my domain). Any ideas? I’m using the built-in CODE server and I’m updated to 19.0.2. This seems like a bug.

I had this issue too - and nobody helped - which made this unusable to me. Somewhere in the CODE setup there seems to be “http://” be hardcoded - even if your domain is setup via “https:” I think in my setup it is related to the use of docker and traefik2 - but i’m not sure about that.

You can reproduce the error if you look into the “F12” network console of your browser and click on an document - that produces this error on my side.

I was having the same problems but finally managed to get this working using the advice in @tgurr’s comment above.

The crux of this issue seems to be that you need to get the Collabora_Online.AppImage executable running in apps/richdocumentscode/collabora.

If you can get this to run, then CODE should run successfully – although I did need to restart my box.

Also, note that the FUSE package in Debian 10 (and presumably derivatives like the latest versions of Ubuntu) is fuse2. So you need to install that and fontconfig.

I was also never able to get the CODE docker instance running. But, at last, I have CODE running and I’m happy. 😃

Update: I didn’t see the latest comments before posting this! 🤦‍♂️ But it looks like we’re all on the same page now. 🎉

Update 2: My resolution is slightly different to the above. Having managed to get the AppImage to execute, I closed it, reset my box, and was then able to activate CODE through the Nextcloud settings interface.

Still same problem with nginx and nextcloud:19-fpm-alpine image in docker with the 404 version…

Let’s close this, then.

@TheSkrypt If you have not been able to find the solution, it has worked for me installing fuse, fontconfig and installing the libraries as explained here: https://github.com/cdr/code-server/issues/766

after executing ./Collabora_Online.AppImage manually in /var/www/html/nextcloud/apps/richdocumentscode/collabora/

Then I checked in the nextcloud control panel by clicking again on use CODE. And works for me!!

Anyone got a solution to this madness? I’ve got fuse installed, fontconfig installed, port opened, yet it’s still saying fsockopen(): unable to connect to localhost:9982 (Connection refused)

This is frustrating as hell 😕

@pascal-ts Thanks so much! I was able to kill the process without rebooting, and also get it to run on startup using the crontab. Here’s what I did for anyone interested:

First find the running collabora process.

sudo netstat -tulpn|grep 9982
tcp6       0      0 :::9982                 :::*                    LISTEN      7497/loolwsd

Then kill it using the pid from the last column, in this case 7497.

sudo kill 7497

Edit the crontab for the www-data user, or whatever user manages nextcloud for you.

sudo -u www-data crontab -e

Add this to the crontab:

@reboot /var/www/html/nextcloud/apps/richdocumentscode/collabora/Collabora_Online.AppImage

Then I opened a tmux session and manually ran the AppImage, but you could just reboot instead.

I had the same issue but was able to fix it, so may this helps!

fresh and updated CentOS 8 vm, Nextcloud 19.0.1, Collabora 3.7.3 and CODE 4.2.602

executing ./Collabora_Online.AppImage manually in /var/www/html/nextcloud/apps/richdocumentscode/collabora/ did the trick. Within the Nextcloud settings I had to say “use your own server” and I used the option to not check the certificate, but that’s fine for me.

Within the terminal netstat -ldp showed that port 9982 is listening but it looks like after a reboot it doesn’t start automatically.

I had to edit /etc/rc.d/rc.local: vi /etc/rc.d/rc.local

and added this line to the end cd /var/www/html/nextcloud/apps/richdocumentscode/collabora/ | ./Collabora_Online.AppImage </dev/null &>/dev/null

afterwards made it executable: chmod +x /etc/rc.d/rc.local

now CODE is autmatically starting and it works like a charm

Question: is it needet to configure additional settings in my apache configuration to use the "“Built-in CODE server”? For my understanding (documentation says nothing) there is no further setting necessary, just install an set the collabora app to the “Built-in CODE server” option. Unfurtunately i cannot use it with the today released version as well.

@kendy You don’t have to build it. sudo docker-compose up in the correct directory should be enough.

@kyrofa Ah cool. Normally the loolwsd has to run under user ‘lool’ and we already have a switch that overrides this - but works only for “any non-root user”. But we should probably allow that even for root; but unfortunately needs a rebuild of the AppImage, hope to include that early next week.

@kendy seems like a good approach. The patch still doesn’t work on the snap and without a log I can’t know for sure, but taking what you did there and running locally gives me a good idea:

# ./Collabora_Online.AppImage --appimage-extract-and-run
terminate called after throwing an instance of 'std::runtime_error'
  what():  Do not run as root. Please run as lool user.
/tmp/appimage_extracted_08b1ce0e45447fbaa468514439b2523c/AppRun: line 35:   917 Aborted                 (core dumped) loolwsd --config-file="${HERE}/etc/loolwsd/loolwsd.xml" --disable-lool-user-checking --port=9982 --lo-template-path="${HERE}/opt/collaboraoffice6.2" --o:sys_template_path="${HERE}/" --o:security.capabilities="false" --o:child_root_path="${WRITABLE}" --o:file_server_root_path="${HERE}/usr/share/loolwsd" --o:ssl.enable="false" --o:net.proxy_prefix="true" --o:storage.wopi.host[0]=".*" --o:storage.wopi.host[0][@allow]="true" --o:memproportion="50" --o:logging.file[@enable]="true" --o:logging.file.property[0][@name]="path" --o:logging.file.property[0]="${WRITABLE}/loolwsd.log" --o:welcome.enable="false" "$@"

Services in the snap run as (confined) root. Is there a way to opt out of that check?

Get the same on docker won’t connect to the Build in Code Server OS: Arch Linux x86_64 Host: vServer 20171111 Kernel: 5.6.15-arch1-1 CPU: AMD EPYC (with IBPB) (2) @ 2.495GHz

root:~/ # netstat -lnpt | grep docker                                                                                                            
tcp6       0      0 :::80                   :::*                   LISTEN      docker-proxy    
tcp6       0      0 :::443                 :::*                   LISTEN     docker-proxy    

installing fuse, fontconfig and restarting php7.4-fpm fixed it for me.

as i can see, after trying to open an document, an ipv6 socket is opened: tcp6 0 0 :::9982 :::* LISTEN 6061/loolwsd …but no ipv4, is this the issue?