NextcloudでONLYOFFICEの「ドキュメントを保存できませんでした」エラーを修正する

NextcloudでDOCXファイルを開き、ONLYOFFICEが正常に起動し、変更を加えた後、エディタから「ドキュメントを保存できませんでした」というエラーメッセージが表示されるとします。ブラウザがファイルを紛失したか、ONLYOFFICE自体がディスクに書き込めないのではないかと考えてしまいがちですが、Nextcloudとの連携においては、そこから原因究明を始めるのは多くの場合間違いです。

重要なのは、保存の仕組みです。Nextcloud は ONLYOFFICE Docs にドキュメント URL と を渡しますcallbackUrl。ONLYOFFICE はファイルをダウンロードし、編集セッションをホストした後、Nextcloud を呼び出して、Nextcloud が更新されたファイルを取得して保存済みのバージョンを置き換えるようにします。ONLYOFFICE の公式統合ドキュメントには、このコールバックのやり取りが明示的に記載されています。つまり、保存に使用される戻りパスが壊れていても、エディタは正常に開くことができます。対処法:開くことと保存することを 2 つの別々のネットワーク テストとして扱います。

エラーメッセージではなく、検証済みの動作から始めましょう。

現在の公式統合ドキュメントによると、ONLYOFFICEのNextcloudコネクタはサーバー間ワークフローを使用します。つまり、ドキュメントサーバーはNextcloudからアクセス可能でなければならず、Nextcloudもドキュメントサーバーからアクセス可能でなければなりません。編集が完了すると、ONLYOFFICEはコールバックURLにPOSTリクエストを送信します。するとNextcloudは編集されたドキュメントをダウンロードし、以前のバージョンを置き換えます。詳細については、ONLYOFFICE公式Nextcloud統合ガイドおよびONLYOFFICE APIのNextcloud統合に関する説明を参照してください。

検証済み：コールバックパスが不正または到達不能な場合、エディタが開いていても保存エラーが発生する可能性があります。ONLYOFFICEのトラブルシューティングドキュメントでは、保存エラーが発生した場合に、管理者がDocServiceログを確認し、コールバックURLに到達可能であることを確認するよう具体的に指示しています。対処方法：エディタの再インストールやブラウザのキャッシュクリアから始めず、まずサーバー間のパスをテストしてください。

1. コネクタの内蔵接続チェックを実行します。

Nextcloudホスト上で、WebサーバーユーザーとしてONLYOFFICEコネクタチェックを実行します。一般的なDebianまたはUbuntuのインストール環境では、以下の手順を実行します。

cd /var/www/nextcloud
sudo -E -u www-data php occ onlyoffice:documentserver --check

Nextcloud の正確なパスと HTTP ユーザーは、ディストリビューションやコンテナのレイアウトによって異なる場合があります。Nextcloud の管理マニュアルでは、occファイルの所有権が一貫しているように HTTP ユーザーとして実行することを推奨しています。ONLYOFFICE は、occ onlyoffice:documentserver --checkコネクタ接続テストとしてドキュメント化しています。

このテストで証明されること：ドキュメントサーバーの設定エラーや接続エラーが明らかになる場合がある。証明されないこと：実際の編集セッション中に生成されるすべてのコールバックが、すべてのプロキシ、DNSルート、認証レイヤーを通過すると必ず成功するとは限らない。対処法：チェックに合格しても保存が失敗する場合は、統合が正常であると宣言するのではなく、コールバックとログの処理を続行する。

2. 公開サーバーアドレスと内部サーバーアドレスの両方を確認する

Nextcloudで、[設定] → [管理] → [ONLYOFFICE]を開きます。メインのONLYOFFICE Docsアドレスは、関連するクライアントとサービスからアクセスできる必要があります。Dockerネットワーク、NAT、スプリットホライズンDNS、またはファイアウォールポリシーが原因でパブリックURLが内部的にルーティングできない場合は、詳細サーバー設定を展開してください。

公式コネクタは、まさにこのような状況に対応するために、個別の内部アドレスを公開しています。

• ONLYOFFICE Docs サーバーからの内部リクエスト用のアドレス: Nextcloud が ONLYOFFICE にアクセスするために使用するアドレス。
• ONLYOFFICE Docs からの内部リクエスト用のサーバーアドレス: ONLYOFFICE がコールバックや関連するサーバー間トラフィックのために Nextcloud にアクセスする際に使用するアドレス。

例えば、同じ Compose ネットワーク上の 2 つのコンテナは、内部的にはサービス名を使用できる一方で、ブラウザは依然として公開 HTTPS ホスト名を使用する場合があります。このパターンを盲目的にコピーしないでください。名前は実際にネットワーク内で解決される必要があります。対処方法：リクエストの発信元となるマシンまたはコンテナから、各方向をテストしてください。

