Kein Zugriff auf Collabora nach Neuinstallation

Ich habe eine bestehende Installation von Ubuntu 16.04 mit nextcloud in /var/www/cloud(wordpress befindet sich im Root). Es läuft jetzt schon eine Weile gut, aber ich habe kürzlich Collabora als Alternative zu Google Docs entdeckt und möchte, dass dies WIRKLICH funktioniert. Beim Versuch, ein Dokument zu öffnen, wird die Fehlermeldung "Zugriff verboten" angezeigt. Ich habe Collabora gemäß den Anweisungen hier installiert

Ich habe die Ausgabe von lsof -i überprüft und sehe, wie Docker auf 9980 lauscht, die URL in Nextcloud konfiguriert und ehrlich gesagt, ich bin mir nicht sicher, wie ich anfangen soll, dieses Problem zu beheben. Wenn mir jemand aus der Community eine Anleitung geben könnte, wäre das erstaunlich. Einige zusätzliche Informationen finden Sie weiter unten.

Einträge aus der Datei apache error.log 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

Bereinigte Version von My Apache Config für den 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>

Die Adresse meiner nextcloud-Instanz lautet domain.com/cloud

Ausgabe von lsof -i | grep docker Ich glaube, dies zeigt, dass der Docker-Container den Datenverkehr vom Localhost auf 9980 abhört, um ihn an den Container zu senden

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

Theorie : Ich habe die Theorie, dass ich nextcloud wahrscheinlich dieses Mal erneut einrichten muss, wobei nextcloud in der Webroot und mein Blog in einem Ordner in der Webroot enthalten sind, da die Stimmung, die ich aus der Dokumentation erhalte, so ist, dass nextcloud erwartet wird auf einem eigenen Computer mit einem eigenen Domänennamen und diesem Dienst wird eine Verbindung zu einer Unterdomäne dieses Stammdomänennamens hergestellt. Die domain.com/cloud wirft also das Ganze für eine Schleife

Wenn mir jemand eine Anleitung geben könnte, wäre ich sehr dankbar, da nextcloud ein Produkt ist, in das ich wirklich investieren möchte.

Dieser Beitrag von Mike Griffen befasst sich nur mit diesem Problem, und es scheint eine einfache Lösung zu sein.

Authz_core:error Client Denied by Server Configuration

... mod_authz_corewurde in Apache2.3 eingeführt. Dies ändert die Art und Weise, wie die Zugriffssteuerung deklariert wird

von:

Order allow, deny
Allow from all

zu:

Require all granted

Dies bedeutet, dass die Gesamtkonfiguration für ein Verzeichnis jetzt ungefähr so ​​lautet:

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

Starten Sie Apache neu und alles wird gut funktionieren.