新規インストール後にcollaboraにアクセスできません


16

nextcloudがインストールされたUbuntu 16.04の既存のインストールがあります/var/www/cloud(wordpressはルートにあります)。しばらくの間は正常に動作していましたが、最近、Googleドキュメントの代替としてコラボラを発見し、これが本当に機能することを望んでいます。文書を開こうとすると、「アクセス禁止」エラーが表示されます。ここにある指示に従ってコラボラをインストールしまし

私はlsof -iの出力をチェックし、9980でdockerがリッスンしていること、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のlocalhostからコンテナに送信するトラフィックをリッスンしていることを示していると思います

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

理論:私はおそらく、nextcloudがwebrootにあり、私のブログがwebroot内のフォルダーにある状態で、nextcloudを再度セットアップする必要があるという理論を持っています。独自のドメイン名を持つ独自のマシン上で、このサービスはそのルートドメイン名のサブドメインに接続します。そのため、domain.com / cloudはループ全体をスローしています

誰かが私にいくつかのガイダンスを与えることができれば、nextcloudは私が本当に投資に興味を持っている製品なので、私は非常に感謝します。

回答:


1

Mike Griffenによるこの投稿はまさにこの問題に対処するものであり、簡単な解決策のようです。

Authz_core:error Client Denied by Server Configuration

... mod_authz_coreApache2.3で導入されました。これにより、アクセス制御の宣言方法が変更されます

から:

Order allow, deny
Allow from all

に:

Require all granted

これは、ディレクトリの構成全体が次のようになることを意味します。

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

Apacheを再起動すると、すべて正常に動作します。


詳細な説明を含むように回答を修正し、実際のエラーメッセージ「authz_core:error」を1回グーグル(またはこの場合はduck-duck-go'ing)で説明しようとしており、最初の結果を選択すると質問の回答が保存されることがよくありますここでループ
スティーブホープ

人々はランダムな記事が正しいかどうかを知りません...少なくともSEサイトでは投票システムがあり(確かに投票は常に信頼できるとは限りません!)、すべてのユーザーが編集してある程度のピアレビュー、保守性などを実装できるようにします。ここの投稿は検索エンジンでも見つけられます。適切な回答を提供することにより、適切な検索結果を提供します。
ザンナ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.