全新安装后无法访问 collabora

Question

我已经安装了 Ubuntu 16.04，其中安装了 nextcloud /var/www/cloud（wordpress 位于根目录中）。它已经运行了一段时间，但我最近发现 collabora 可以替代 google docs，并且真的希望它起作用。当我尝试打开文档时，收到“禁止访问”错误。我已根据此处的说明安装了 collabora

我检查了 lsof -i 的输出，可以看到 docker 在 9980 上监听，在 Nextcloud 中配置了 URL，老实说，我不确定如何开始解决这个问题。如果社区中的任何人能给我一些指导，那就太棒了。一些附加信息如下。

来自位于 /var/log/apache2 中的apache error.log 的条目：

[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

用于 collabora vhost的 My Apache 配置的净化版本：

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

我的 nextcloud 实例的地址是 domain.com/cloud

lsof -i 的输出| grep docker我相信这表明 docker 容器正在侦听来自 9980 上的本地主机的流量以发送到容器

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

理论：我有一个理论，这次我可能需要再次设置 nextcloud，nextcloud 位于 webroot 中，而我的博客位于 webroot 内的文件夹中，因为我从文档中获得的感觉是 nextcloud 预计将是在它自己的机器上使用它自己的域名，并且此服务连接到该根域名的子域。所以 domain.com/cloud 把整个事情都扔了一个循环

如果有人能给我一些指导，我将不胜感激，因为 nextcloud 是我真正有兴趣投资的产品。

Answer 1

迈克·格里芬 (Mike Griffen) 的这篇文章正是解决了这个问题，而且它似乎是一个简单的解决方案。

\n\n

Authz_core:error Client Denied by Server Configuration\n

\n\n

\n

...mod_authz_core在Apache2.3中引入。这改变了访问控制的声明方式

\n\n

从：

\n\n

Order allow, deny\nAllow from all\n

\n\n

到：

\n\n

Require all granted\n

\n\n

这意味着目录的总配置现在类似于：

\n\n

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

\n\n

重新启动apache，它\xe2\x80\x99就可以正常工作了。

\n

\n