よくある誤解：「エディタが開くから、DNSとルーティングは問題ない」

その結論は信頼できません。ブラウザ、Nextcloud、ONLYOFFICE Docsはそれぞれ異なるネットワーク参加者です。ブラウザはアクセスできるかもしれoffice.example.comませんが、ドキュメントサーバーコンテナは名前解決や接続ができない可能性cloud.example.comがあります。同様に、Nextcloudは内部ホスト名を介してONLYOFFICEにアクセスできるかもしれませんが、コールバックは到達不可能なパブリックアドレスを指している可能性があります。

手順： ONLYOFFICEコンテナまたはホストに入り、使用される予定のNextcloudアドレスをテストします。Nextcloudホストへの基本的なHTTPSリクエストにより、DNS/TCP/TLSの到達可能性を確認できますが、status.phpリクエストが成功したとしても、実際のコールバック認証やPOST処理が検証されたわけではないことに注意してください。

3. プロキシルールを変更する前にJWTを確認してください

JWTもまた、よく混乱を招く要因の一つです。ONLYOFFICE Docs 7.2以降、JWTはデフォルトで有効になっており、秘密鍵が自動的に生成されます。公式の手順では、ドキュメントサーバーとNextcloud ONLYOFFICEコネクタの両方で同じ秘密鍵を使用する必要があるとされています。また、現在のコネクタのドキュメントでは、デフォルトのヘッダーを使用しないインストール環境向けに、authorization-headerの設定についても説明しています。

検証済み:共有シークレットは一致する必要があります。デプロイメント依存:管理する正確な場所は、ONLYOFFICE がパッケージからインストールされているか、Windows にインストールされているか、Docker にインストールされているかによって異なります。Docker デプロイメントでは、JWT_SECRET環境変数が一般的に使用されます。有効なサーバー構成は、でも確認できます/etc/onlyoffice/documentserver/local.json。

対処方法：両側の有効なシークレットとヘッダーの設定を比較し、サーバー側で変更を加えた後はONLYOFFICEサービスまたはコンテナを再起動してください。JWTを恒久的に無効にして問題を「解決」しないでください。これは設定を修正するのではなく、セキュリティ制御を削除することになります。詳細はONLYOFFICEのJWT設定ガイドを参照してください。

4. 保存失敗時の ONLYOFFICE と Nextcloud のログを確認する

ONLYOFFICE では、保存エラーがないか DocService のログを確認することを推奨しています。Linux および Docker インストールの場合、ドキュメント サーバーのログは にあります。Docker/var/log/onlyoffice/documentserverユーザーは、 を使用してコンテナの出力を追跡することもできます。さらに詳細な情報が必要な場合は、または log4js の設定docker logs -f <container>を使用して一時的なデバッグ モードをドキュメント化しています。公式のデバッグ ロギング ガイドを参照してください。DS_LOG_LEVEL=DEBUG

Nextcloudでは、デフォルトのファイルベースのログは通常、nextcloud.log設定済みのデータディレクトリに保存されます。アクティブなパスは、以下のコマンドで確認できます。

sudo -E -u www-data php occ log:file

Nextcloud は、ログ リーダー アプリが利用可能になったときにlog:tailもドキュメントを作成します。対処方法:保存失敗を 1 回再現し、タイムスタンプを記録してから、両方の側面を関連付けます。ネットワーク拒否、TLS エラー、401/403 レスポンス、5xx レスポンス、またはストレージ例外は、それぞれ異なる修正方法を示しています。log:watch

5. 本番環境のセキュリティを損なうことなく、TLSとリバースプロキシの問題を修正する

自己署名証明書または私的発行証明書は、対応する認証局（CA）が信頼されていない場合、サーバー間HTTPS接続を破綻させる可能性があります。コネクタには「証明書検証を無効にする（安全でない）」オプションがありますが、ONLYOFFICEはこれを安全でないと明記し、信頼できるCAが発行した証明書に置き換えることを推奨しています。対処法：証明書検証のバイパスは、管理された環境での短時間の診断手順としてのみ使用してください。恒久的な解決策は、両方のサーバーが信頼する有効な証明書チェーンを使用することです。

ONLYOFFICEの前にリバースプロキシが設置されている場合は、想定されるスキーム、ホスト、およびアップグレード動作が維持されていることを確認してください。ONLYOFFICEは、転送ヘッダーやWebSocket関連の設定など、リバースプロキシに関する専用のガイダンスを公開しています。ONLYOFFICEのNextcloudリバースプロキシ設定ガイドを参照してください。

