Не может получить доступ к collabora после новой установки

У меня есть существующая установка Ubuntu 16.04 с nextcloud, установленным в /var/www/cloud (Wordpress находится в корне). Это хорошо работало некоторое время теперь, но я недавно обнаружил collabora как альтернативу документам Google, и ДЕЙСТВИТЕЛЬНО хотят, чтобы это работало. Когда я пытаюсь открыть документ, я получаю "Доступ Запрещенная" ошибка. Я установил collabora согласно инструкциям, найденным здесь

Я проверил вывод lsof-i и вижу, что докер слушает на 9 980, Настроенный URL в Nextcloud и barehonestly, я не действительно уверен, как пойти о том, чтобы начинать диагностировать эту проблему. Если бы кто-либо от сообщества мог бы дать мне некоторые указания, которые были бы удивительны. Некоторая дополнительная информация ниже.

Записи из апачского error.log, расположенного в/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

Санированная версия Моего Apache конфигурируется для 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>

Адрес моего nextcloud экземпляра domain.com/cloud

вывод lsof-i | grep докер, я верю этому, показывает, что контейнер докера прислушивается к трафику от localhost на 9 980 для отправки к контейнеру

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

Теория: у Меня есть теория, что я должен буду, вероятно, установить nextcloud снова на этот раз с nextcloud, находящимся в webroot и моем блоге, находящемся в папке в webroot, потому что энергетика, которую я получаю из документации, - то, что nextcloud, как ожидают, будет на своей собственной машине со своим собственным Доменным именем, и этот сервис соединяются с субдоменом того корневого доменного имени. таким образом, domain.com/cloud бросает все это для цикла

если бы кто-либо мог бы дать мне некоторые указания, я был бы значительно благодарен, поскольку nextcloud является продуктом, я действительно интересуюсь инвестированием в.

16
задан 2 January 2017 в 23:37

1 ответ

Это сообщение Mike Griffen адреса просто эта проблема, и это, кажется, простое решение.

Authz_core:error Client Denied by Server Configuration

... mod_authz_core был представлен в Apache2.3. Это изменяет способ, от которого управление доступом объявляется

:

Order allow, deny
Allow from all

к:

Require all granted

Это означает, что общая конфигурация для Каталога - теперь что-то как:

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

апач Перезапуска и it’ll вся работа приятно.

1
ответ дан 23 November 2019 в 02:37

Другие вопросы по тегам:

Похожие вопросы: