問題: インタラクティブ・モードを有効にしときに"Error in download.file(...." というエラーが表示される

以前は機能していたインサイトで、インタラクティブ・モードをオンにして、パラメーターのセッションや詳細の表示セッションを開始したとききに、Error in download.file("http://....といったエラーが表示される場合があります。これは内部の一時ディレクトリに空き領域がないときなどに表示されるエラーです。

解決方法

ボリュームに、/tmpfsフォルダを割り当てる代わりに、/tmpフォルダを割り当てることで、こちらの問題は解決できます。詳しい手順は以下となります。

1. Exploratory サーバーのインストールフォルダにあるdocker-compose.yml を開きます。
2. rserveのセクションを探します。
3. tmpfsと同じレベルにvolumes セクション（2行）を追加します。
4. tmpfsセクション（通常は3行）の先頭に「#」を追加して、コメントアウトします。

以下がrserve修正後の例です。

 rserve:
   image: r-exploratory:7.0.9
    #tmpfs:
    #  # exec is necessary to run prophet successfully.
    #  - /tmp:exec   tmpfs:
    volumes:
      - ./tmp:/tmp

変更が完了したら、サーバーを再起動することで変更が有効になります。

$ docker-compose down
$ docker-compose up -d

問題: パラメータを更新しようとしたときに「データサイズが大きいため、処理が失敗した可能性があります」というエラーが表示される

サーバーに十分なメモリがあるにもかかわらず、コンテンツのパラメータを更新しようとしたとき「データサイズが大きいため、処理が失敗した可能性があります」「Processing might have failed due to the large data size.」といったエラーが表示される場合は、Exploratory サーバーに十分なメモリの割り当てがされてないことが原因である可能性があります。

解決方法

Exploratoryサーバーのメモリの割り当てを増やすことでこの問題を解決できる可能性があります。詳細はこちらを参照してください。

問題: インタラクティブ・モードが起動中のままになる

すべてのプールされたRのコネクションが使用中の場合、インタラクティブ・モードの起動に時間がかかることがあります。これは、多くのユーザーが同時にインタラクティブ・モードにアクセスしている場合によく発生します。

解決方法

Rコネクションの最大プールサイズを増やすことで解決できます。以下の手順で設定を変更します。

R接続の最大プールサイズを増やすことで解決できます。以下の手順で設定を変更します。

1. Exploratory Serverのインストールフォルダ内のdocker-compose.ymlを開きます。
2. exploratoryセクションのenvironmentセクションを見つけます。
3. EXPL_RSERVE_POOL_MAX_SIZEを追加し、値を指定します。何も指定していない場合の初期値は5です。最適値はシステムの仕様に応じて変わりますが、まずは、20か30に増やして確認してみてください。 例は次の通りです。

exploratory:
              :
              :
  environment:
    - EXPL_RSERVE_POOL_MAX_SIZE=30

1. 設定変更後、サーバーを再起動して変更を反映させます。

$ docker-compose down
$ docker-compose up -d

問題: 'docker-compose up'コマンド実行時の、'repository does not exist'に関するエラー

docker-compose up -dコマンドで、 Exploratoryサーバーを起動する際に以下のようなエラーが発生します。

Pulling rserve (r-exploratory:5.1.6.2)...
ERROR: pull access denied for r-exploratory, repository does not exist or may require 'docker login'

解決方法

このエラーは、ExploratoryサーバーのDockerイメージが正しくロードされていないことが原因で起こります。Dockerイメージをロードする際にディスク容量が不足していることが主な原因です。ディスク容量を確保した後、インストール・ガイドを確認して、以下のコマンドを実行するステップが、正しく完了していることを再確認してください。

docker load -i exploratory-collab-images-<version number>.tar.gz

問題: 'docker-compose up'実行時の、'start shim'に関するエラー

docker-compose up -dコマンドで、 Exploratoryサーバーを起動する際に以下のようなエラーが発生します。

docker: Error response from daemon: failed to start shim: exec: "docker-containerd-shim": executable file not found in $PATH: unknown.

解決方法

Dockerサービスの状態に異常がある可能性があります。Dockerサービスを以下のコマンドで、再起動してから再度Exploratoryサーバーの起動をお試しください。

systemctl restart docker

問題: 'docker-compose up'実行時のエラー 'getaddrinfo("mongodb") failed'

docker-compose up -dコマンドで、 Exploratoryサーバーを起動してもブラウザーからアクセス可能にならず、Exploratoryサーバーのログを確認すると、以下のようなエラーが記録されています。

getaddrinfo("mongodb") failed: Temporary failure in name resolution

解決方法

Dockerサービスの状態に異常がある可能性があります。Dockerサービスを以下のコマンドで、再起動してから再度Exploratoryサーバーの起動をお試しください。

systemctl restart docker

問題: システムのディスク容量が足りなくてExploratoryサーバーを起動できない。

システムのディスク容量が足りない場合、docker-compose up -dコマンドの実行が失敗することがあります。

解決方法

システム上の不要なファイルを削除して、ディスク容量を確保してください。もし、以前にアップグレードをしたことがある場合は、不要な Exploratory Server の Docker イメージを消すことでディスク容量を確保することができます。

問題: クラウドサーバー（exploratory.io）とオンプレミスサーバーの両方に同じノートをパブリッシュすると、Exploratoryデスクトップ上のノートから発行されたURLが削除される

解決方法

現在のところ、パブリッシュ機能は1つのノートにつき、1つのURLしかサポートしていないため、複数のサーバーに同時に1つノートをパブリッシュすることはできません。回避策として、ノートを複製し、それぞれのノートをサーバーに別々にパブリッシュすることで、サーバーごとに固有のURLを維持できます。

問題：ライセンス・キーをセットしても使用可能にならない

ライセンス・キーを設定したにも関わらず、以下のようなトライアル期間終了のページが表示されます。

解決方法

ライセンス・キーの中には、以下のようにIPアドレス、またはホスト名が埋め込まれています。

ライセンス・キーの例1（IPアドレスが埋め込まれたもの）：

ライセンス・キーの例2（ホスト名が埋め込まれたもの）：

これらは、ブラウザに打ち込むURL中のIPアドレス、ホスト名と一致する必要があります。 もし、ライセンスキー中にあるIPアドレス、ホスト名以外を使ってブラウザからアクセスする必要がある場合はサポートまでご連絡ください。

問題：ブラウザーからExploratoryサーバーに接続できない

ブラウザーからExploratoryサーバーに接続しようとしても待たされ続けて何も表示されない。

解決方法

これは、ブラウザーとコラボレーションサーバーの間にネットワーク通信の問題があるときに起きる現象です。

様々な原因でネットワーク通信の問題は起こりますが、一つの可能性はDockerがコラボレーションサーバーに割り当てるIPアドレスが、何かと衝突していることです。 これを避けるための手段として、docker-compose.ymlに、以下の例のような設定を追加して、Dockerが割り当てるIPアドレスの範囲を指定することが出来ます。 以下の例では、Dockerが割り当てるIPアドレスが、192.168.100.0から192.168.100.255までの範囲になるよう指定しています。

networks:
  default:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 192.168.100.0/24

問題

インサイトの検索をすると「検索結果の取得に失敗しました。リロードをしてもう一度お試しください。」と表示され、リロードしても解消されない。

解決方法

Exploratoryサーバー内部で使用しているデータベースにある索引が十分でない可能性があります。以下のステップに従って、索引を作成してください。

• MongoDBのDockerコンテナIDを確認します。docker ps コマンドを実行してコンテナIDの一覧を取得し、その中で、IMAGEが"mongo"で始まっているものを探します。以下の例では、494388a45e11 がコンテナIDになります。

• 以下のコマンドを実行して、コンテナへの接続を行います。 ((Container ID) は実際のコンテナIDに置き換えてください)

docker exec -it (Container ID) bash

• 以下のコマンドを実行して、MongoDBへの接続を行います。

mongo exploratory

• 以下のコマンドを実行して、MongoDBに索引を作成します。

db.notebooks.createIndex({"updatedAt" : -1})
db.notebooks.createIndex({"numlikes" : -1})
db.notebooks.createIndex({"views" : -1})
db.notebooks.createIndex({"downloads" : -1})
db.notebooks.createIndex({"viewStats.last7Days" : -1})
db.notebooks.createIndex({"viewStats.thisWeek" : -1})
db.notebooks.createIndex({"viewStats.lastWeek" : -1})
db.notebooks.createIndex({"viewStats.lastMonth" : -1})
db.notebooks.createIndex({"viewStats.last30Days" : -1})
db.notebooks.createIndex({"viewStats.last365Days" : -1})
db.notebooks.createIndex({"viewStats.thisYear" : -1})
db.notebooks.createIndex({"viewStats.lastYear" : -1})
db.notebooks.createIndex({"viewStats.allTime" : -1})
db.notebooks.createIndex({"viewStats.thisMonth" : -1})

問題：デスクトップからGoogle AnalyicsなどのOAuthのデータソースにアクセスしようとすると「アクセスをブロック: 認証エラーです 400: invalid_request」となる。

接続先がexploratory.ioでなくExploratoryサーバー（ホステッドまたはオンプレミス）で、かつOAuthの設定が完了していないとこちらのエラーが表示されます。

解決方法

Exploratory サーバー（ホステッドまたはオンプレミス）でGoogle Sheets, Analytics, BigQueryにOAuth接続する方法の手順に従ってOAuthの設定をしてください。

問題：Googleのサービスをデータソースに利用してサーバーでスケジュールを設定しているときに、OAuthの再認証エラーが出る

Google Analytics、Google Sheets、Google BigQuery、Google Driveなどをデータソースに持つコンテンツをスケジュールしていると以下のようなエラーメッセージが表示されることがあります。

"There are unauthorized oauth tokens: xxxx" こちらからOAuthトークンの再認証を行ってください。

解決方法

エラーダイアログの中の「こちら」をクリックして、OAuthを再認証することでこの問題は解決します。

なお、OAuthの再認証が必要となるケースにつきましては、こちらに情報をまとめていますので、ご参考ください。

問題: データ・リフレッシュしてもパブリッシュされたダッシュボードなどの更新日時が古い

データ・リフレッシュが実行された後でも、パブリッシュされたダッシュボードなどの更新日時が古いままです。

解決方法

ご使用のサーバーのクロックが、現在時刻から遅れていないかご確認ください。

もし、それ以外の原因でリフレッシュがうまくいっていない場合は、サポートまでご連絡ください。

問題: データ・リフレッシュすると、Dataタブの内容がなくなる

データ・リフレッシュすると、以下のスクリーンショットのように、Dataタブの内容が表示されなくなります。

解決方法

exploratoryディレクトリの下のrdataディレクトリの下にできるディレクトリの所有者が間違ってrootになってしまっているためにDataタブの内容がExploratoryサーバー内部で正しく受け渡しできず、この問題が起きるケースがありました。（以下の赤枠で囲われたディレクトリのような状況です。）

この場合は、所有者が間違っているディレクトリを一旦消去することによって問題が起きなくなります。

sudo rm -rf iYk0ehZ6TQ

ディレクトリを消去する際は、間違ったディレクトリやファイルを消さないよう、ご注意ください。どのディレクトリを消したら良いのか確信が持てないときなどは、サポートまでご相談ください。

問題: スケジュール時に「Error in curl::curl_fetch_memory(url, handle = handle) : Timeout was reached: [webdav] Operation timed out after 30001 milliseconds」のエラーが発生してしまう。

更新に長時間かかるインサイトをスケジュールすると、下記のようなエラーが発生することがあります。

Error in curl::curl_fetch_memory(url, handle = handle) : Timeout was reached: [webdav] Operation timed out after 30001 milliseconds。

解決方法

v7.0以降を使用している場合は、docker-compose.ymlのconfigファイルにあるEXPL_HTTP_TIMEOUTのパラメーターでより長い時間のタイムアウトを設定することで回避できます。タイムアウトの単位は秒単位になっていて、1時間に設定したい場合は「3600」と指定します。

1. Exploratory Serverのインストールフォルダにあるdocker-compose.ymlを開きます。
2. rserveのセクションを探します。
3. rserveのサブセクションであるenvironmentの下に- EXPL_HTTP_TIMEOUT=3600の行を追加します。 もし、environmentのセクションが無い場合は、下記のように追加します。

rserve:
image: r-exploratory:7.0.9
tmpfs:
  # exec is necessary to run prophet successfully.
  - /tmp:exec
environment:
  - EXPL_HTTP_TIMEOUT=3600

変更が完了したら、下記を実行してサーバーを再起動して変更を有効にします。

$ docker-compose down
$ docker-compose up -d

問題が解決しない場合は、サポートにお問合せください。

問題: スケジュール時に「cannot popen '/usr/bin/which 'uname' 2>/dev/null', probable reason 'Cannot allocate memory'」のエラーが発生してしまう。

インサイトをスケジュールすると、下記のようなエラーが発生することがあります。これは、新規にサーバをインストールしたときや、サーバのアップグレードの直後によく起こります。

cannot popen '/usr/bin/which 'uname' 2>/dev/null', probable reason 'Cannot allocate memory'

解決方法

docker-compose.ymlファイルのrserveセクションに、privileged: trueというパラメーターを追加することで回避できます。

1. Exploratory Serverのインストールフォルダにあるdocker-compose.ymlを開きます。
2. rserveのセクションを探します。
3. privileged: true という行を追加します。

パラメーターを追加後の設定ファイルは、以下のようになります。

 rserve:
   image: r-exploratory:7.0.9
   tmpfs:
     # exec is necessary to run prophet successfully.
     - /tmp:exec
   privileged: true

変更が完了したら、下記を実行してサーバーを再起動して変更を有効にします。

$ docker-compose down
$ docker-compose up -d

問題が解決しない場合は、サポートにお問合せください。

問題: Googleが常にOAuthの再認証を行うよう要求される

Google BigQueryまたはその他のGoogle関連のデータソースにアクセスするダッシュボードまたはノートを実行しようとすると、Googleに常にOAuthの再認証を要求される。

解決方法

「Collaboration ServerでGoogle Sheets, Analytics, BigQueryにOAuth接続する方法」のノートに従って、Google OAuthのトークンのセッションに適切な期間を設定します。

問題: コンテンツをスケジュールしたときに「データサイズが大きいため、処理が失敗した可能性があります」というエラーが表示される

サーバーに十分なメモリがあるにもかかわらず、コンテンツをスケジュールをしたときに、「データサイズが大きいため、処理が失敗した可能性があります」「Processing might have failed due to the large data size.」といったエラーが表示される場合は、Exploratory サーバーに十分なメモリの割り当てがされてないことが原因である可能性があります。

解決方法

Exploratoryサーバーのメモリの割り当てを増やすことでこの問題を解決できる可能性があります。詳細はこちらを参照してください。

問題: Exploratoryデスクトップ上ではデータの再インポートができるのに、サーバー上でスケジュールしたときにはエラーがでる。

Exploratoryデスクトップ上ではデータの再インポートができるのに、サーバー上でスケジュールしたときにはデータが取得できずエラーになってしまう場合、データソースとして使用しているデータベースが、Exploratory サーバーからのリクエストを許可していないことが原因の場合があります。

解決方法

データベースのホワイトリストにExploratoryサーバーのIPアドレスを登録することで解決することができます。詳細はこちらを参照してください。

問題: 'docker-compose down'コマンド実行時の'network has active endpoints'というエラー

docker-compose downnコマンドで、 Exploratoryサーバーをシャットダウンする際に以下のようなエラーが発生します。

ERROR: network exploratory_default has active endpoints

解決方法

1. エラーメッセージ中にあるDockerネットワーク(この場合は、"exploratory_default")の状態を以下のコマンドで確認します。

docker network inspect exploratory_default

以下のような出力が表示されます。

[
    {
        "Name": "exploratory_default",
                ...
        "Containers": {
            "014cbe0146...": {
                "Name": "exploratory_exploratory_1",
                ...
            },
            "494388a45e...": {
                "Name": "exploratory2_mongodb_1",
                ...
            },
                        ...
        },
        ...
    }
]

"014cbe0146..."などの部分は、DockerコンテナのIDです。次のステップで必要になります。 2. 前のステップで取得したコンテナIDで、以下のコマンドを実行し、これらのコンテナを削除します。

docker rm (container ID)

上記のコマンドでは削除できない場合、以下のコマンドを実行します。

docker rm -f (container ID)

これを、問題のあるDockerネットワークに接続している全てのコンテナについて実行します。 3. その後で、以下のコマンドで、Exploratoryサーバーをシャットダウンします。 docker-compose down.

問題: docker-compose.ymlまたはexploratory_config.yml内の管理者ユーザー情報(emailなど)を更新したが、変更が反映されない

docker-compose.ymlまたはexploratory_config.yml内の管理者ユーザー情報(emailなど)を更新した後で、コラボレーションサーバーを再起動しましたが、管理者ユーザー情報が実際に更新されているように見えません。

解決方法

docker-compose.ymlまたはexploratory_config.yml内の管理者ユーザー情報は、インストールの際のみに利用されるものですので、インストール後にこちらを変更しても無視されます。 インストール後に管理者情報を変更する場合は、管理者アカウントでブラウザからログインして、「アカウントの設定」ページで情報を更新してください。

問題: exploratory.ioにExploratory Publicで接続したあとで、Exploratory DesktopでExploratoryサーバーに接続しようとするとエラーダイアログが表示される

ご使用のPCでExploratory Publicでexploratory.ioにログインすると、接続先情報（exploratory.io）がExploratoryのレポジトリに記録されます。そのため、次にExploratoryサーバーにログインしようとしてExploratoryデスクトップを開くと、exploratory.ioのExploratory Public用のアカウントに接続され、エラーダイアログが表示されます。

解決方法

表示されたエラーダイアログの、"接続先のサーバーを変更"ボタンをクリックします。

以下のようなログイン画面が開きますので、"サーバタイプ"をExploratoryサーバーに切り替えて、ExploratoryサーバーのURLを入力することにより、Exploratoryサーバーに接続してExploratoryデスクトップを使用することができます。

問題: 普段はExploratoryサーバーを使っているが、exploratory.ioに接続しようとすると認証に失敗する。

普段はExploratoryデスクトップをExploratoryサーバーに接続して使っていますが、exploratory.ioに切り替えようとすると認証に失敗します。

解決方法

exploratory.ioのアカウントは、Exploratoryサーバー上のアカウントとは連携されていませんので、exploratory.ioに接続するには、exploratory.io上でアカウントを作成する必要があります。

Exploratoryサーバーの利用者様が、exploratory.ioにも接続したい場合は、Exploratoryサーバーのライセンスと同期間有効なexploratory.io上のライセンスを付与させていただきますので、サポートまでご相談ください。

問題: "504 Gateway Time-out"というエラーが表示される。

ExploratoryサーバーにExploratoryデスクトップからデータ、チャート、ダッシュボードなどをパブリッシュするときに、特に大きいデータを扱っている際に、以下のようなエラーが表示される。

Network Error: 504
Gateway Time-out

解決方法

こちらのエラーは、Exploratoryサーバー内で、Exploratoryデスクトップからのリクエストを受け取ってバックエンドに渡す役割をしているNginxウェブサーバーが、バックエンドからのレスポンスが時間がかかりすぎていると判断してタイムアウトしたときに発生します。

デフォルトではタイムアウトまでの待ち時間は60秒ですが、これを延長することができます。

exploratoryディレクトリの下のdefault.confファイルは、Nginxの設定ファイルですが、このファイルのserverセクションの中の、locationセクションに、以下のようにproxy_read_timeoutパラメターを追加することによってタイムアウト時間を調整できます。

以下の例では、600s、つまり600秒にタイムアウト時間を設定しています。

default.confの例

server {
  ...
  location / {
    ...
    proxy_read_timeout 600s
  }
  ...
}

問題: "Hostname/IP does not match certificate's altnames: IP: xxx.xxx.xxx.xxx is not in the cert's list"というエラーが表示される。

ExploratoryサーバーにExploratoryデスクトップからデータ、チャート、ダッシュボードなどをパブリッシュするときに、以下のようなエラーが表示される。

Hostname/IP does not match certificate's altnames: IP: xxx.xxx.xxx.xxx is not in the cert's list:

解決方法

こちらのエラーは、Exploratoryサーバーをホスト名ではなくIPアドレスで運用し、HTTPS(SSL)を設定している際に発生することがあります。

その場合は、Exploratory Collaboration Server用の自己署名のSSL証明書ファイルを、サーバー名ではなくIPアドレスで作成する方法を参照してSSL証明書を作成し、そちらをExploratoryサーバーに使用してください。

問題: システムのディスク容量が足りなくて、パブリッシュが失敗する。

システムのディスク容量が足りない場合、パブリッシュが失敗することがあります。

解決方法

システム上の不要なファイルを削除して、ディスク容量を確保してください。もし、以前にアップグレードをしたことがある場合は、不要な Exploratory Server の Docker イメージを消すことでディスク容量を確保することができます。

問題: Exploratoryサーバーを削除するとログファイルが削除されてしまう。

Exploratory Server を再起動すると、システムはデフォルトで古いログファイルを削除します。

解決方法

設定ファイルをカスタマイズしてログの保存先を変更することで、再起動時にもログファイルを保持しつづけることが可能です。

詳細は、こちらのノートを参照してください。

問題: いつ、誰がインサイト、ユーザー、チームを作成、アクセス、または更新したかを知りたい

HTTPアクセスログから、いつ、誰がインサイト、ユーザー、チームを作成、アクセス、または更新したかを知るのは困難です。

解決方法

Exploratoryサーバーのバージョン 8.0 以降では、ログファイルからインサイト、ユーザーおよびチームのイベントを確認することが可能です。詳細はこちらを参照してください。