デプロイメントに依存します。保存エラーだけでは、Nginx、Apache、Traefik、HAProxy、ingress-controller、またはCDNの正確な構成を推測することはできません。対処方法：タイムアウトやヘッダーを無作為に変更する前に、ご使用のトポロジーに対応するベンダー提供のプロキシ構成例と比較し、コールバック中に記録されたHTTPステータスを確認してください。

6. コールバックがNextcloudに到達した場合、ストレージと書き込みエラーを確認します。

ログでコールバックがNextcloudに正常に到達したことが確認できたら、スタックを下に進みます。Nextcloudは新しいドキュメントを取得して、保存されているバージョンを置き換える必要があります。ローカルファイルシステムのアクセス許可、読み取り専用マウント、ディスク容量不足、クォータ制限、外部ストレージの利用不可、またはアプリケーション/ストレージ例外などが原因で、最終的な書き込みが妨げられる可能性があります。

既知の情報： ONLYOFFICEのコールバックステータス値は、保存準備完了のドキュメントと保存エラーを区別し、コールバックにはストレージサービスが取得するための編集済みドキュメントへのURLが含まれています。公式のコールバックハンドラーのドキュメントでは、ステータス2は保存準備完了、ステータス3は保存エラーと定義されています。

ブラウザのメッセージだけでは、エラーがONLYOFFICE、ネットワークパス、Nextcloud、または基盤となるストレージのいずれで発生したのかがわかりません。対処法：エディタが保存できないと表示したからといって、Nextcloudデータディレクトリ上のファイルの所有権を再帰的に変更しないでください。まず、Nextcloudのログでストレージ側のエラーを確認してください。

7. 保存ボタンと強制保存の動作を理解する

もう一つの誤解は、保存ボタンを押すたびにNextcloudに保存されているファイルが即座に置き換えられるというものです。コネクタは、中間保存または強制保存のオプションを使用できます。公式の統合ガイドによると、 「編集時に中間バージョンを保持する（強制保存）」が有効になっている場合、保存をクリックすると変更がストレージに直接送信されます。そうでない場合は、変更はエディタのキャッシュに保持され、通常の最終保存ワークフローが後で実行されます。

これはトラブルシューティングにおいて重要です。強制保存だけが失敗し、通常の閉じて保存が成功する場合、またはその逆の場合、タイムスタンプとコールバックステータスは貴重な証拠となります。対処法：手動での保存、ブラウザの閉じる操作、複数のエディタタブの同時使用などを混在させるのではなく、明確に定義された単一のワークフローで失敗を再現し、その試行時のログをキャプチャしてください。

クイック診断表

修正内容を確認する方法

重要度の低いフォルダに小さなテスト用DOCXファイルを用意します。ONLYOFFICEでファイルを開き、タイムスタンプなどの固有の行を入力します。エディタが変更を保存したと報告するまで待ち、その後、通常どおりエディタを閉じます。Nextcloudからファイルを再度開き、テキストが存在することを確認します。次に、デプロイメントでバージョン履歴を使用している場合は、バージョン履歴を調べ、同じ期間のサーバーログを確認します。

次に、コネクタのチェックを再度実行します。

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

良い結果とは、単に「エディタが開く」ことだけではありません。完全なテストとは、NextcloudがONLYOFFICEに接続でき、ONLYOFFICEがNextcloud上のコールバックアドレスに接続でき、認証が成功し、Nextcloudが更新されたファイルを取得でき、ストレージバックエンドが置換を受け入れることです。

原因がまだ不明な場合

ログに明らかな障害が見られない場合は、再現手順を一度だけ実行する際に、ONLYOFFICEとNextcloudのログレベルを一時的に上げ、その後、通常のログレベルに戻してください。Nextcloudは、DEBUGログは冗長でパフォーマンスに影響を与える可能性があるため、本番環境での恒久的な設定ではなく、診断手段として使用すべきであると警告しています。ログレベルを変更する前に、 Nextcloudのログに関するドキュメントを確認してください。

その時点で、正確なタイムスタンプ、HTTPステータスコード、コネクタバージョン、Nextcloudバージョン、ONLYOFFICE Docsバージョン、トポロジ、および関連する編集済みログ行を保存してください。これらの情報は、ブラウザの一般的な「ドキュメントを保存できませんでした」というメッセージよりもはるかに有用です。

公式資料

• ONLYOFFICE：Nextcloud連携ガイド
• ONLYOFFICEドキュメント APIトラブルシューティング
• ONLYOFFICEコールバックハンドラーAPI
• ONLYOFFICE JWT設定
• Nextcloudのログ設定