No se puede acceder a Collabora después de una nueva instalación

Tengo una instalación existente de Ubuntu 16.04 con nextcloud instalado /var/www/cloud(wordpress está en la raíz). Ha estado funcionando bien por un tiempo, pero recientemente descubrí Collabora como una alternativa a los documentos de Google y REALMENTE quiero que esto funcione. Cuando intento abrir un documento, recibo un error de "Acceso prohibido". He instalado Collabora de acuerdo con las instrucciones que se encuentran aquí.

He comprobado la salida de lsof -i y puedo ver a Docker escuchando en 9980, configuré la URL en Nextcloud y, sinceramente, no estoy realmente seguro de cómo comenzar a solucionar este problema. Si alguien de la comunidad pudiera darme alguna orientación, sería increíble. Alguna información adicional está abajo.

Entradas de apache error.log ubicado en / 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

Versión desinfectada de My Apache config para el vhost colaborador :

<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>

La dirección de mi instancia de nextcloud es domain.com/cloud

salida de lsof -i | grep docker Creo que esto muestra que el contenedor de docker está escuchando el tráfico del localhost en 9980 para enviar al contenedor

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

Teoría : Tengo la teoría de que probablemente tendré que configurar nextcloud nuevamente esta vez, con nextcloud en la raíz web y mi blog en una carpeta dentro de la raíz web porque el ambiente que obtengo de la documentación es que se espera que nextcloud sea en su propia máquina con su propio nombre de dominio y este servicio se conecta a un subdominio de ese nombre de dominio raíz. así que domain.com/cloud está lanzando todo para un bucle

si alguien pudiera darme alguna orientación, lo agradecería enormemente, ya que nextcloud es un producto en el que estoy realmente interesado en invertir.

Esta publicación de Mike Griffen aborda solo este problema, y ​​parece ser una solución simple.

Authz_core:error Client Denied by Server Configuration

... mod_authz_corese introdujo en Apache2.3. Esto cambia la forma en que se declara el control de acceso

desde:

Order allow, deny
Allow from all

a:

Require all granted

Esto significa que la configuración total para un Directorio ahora es algo así como:

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

Reinicia Apache y todo funcionará bien.