Não é possível acessar a collabora após a instalação nova

Eu tenho uma instalação existente do Ubuntu 16.04 com nextcloud instalado /var/www/cloud(o wordpress está na raiz). Ele está funcionando bem há um tempo, mas recentemente descobri a colaboração como uma alternativa ao Google Docs e REALMENTE quero que isso funcione. Quando tento abrir um documento, recebo o erro "Acesso proibido". Eu instalei o collabora de acordo com as instruções encontradas aqui

Verifiquei a saída de lsof -i e posso ver o docker ouvindo no 9980, configurei o URL no Nextcloud e, simplesmente, não tenho muita certeza de como começar a solucionar esse problema. Se alguém da comunidade pudesse me dar alguma orientação, isso seria incrível. Algumas informações adicionais estão abaixo.

Entradas do apache error.log localizado em / 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

Versão higienizada da configuração do My Apache para o 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>

O endereço da minha instância nextcloud é domain.com/cloud

saída de lsof -i | grep docker Eu acredito que isso mostra que o contêiner do docker está escutando o tráfego do host local no 9980 para enviar para o contêiner

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

Teoria : Eu tenho uma teoria de que provavelmente precisarei configurar o nextcloud novamente desta vez, com o nextcloud no webroot e o meu blog em uma pasta dentro do webroot porque a vibração que estou obtendo da documentação é que o nextcloud deve ser em sua própria máquina com seu próprio nome de domínio e esse serviço se conecta a um subdomínio desse nome de domínio raiz. então o domain.com/cloud está jogando tudo por um loop

se alguém pudesse me dar alguma orientação, eu ficaria muito grato porque o nextcloud é um produto no qual estou realmente interessado em investir.

— user502301
fonte

Este post de Mike Griffen aborda apenas esse problema e parece ser uma solução simples.

Authz_core:error Client Denied by Server Configuration

... mod_authz_corefoi introduzido no Apache2.3. Isso muda a maneira como o controle de acesso é declarado

a partir de:
Order allow, deny
Allow from all
para:
Require all granted
Isso significa que a configuração total de um diretório agora é algo como:
<Directory /path/to/directory>
     Options FollowSymlinks
     AllowOverride none
     Require all granted
</Directory>
Reinicie o apache e tudo funcionará bem.

— Steve Hope
fonte

resposta alterada para incluir explicação expandida, também estava tentando ilustrar o Google (ou, neste caso, duck-duck-go'ing) a mensagem de erro real, 'authz_core: error', uma vez, e escolher o primeiro resultado geralmente salvará a resposta da pergunta laço aqui

— Steve esperança

As pessoas não sabem se um artigo aleatório está correto ... pelo menos nos sites da SE, temos um sistema de votação (é certo que os votos nem sempre são confiáveis!) E permitem que todos os usuários editem para implementar algum nível de revisão por pares, manutenção etc. As postagens aqui também são encontradas pelos mecanismos de pesquisa. Ao fornecer boas respostas, fornecemos bons resultados de pesquisa.

— Zanna