Impossible d'accéder à Collabora après une nouvelle installation

J'ai une installation existante d'Ubuntu 16.04 avec nextcloud installé dans /var/www/cloud(wordpress est à la racine). Cela fonctionne bien depuis un certain temps maintenant, mais j'ai récemment découvert la collaboration comme une alternative aux documents Google et je veux vraiment que cela fonctionne. Lorsque j'essaie d'ouvrir un document, je reçois une erreur "Accès interdit". J'ai installé collabora selon les instructions trouvées ici

J'ai vérifié la sortie de lsof -i et je peux voir docker écouter sur 9980, Configurer l'URL dans Nextcloud et, honnêtement, je ne sais pas vraiment comment commencer à résoudre ce problème. Si quelqu'un de la communauté pouvait me donner des conseils, ce serait incroyable. Quelques informations supplémentaires sont ci-dessous.

Entrées du fichier apache error.log situé dans / 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

Version aseptisée de ma configuration My Apache pour le 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>

L'adresse de mon instance nextcloud est domain.com/cloud

sortie de lsof -i | grep docker Je crois que cela montre que le conteneur docker écoute le trafic provenant de l'hôte local sur 9980 à envoyer au conteneur

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

Théorie : J'ai une théorie selon laquelle je devrai probablement configurer à nouveau nextcloud cette fois avec nextcloud étant dans le webroot et mon blog étant dans un dossier à l'intérieur du webroot parce que l'ambiance que je reçois de la documentation est que nextcloud devrait être sur sa propre machine avec son propre nom de domaine et ce service se connecte à un sous-domaine de ce nom de domaine racine. donc le domaine.com/cloud lance le tout pour une boucle

si quelqu'un pouvait me donner des conseils, je serais très reconnaissant car nextcloud est un produit dans lequel je suis vraiment intéressé à investir.

Cet article de Mike Griffen ne traite que de ce problème et il semble que ce soit une solution simple.

Authz_core:error Client Denied by Server Configuration

... a mod_authz_coreété introduit dans Apache2.3. Cela change la façon dont le contrôle d'accès est déclaré

de:

Order allow, deny
Allow from all

à:

Require all granted

Cela signifie que la configuration totale d'un répertoire est maintenant quelque chose comme:

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

Redémarrez apache et tout fonctionnera bien.