Requesting address is denied: ::ffff:172.17.0.1| wsd/LOOLWSD.cpp:1971

[anon50134577]

@kevdog Do you see any other suspicious error in your nextcloud.log file?

[kevdog]

@anon50134577 – I do have that statement within the loolwsd.xml file:

<wopi desc="Allow/deny wopi storage. Mutually exclusive with webdav." allow="true"> <host desc="Regex pattern of hostname to allow or deny." allow="true">nextcloud\.domain\.com</host>

I substituted “domain” here and actually put my real domain name. Unfortunately I still get the same error.

How are you invoking the docker container on the command line?

I’m using the following:

sudo docker run --sysctl net.ipv6.conf.all.disable_ipv6=1 --sysctl net.ipv6.conf.default.disable_ipv6=1 -t -d -p 127.0.0.1:9980:9980 -e 'domain=nextcloud\.domain\.com' --name="jax" -e "username=admin" -e "password=dockercol" --restart always --cap-add MKNOD collabora/code

I’ve used a lot of permutations and whatever I put down always seems to result in the same error:

wsd-00028-00039 2019-02-14 18:59:57.296446 [ websrv_poll ] ERR Requesting address is denied: ::ffff:172.17.0.1| wsd/LOOLWSD.cpp:1971

[nextClo]

Hello kevdog,

I used these commands on the docker host.

with regards

[anon50134577]

@kevdog

I’ve used a lot of permutations and whatever I put down always seems to result in the same error:

wsd-00028-00039 2019-02-14 18:59:57.296446 [ websrv_poll ] ERR Requesting address is denied: ::ffff:172.17.0.1| wsd/LOOLWSD.cpp:1971

I believe that is not a blocking error you should worry about at this time: did you notice some other error that is breaking Collabora?

[kevdog]

@anon50134577

Looking at the docker log file I’m getting this as well:
frk-00031-00031 2019-02-14 19:55:51.864119 [ forkit ] ERR Error: forkit has more than a single thread after pre-init| kit/ForKit.cpp:540

That seems to be the main one.
I’ll post the log here:
https://pastebin.com/5efWScTE
The logfile is almost 2000 lines. Almost impossible to debug. I put logging level at debug

[kevdog]

@anon50134577

Honestly after thumbing through the 2000 line log, the only other problem I’m seeing is this:
(And am I supposed be be generating certs at the top of the log???)

Init vcl
preload: merged unordf ucpchelp1 msforms vbaobj pcr vbaswobj sw animcore hwp flash chartcore solver sc wpftcalc xof ucpcmis1 wpftdraw sd svgfilter evtatt ucpftp1 graphicfilter wpftimpress sdfilt sm:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
pdffilter PresentationMinimizer rptxml:failed
:failed
:failed
:failed
protocolhandler ucpdav1 wpftwriter msword lwpft writerfilter t602filter xmlfa basctl binaryurp uuresolver scd chartcontroller ldapbe2 dba sdbt dbu:failed
:failed
:failed
dbmm:failed
:failed
:failed
deploymentgui migrationoo2 migrationoo3 xsltfilter sdd embobj emboleobj log expwrap odfflatxml textfd storagefd xmlfd frm fwl fwm io textconversiondlgs smd:failed
mozbootstrap oox scfilt OGLTrans:failed
slideshow proxyfac cairocanvas vclcanvas canvasfactory mtfrenderer simplecanvas oglcanvas rptui:failed
:failed
:failed
:failed
:failed
:failed
rpt:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
dlgprov basprov stringresource dbaxml:failed
mork odbc sdbc2 calc dbase flat mysqlc writer xsec_xmlsec reflection bootstrap introspection invocation invocadapt namingservice stocservices cmdmail syssh cached1 ucphier1 ucpimage ucppkg1 srtrs1 ucptdoc1 xsltdlg swd cui bib guesslang offacc:failed
:failed
scn scriptframe dbpool2 xmlsecurity analysis date pricing fps_office:failed
:failed
i18nsearch wizards.agenda.CallWizard wizards.fax.CallWizard wizards.letter.CallWizard emfio vbaevents PresenterScreen:failed
pdfimport abp:failed
dbp:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
:failed
mysql ucpext hyphen spell lnth mailmerge for ctl passwordcontainer svgio updatefeed

[anon50134577]

@kevdog

