Impossibile accedere a collabor dopo una nuova installazione

Ho un'installazione esistente di Ubuntu 16.04 con nextcloud installato in /var/www/cloud(wordpress è nella radice). Funziona bene da un po 'di tempo, ma recentemente ho scoperto collaborare come alternativa ai documenti di Google e DAVVERO voglio che funzioni. Quando provo ad aprire un documento ricevo un errore "Accesso vietato". Ho installato collabor in base alle istruzioni trovate qui

Ho controllato l'output di lsof -i e posso vedere la finestra mobile in ascolto su 9980, ho configurato l'URL in Nextcloud e sinceramente non sono davvero sicuro di come iniziare a risolvere questo problema. Se qualcuno della community potesse darmi una guida sarebbe fantastico. Alcune informazioni aggiuntive sono di seguito.

Voci da apache error.log situate 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

Versione sterilizzata di My Apache config per il vhost collabor :

<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'indirizzo della mia istanza nextcloud è domain.com/cloud

output di lsof -i | finestra mobile grep Credo che ciò dimostri che il contenitore finestra mobile sta ascoltando il traffico dall'host locale su 9980 per l'invio al contenitore

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

Teoria : ho una teoria secondo cui probabilmente avrò di nuovo la configurazione di nextcloud questa volta con nextcloud nella webroot e il mio blog in una cartella all'interno della webroot perché l'atmosfera che sto ottenendo dalla documentazione è che ci si aspetta che nextcloud sia sulla propria macchina con il proprio nome di dominio e questo servizio si connette a un sottodominio di quel nome di dominio principale. così domain.com/cloud sta lanciando il tutto per un loop

se qualcuno potesse darmi qualche consiglio, sarei molto grato poiché nextcloud è un prodotto a cui sono veramente interessato a investire.

Questo post di Mike Griffen affronta proprio questo problema e sembra essere una soluzione semplice.

Authz_core:error Client Denied by Server Configuration

... è mod_authz_corestato introdotto in Apache2.3. Ciò cambia il modo in cui viene dichiarato il controllo di accesso

a partire dal:

Order allow, deny
Allow from all

per:

Require all granted

Ciò significa che la configurazione totale per una directory è ora simile a:

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

Riavvia Apache e funzionerà tutto bene.