Cannot access collabora after fresh install

I have an existing installation of Ubuntu 16.04 with nextcloud installed into /var/www/cloud (wordpress is in the root). It's been running fine for a while now but I recently discovered collabora as an alternative to google docs and REALLY want this to work. When I try to open a document I receive an "Access Forbidden" error. I have installed collabora according to the instructions found here

I've checked the output of lsof -i and can see docker listening on 9980, Configured the URL in Nextcloud, and barehonestly I'm not really sure how to go about starting to troubleshoot this issue. If anyone from the community could give me some guidance that would be amazing. Some additional information is below.

Entries from apache error.log located in /var/log/apache2:

[Mon Jan 02 22:05:30.027625 2017] [authz_core:error] [pid 26396] [client <IPADDRESS>:54120] AH01630: client denied by server configuration: /var/www/html/cloud/data/.ocdata
[Mon Jan 02 22:05:32.314370 2017] [authz_core:error] [pid 3122] [client <IPADDRESS>:54123] AH01630: client denied by server configuration: /var/www/html/cloud/data/.ocdata

Sanitized version of My Apache config for the collabora vhost:

<VirtualHost *:443>
  ServerName sub.domain.com:443

  # SSL configuration, you may want to take the easy route instead and use Lets Encrypt!
  SSLEngine on
  SSLCertificateFile /etc/letsencrypt/live/domain.com/fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/domain.com/privkey.pem
  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$
  SSLHonorCipherOrder on

  # Encoded slashes need to be allowed
  AllowEncodedSlashes     On

  # 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://127.0.0.1:9980/loleaflet retry=0
  ProxyPassReverse           /loleaflet https://127.0.0.1:9980/loleaflet

  # WOPI discovery URL
  ProxyPass    /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
  ProxyPassReverse           /hosting/discovery https://127.0.0.1:9980/hosting/discovery

  # Main websocket
  ProxyPassMatch    "/lool/(.*)/ws$" wss://127.0.0.1:9980/lool/$1/ws

  # Admin Console websocket
  ProxyPass /lool/adminws wss://127.0.0.1:9980/lool/adminws

  # Download as, Fullscreen presentation and Image upload operations
  ProxyPass   /lool https://127.0.0.1:9980/lool
  ProxyPassReverse           /lool https://127.0.0.1:9980/lool
  ServerAlias    sub.domain.com
</VirtualHost>

The Address of my nextcloud instance is domain.com/cloud

output of lsof -i | grep docker I believe this shows the docker container is listening for traffic from the localhost on 9980 to send to the container

docker-pr  1634     root    4u  IPv4  19492      0t0  TCP localhost:9980 (LISTEN)

Theory: I have a theory that I will probably need to setup nextcloud again this time with nextcloud being in the webroot and my blog being in a folder inside the webroot because the vibe I'm getting from the documentation is that nextcloud is expected to be on it's own machine with it's own Domain name and this service connect to a subdomain of that root domain name. so the domain.com/cloud is throwing the whole thing for a loop

if anyone could give me some guidance I would be greatly appreciative as nextcloud is a product I'm really interested in investing in.

Solution 1:

This post by Mike Griffen addresses just this issue,and it appears to be a simple solution.

Authz_core:error Client Denied by Server Configuration

... mod_authz_core was introduced in Apache2.3. This changes the way that access control is declared

from:

Order allow, deny
Allow from all

to:

Require all granted

This means that the total configuration for a Directory is now something like:

<Directory /path/to/directory>
     Options FollowSymlinks
     AllowOverride none
     Require all granted
</Directory>

Restart apache and it’ll all work nicely.