And am I supposed be be generating certs

I think it’s the intended (albeit convoluted) behaviour of how NextCloud talks with Collabora

The error that you mention a bit earlier, too, doesn’t seem to be a showstopper: see here and here

What was the error again? .ODT documents do not open? Are you experiencing, too, the spinning loading icon that doesn’t disappear?

[kevdog]

Yea on screen its the spinning loading icon that does not disappear. Yes my test documents are .odt. Should I try a different document type?
I assumed the spinning loading icon was due to the error I keep posting…Maybe not?

[anon50134577]

I believe so. The log file you posted looks fine (although I may be not the best person to inspect that).

Asking a basic question, did you configure the Collabora endpoint on NextCloud, right?

[kevdog]

Yes I did configure the endpoint on Nextcloud.

I first attempted a local IP address, but that didn’t work since I suspect that was a cert thing.
I then put in the URL and that’s when I get the spinny thing.

[kevdog]

You know the funny thing is when I go into the web admin console for collobora, the initial web page loads showing the interface then I get a connection error. In the logs I get:

[Thu Feb 14 15:25:37.381571 2019] [proxy:warn] [pid 17119:tid 1405042391
75424] [client 10.0.1.158:39243] AH01144: No protocol handler was valid
for the URL /lool/adminws/ (scheme ‘wss’). If you are using a DSO versio
n of mod_proxy, make sure the proxy submodules are included in the confi
guration using LoadModule.

I’m not sure that has anything to do with it.

[kevdog]

Ok I wanted to add some closure to this topic. I managed to get things up and running and the actual error had nothing to do with it.

I’ll just describe what the problem was and my solution and give anyone a chance to comment on the solution

I originally had a apache webserver located within the DMZ → forwarding to apache webserver located within LAN —> forwarding to collabora docker container running on same machine as the internal LAN apache server.

I believe my problems all stem from the way the SSL certs were being handled. I’m not certain exactly how to handle all the SSL forwarding and certification credentials, so anyone with experience can had input

I have one master SSL cert <domain.com> and the subdomains also are attached to this certificate <nextcloud.domain.com> <office.domain.com>

Solution I’ve come up with is to basically take the back end apache webserver out of the loop (although I’d really like to keep this in).

Current working setup is
apache webserver (DMZ) —> with redirects to port 9980 directly on machine located within LAN.

How I achieved this was the following:

1. Relevant portions of the virtual host file on apache webserver located within DMZ: (Sorry about the formatting guys, I don’t know whats up with this BB)

<Virtualhost *:443>
ServerAdmin admin@domain.com
ServerName office.domain.com
DirectoryIndex /index.php index.php index.html index.htm
DocumentRoot /usr/local/www/office
Options -Indexes

SSLEngine on
SSLCertificateFile /usr/local/etc/letsencrypt/live/domain.com/fullchain.pem
SSLCertificateKeyFile /usr/local/etc/letsencrypt/live/domain.com/privkey.pem

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off
SSLOptions +StrictRequire

# HSTS (mod_headers is required) (15768000 seconds = 6 months) Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"

# Encoded slashes need to be allowed
   AllowEncodedSlashes NoDecode

# Container uses a unique non-signed certificate
        SSLProxyEngine On
        SSLProxyVerify None
        SSLProxyCheckPeerCN Off        
        SSLProxyCheckPeerName Off

        # keep the host
        ProxyPreserveHost On

        # static html, js, images, etc. served from loolwsd
        # loleaflet is the client part of LibreOffice Online
        ProxyPass /loleaflet https://office.domain.com:9980/loleaflet retry=0
        ProxyPassReverse /loleaflet https://office.domain.com:9980/loleaflet

         # WOPI discovery URL
        ProxyPass /hosting/discovery https://office.domain.com:9980/hosting/discovery retry=0
        ProxyPass /hosting/discovery https://office.domain.com:9980/hosting/discovery retry=0

        # Capabilities
        ProxyPass           /hosting/capabilities https://office.domain.com:9980/hosting/capabilities retry=0
        ProxyPassReverse    /hosting/capabilities https://office.domain.com:9980/hosting/capabilities

        # Main websocket
        ProxyPassMatch "/lool/(.*)/ws$" wss://office.domain.com:9980/lool/$1/ws nocanon
       
       # Admin Console websocket
        ProxyPass /lool/adminws wss://office.domain.com:9980/lool/adminws
       
        # Download as, Fullscreen presentation and Image upload operations
        ProxyPass /lool https://office.domain.com:9980/lool
        ProxyPassReverse /lool https://office.domain.com:9980/lool
 
