ONLYOFFICEがNextcloudに保存しない場合の保存コールバックのトレース

架空の例：ミナがNextcloudフォルダからONLYOFFICEでプロジェクトプランを編集します。エディタが開き、変更が反映されますが、その後Nextcloudから「ドキュメントを保存できませんでした」というエラーが表示されます。この例は説明のためのものであり、実際のテスト結果ではありません。このような状況では、エディタを開いたままにして、保存されていない作業のローカルコピーを保持し、ONLYOFFICE DocsがNextcloudの保存コールバックに直接アクセスできるかどうかを確認してください。その後、ログを使用して、コールバックのルーティングエラーとNextcloudのストレージまたは権限の問題を区別してください。

1. トラブルシューティングを行う前に、ミナの変更を保護してください。

Nextcloudが保存していない変更が含まれている間は、エディタを閉じたり更新したりしないでください。エディタが応答可能な場合は、エディタの「ダウンロード」オプションを使用してローカルに復元コピーを保存してください。管理者がログと照合できるように、保存に失敗した日時とファイル名をメモしておいてください。

標準のNextcloudフォルダに小さなDOCXファイルを作成してテストしてください。保存に成功した場合は、元のファイルのアクセス権限、共有ステータス、ストレージ、またはフォーマットを確認してください。すべてのファイルの保存に失敗した場合は、共有コールバックルートとサーバーの状態から確認してください。

2. サーバー間保存コールバックを確認する

ONLYOFFICE Docsは、Nextcloudコネクタから提供されるコールバックURLにPOSTリクエストを送信します。Nextcloudは編集されたファイルを取得し、保存されているバージョンを更新します。ドキュメントサーバーがNextcloudにPOSTバックできない場合、エディタは正常に開くことができますが、保存に失敗する可能性があります。

テストファイルを使用して問題を再現し、その時点での DocService と Nextcloud のログを比較してください。Linux では ONLYOFFICE のログは にあります/var/log/onlyoffice/documentserver/。Docker では、コンテナのログまたはマウントされたログディレクトリを確認してください。Nextcloud のデフォルトのファイルログは、または が変更されないnextcloud.log限り、データディレクトリにあります。log_typelogfile

• 301、302、または308：コールバックURLリダイレクト。多くの場合、HTTP/HTTPS間またはホスト名間で行われます。
• タイムアウトまたはDNSエラー：ドキュメントサーバーがURLを解決できないか、アクセスできません。
• 403または404：プロキシ、アクセスルール、パス書き換え、またはホスト設定により、リクエストが拒否された可能性があります。
• Nextcloudストレージ例外：コールバックが到着しました。クォータ、権限、ストレージの状態、またはロックを確認してください。

3. コールバックがリダイレクトされた場合は、URLまたはプロキシルートを修正する

Nextcloudで、[設定] > [管理] > [ONLYOFFICE]を開きます。公開されているONLYOFFICE Docsのアドレスが、ユーザーのブラウザが読み込むべきURLであることを確認してください。2つのサーバーが公開アドレスを介して相互に通信できない場合は、ドキュメントに記載されている内部フィールドを設定します。サーバーからの内部リクエスト用のONLYOFFICE Docsアドレスと、ONLYOFFICE Docsからの内部リクエスト用のサーバーアドレスです。前者はNextcloudからDocument Serverへの通信で機能する必要があり、後者はDocument ServerからNextcloudへの通信で機能する必要があります。

Minaの想定設定では、コールバックはHTTPSを使用しhttp://cloud.example.com、HTTPSにリダイレクトします。最終的なHTTPSアドレスを直接設定し、DNS、ファイアウォールルール、証明書の信頼関係によってDocument Serverがそのアドレスにアクセスできることを確認してください。プロキシは、スキーム、ホスト名、パスをリダイレクトせずに、コールバックをNextcloudに渡す必要があります。サンプルホスト名は実際のインストールには適していません。

ONLYOFFICEの接続チェックは、設定済みのサービスアドレスを確認するのに役立ちます。

sudo -u www-data php occ onlyoffice:documentserver --check

Nextcloudディレクトリから、適切なWebサーバーアカウントで実行してください。チェックが成功したからといって、コールバックPOSTが正しく機能しているとは限りません。同じホスト名で手動でHEADリクエストを送信したり、ブラウザでページを開いたりしても、証明にはなりません。

4. 証拠をNextcloudストレージに追跡する

コールバックがNextcloudに到達してもファイルが更新されない場合は、Nextcloudのログで該当するリクエストを確認してください。ユーザーに編集権限があること、ストレージのマウントポイントが利用可能であること、アカウントのクォータが超過していないこと、データボリュームに空き容量とinodeがあることを確認してください。問題が共有ファイルに影響している場合は、他のユーザーまたは同期クライアントが同時にファイルを変更していないか確認し、プライベートフォルダ内のコピーでテストしてください。

Nextcloudのトランザクションファイルロックは書き込みを調整します。応急処置として無効にしないでください。ログにロックまたはデータベースのエラーが記録されている場合は、ロックバックエンドとRedisまたはValkeyサービスを確認してください。oc_file_locksアクティブな書き込みを妨げる可能性があるため、行を削除したり、ファイルをロックしたりしないでください。

標準フォルダのテストは成功するのに、外部ストレージに保存されたファイルのテストが失敗する場合は、そのマウントポイントの可用性と認証モードを調査してください。ONLYOFFICE には、一部の外部ストレージモードに関する制限事項が記載されています。マウントポイントを特定するまでは、認証情報を変更しないでください。

5. 保存パス全体を確認する

設定を1つ変更した後、小さなテスト文書で明確な編集を行い、保存が完了するまで待ってから、Nextcloudから文書を閉じて再度開きます。編集内容が保持されていること、および対応するログにリダイレクト、接続エラー、またはストレージ例外が記録されていないことを確認してください。

テストが成功しても元のファイルが失敗する場合は、権限、外部マウント、または同時編集を確認してください。すべてのコールバックが失敗した場合は、ローカルコピーを保持し、タイムスタンプ、HTTPステータス、バージョン、およびサニタイズされたログを添えてエスカレーションしてください。JWT、Cookie、署名付きURL、および個人ファイル名は削除してください。

これらの手順は、保存エラーの一般的な原因であるコールバック、ルーティング、およびストレージの問題に対処します。具体的な修正方法は、ログ内の最初のエラー発生箇所によって異なります。接続チェックが成功しただけでは、保存ワークフロー全体が正常に機能しているとは言えません。

公式資料

• ONLYOFFICE Nextcloud連携：サーバーアドレス、コールバックフロー、接続チェック
• ONLYOFFICEドキュメントのトラブルシューティング：保存エラーとコールバックの到達可能性
• Nextcloud 35 管理マニュアル：トランザクションファイルロック
• Nextcloud 管理マニュアル: ログ設定

ドキュメントは2026年10月9日に確認済みです。コネクタのフィールドとログ出力先は、インストールされているアプリのバージョンとデプロイメント構成によって異なる場合があります。