</VirtualHost>

Please note that I have an official office.domain.com.

On the second machine I setup the docker collabora installation, and started the container with the following parameters:

sudo docker run --sysctl net.ipv6.conf.all.disable_ipv6=1 --sysctl net.ipv6.conf.default.disable_ipv6=1 -t -d -p 9980:9980 -e ‘domain=nextcloud\.gohilton\.com’ --name=“jax” -e “username=admin” -e “password=dockercol” --restart always --cap-add MKNOD collabora/code

A couple of things when the starting parameters – I passed the sysctl parameters to disable ipv6 within the container as suggested, and I bound the 9980 listening port directly rather than the typical -p 127.0.0.1:9980:9980 which would only listen on the localhost.

The major issue is that I didn’t want port 9980 on the LAN machine to be exposed to the internet. This was my major stumbling point. The reverse proxy statements required a valid ssl certificate – in my case office.domain.com – however this URL resolved to an external IP address (if using an external DNS server). Since I’m not running an internal DNS server, I ended up modifying the /etc/hosts file on the computer running the apache webserver.

I added the following:

10.0.1.162 office.domain.com

10.0.1.162 represented the internal LAN address of the VM host running the docker instance.

My only exposed ports in the DMZ were 80/443.

With this setup, the docker collabora setup seems to be working – no more spinning icon – however the docker log files still produced the following error:

wsd-00028-00039 2019-02-15 16:12:43.064003 [ websrv_poll ] ERR FileServerRequestHandler::NotAuthenticated: No authentication information found| wsd/FileServer.cpp:414

And occasionally I get this error as well

wsd-00028-00039 2019-02-15 16:12:43.063898 [ websrv_poll ] WRN client - server version mismatch, disabling browser cache.| wsd/FileServer.cpp:279

I don’t know how to interpret these errors, but just to report everything seems to work.

I’m not sure if this setup is correct however it works in my case. I’m running the Apache webserver within a FreeNAS jail running Freebsd. The docker container is running within a VM running Ubuntu linux. Perhaps a different setup would help.

Thanks for everyone’s help in trying to resolve the issue.

[anon50134577]

thanks for the writeup happy you could make it work.

[kevdog]

Couple more things I wanted to add. I’m not sure how many people check these forums however the forums were invaluable to me when spending hours trying to get things up and working

References (Source of information – along with some Google-Fu):

1. https://www.collaboraoffice.com/code/apache-reverse-proxy/

2. https://www.virtualmin.com/node/60056

3. Setting up and configuring collabora/code Docker image - Collabora Office and Collabora Online

4. Integrate Collabora Online with Nextcloud on Ubuntu with Docker

5. https://markus-blog.de/index.php/2018/09/10/how-to-deploy-collabora-online-office-without-docker-in-plesk-and-connect-to-nextcloud-on-ubuntu/

6. Collabora Online Development Edition (CODE) - Collabora Office and Collabora Online

7. https://www.samueldowling.com/2018/12/08/install-nextcloud-on-freenas-iocage-jail-with-hardened-security/

Instructions Applicable only if trying to run the collabora docker plugin. I didn’t build collobora from scratch, so some if the information presented below probably isn’t going to be relevant, however salient points probably could be inferred.

Useful commands:

sudo docker ps <----- Shows status of docker

sudo docker stop <container id> <----- Stops docker container given either ID/container name

sudo docker start <container id> <------Starts docker container given either ID/container

sudo docker rm <container id> <--------Use this command if container fails to start or you just really get stuck. (I had to use this command a lot)

sudo docker logs <container id> or
sudo docker logs --tail 50 --follow --timestamps <container id> <—Useful to see what’s going on with your docker instance if something isn’t working.

docker exec -it <container id> /bin/bash <—Command to get terminal prompt within docker container. Filesystem is mounted read-only, so its helpful to view files, but its also possible to change the ownership of files.

When starting up the container, this is command I used:

sudo docker run --sysctl net.ipv6.conf.all.disable_ipv6=1 --sysctl net.ipv6.conf.default.disable_ipv6=1 -t -d -p 9980:9980 -e ‘domain=nextcloud\.domain\.com’ --name=“jax” -e “username=admin” -e “password=dockercol” --mount type=bind,src=/etc/letsencrypt,target=/etc/letsencrypt,readonly --restart always --cap-add MKNOD collabora/code

Explanation
–sysctl net.ipv6.conf.all.disable_ipv6=1 Ensures ipv6 is disabled

–sysctl net.ipv6.conf.default.disable_ipv6=1 Ensures the ipv6 service is disabled when restarting. Both these lines were included based on prior suggestions contained within this thread to disable ipv6

-p 9980:9980 - Based on my setup I wanted to bind dockers listening port 9980 to the machines listening port for all incoming address. Most documentation is going to tell you to do -p 127.0.0.1:9980:9980. This variant is fine if if the docker collabora instance is being run on the same machine as the apache/ngnix webserver. In my situation however my collabora instance is running within a VM within the LAN on a different server

-name=“jax” - You can choose any name here however I set this parameter so the container is always started/stopped etc with the same name. In my example used below my <container id>=jax Makes it a lot easier to troubleshoot if container is always loaded and started with same id

-e “username=<ANYNAME>” , -e “password=<ANYPASS>” – Only need these parameters if wanting to use the collabora admin console – I used this definitely for debugging. If I could reach the admin console, I knew that at least the container was able to startup and I could read for basic uinput . The admin console is going to be reached at:

https://<codebase>/loleaflet/dist/admin/admin.html

<codebase> refers to the URL of the machine that the collabora docker container is running. If this is on the same machine as the nextcloud instance, the codebase name will probably be something like nextcloud.domain.com. If the collabora docker image is being run on a different machine, than the URL needs to be name a URL with a valid SSL cert.

– Side Note: If routing to a different machine on the LAN, I named a LAN machine office.domain.com, (I appended this subdomain to my main domain LetsEncrypt certificate – Instructions: User Guide — Certbot 2.7.0.dev0 documentation and look for section with example: certbot certonly --cert-name example.com -d example.org,www.example.org). In routing to this internal LAN machine (which is actually a FreeNAS ubuntu VM), I modified the /etc/host file of the machine running apache/nextcloud to map office.domain.com to the internal LAN address of the VM. This negated me needing to run a local DNS server or expose port 9980 to the WAN. Depending on your setup, this may or may not be needed.

–mount type=bind,src=/etc/letsencrypt,target=/etc/letsencrypt,readonly
This command is totally optional however all my certificates are kept in one directory on a local machine. The other machines that need access to these certificates either mount the directory within a jail type structure (if using FreeNAS/BSD), or within a NFS share. I share the SSL certificate directory whereby the directories are mounted as read-only for those machines needing access. My setup is so when I renew my certs, the certs are all renewed in one directory and then the shares are automatically updated as well. This is just one strategy for sharing certs among different machines. These certs must be available as well to docker collabora container. (See discussion below regarding the loolwsd.xml file).

–restart always - Docker will restart the machine automatically if machine goes down or experiences error. (usually the behavior you want unless your modifying the contents of the container – see below in the discussion regarding the certificates).

My docker collabora container is started with these parameters as discussed aboive , however additional parameter are contained within a file named loolwsd.xml which is owned by lool:lool (More in this in a minute). This file is located within the container itself within the /etc/loolwsd directory. In many cases its vary useful to get a terminal prompt within the docker container to inspect various files such as loolwsd.xml for debugging purposes.

Although it possible to start the collabora docker container with most of the default settings, in many cases additional settings need to be tweaked in order for the container to work. Container settings are either passed on the command line (which takes precedence) or read from a global configuration file known as loolwsd.xml.
To modify the loolwsd.xml file I first needed to copy the file from the container (I ran this under the root user or with sudo)

docker cp <container id>:/etc/loolwsd/loolwsd.xml loolwsd.xml <–Copies the config file from docker container to local file

As root user its possible to edit the file (vi, nano, any other editor) and make changes to the various fields. In regards to the LetsEncrypt SSL certs (which were mounted as above), I modified this file like this:

<ssl desc="SSL settings">
    <enable type="bool" desc="Controls whether SSL encryption is enable (do not disable for production deployment). If default is false, must first be compiled with SSL support to enable." default="true">true</enable>
    <termination desc="Connection via proxy where loolwsd acts as working via https, but actually uses http." type="bool" default="true">false</termination>
    <cert_file_path desc="Path to the cert file" relative="false">/etc/letsencrypt/live/domain.com/cert.pem</cert_file_path>
    <key_file_path desc="Path to the key file" relative="false">/etc/letsencrypt/live/domain.com/privkey.pem</key_file_path>
    <ca_file_path desc="Path to the ca file" relative="false">/etc/letsencrypt/live/domain.com/chain.pem</ca_file_path>
    <cipher_list desc="List of OpenSSL ciphers to accept" default="ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"></cipher_list>
    <hpkp desc="Enable HTTP Public key pinning" enable="false" report_only="false">
        <max_age desc="HPKP's max-age directive - time in seconds browser should remember the pins" enable="true">1000</max_age>
        <report_uri desc="HPKP's report-uri directive - pin validation failure are reported at this URL" enable="false"></report_uri>
        <pins desc="Base64 encoded SPKI fingerprints of keys to be pinned">
        <pin></pin>
        </pins>
    </hpkp>
</ssl>

Additional settings can be added or removed as many other usser have suggested within this thread. Please take a look at the file to familiarize yourself with the various options.

The configuration file needs to be written back to the container. The original ownership of the loolwsd.xml file was lool:lool and modifications were done under the root user (root:root). You can not directly cp the file into the container because permissions will not be correct (Documentation of this fact would have save me hours of debugging!!). In order to correctly cp the xml file back to the container do the following:

1. Stop the container - sudo docker stop <container id>
2. Remove the container - sudo docker rm <container id>
3. Restart the container (HOWEVER DO NOT START WITH THE --restart always flag) !!VERY IMPORTANT. For my setup the command would be:

sudo docker run --sysctl net.ipv6.conf.all.disable_ipv6=1 --sysctl net.ipv6.conf.default.disable_ipv6=1 -t -d -p 9980:9980 -e ‘domain=nextcloud\.domain\.com’ --name=“jax” -e “username=admin” -e “password=dockercol” --mount type=bind,src=/etc/letsencrypt,target=/etc/letsencrypt,readonly --cap-add MKNOD collabora/code

4. Copy the loolwsd.xml file back to the container:
   sudo docker cp loolwsd.xml <container id>:/etc/loolwsd/loolwsd.xml

5. Login into the container:
   sudo docker exec -it <container id> /bin/bash

6. Modify the ownership of the loolwsd.xml
   chown lool:lool /etc/loolwsd/loolwsd.xml

7. Exit the container with exit command

8. Stop and remove container
   sudo docker stop <container id>
   sudo docker rm <container id>

9. Restart the container with the --restart always flag

sudo docker run --sysctl net.ipv6.conf.all.disable_ipv6=1 --sysctl net.ipv6.conf.default.disable_ipv6=1 -t -d -p 9980:9980 -e ‘domain=nextcloud\.domain\.com’ --name=“jax” -e “username=admin” -e “password=dockercol” --mount type=bind,src=/etc/letsencrypt,target=/etc/letsencrypt,readonly --restart always --cap-add MKNOD collabora/code

Unfortunately these 9 steps need to be repeated if the loolwsd.xml file would need any additional modifications or revisions. It’s possible to pass the options to the container on the command line to avoid this step, however in my experience the syntax begins to become very difficult.

Hopefully this helps someone in the future. Sorry about the long post.

[dgferrin1]

Its very nice to find people like you in this forums, ty very much for this info i think we are many with the same problem, its easy to get info about how docker works but not that much when its related to nextcloud and collabora issues, so good job ill give it a try to fix mine as soon as i get time to start working with it.

[Schleichmichl]

I had same problems. I could create a working instance by setting extra_params. Nothing additional.

The important param that works around the error message is: --o:net.proto=IPv4

docker-compose extract:

 collabora-nc:
    container_name: 'collabora'    
    environment:
     - username=admin 
     - password=***
     - extra_params=--o:server_name=collabora\.domain\.de --o:ssl.enable=false --o:ssl.termination=true --o:net.post_allow.host=::ffff:172\.29\.0\.[0-9]+ --o:net.post_allow.host=172\.29\.0\.[0-9]+ --o:net.proto=IPv4
     - domain=domain\.de
    image: collabora/code:latest
    restart: unless-stopped        
    networks:
      - myNetwork