Главная
» Как сделать
»
Отслеживание события обратного вызова сохранения, когда ONLYOFFICE не сохраняет файлы в Nextcloud.
Отслеживание события обратного вызова сохранения, когда ONLYOFFICE не сохраняет файлы в Nextcloud.
Гипотетический пример: Мина редактирует план проекта в ONLYOFFICE из папки Nextcloud. Редактор открывает и принимает ее изменения, но позже Nextcloud сообщает: «Документ не может быть сохранен». Этот пример является иллюстративным, а не отчетом о реальном тестировании. В этой ситуации оставьте редактор открытым, сохраните локальную копию несохраненной работы и проверьте, может ли ONLYOFFICE Docs напрямую обращаться к функции сохранения Nextcloud. Затем используйте журналы, чтобы отличить сбой маршрутизации обратного вызова от проблемы с хранилищем или правами доступа Nextcloud.
Индикатор сохранения редактором полезен, но после закрытия сеанса редактирования убедитесь, что обновленный файл присутствует в Nextcloud.
1. Защитите изменения Мины перед устранением неполадок.
Не закрывайте и не обновляйте редактор, пока в нем содержатся изменения, которые Nextcloud не сохранил. Используйте опцию «Загрузить как» , чтобы сохранить локальную копию для восстановления, если редактор продолжает отвечать. Запишите время и имя файла, когда сохранение не удалось, чтобы администратор мог сопоставить данные с журналами.
Проверьте небольшой файл DOCX в стандартной папке Nextcloud. Если он сохраняется, сосредоточьтесь на правах доступа к исходному файлу, статусе общего доступа, объеме хранилища или формате. Если все файлы не сохраняются, начните с проверки маршрута обратного вызова общего доступа и состояния сервера.
2. Проверьте функцию обратного вызова для сохранения данных между серверами.
ONLYOFFICE Docs отправляет POST-запрос на URL-адрес обратного вызова, предоставленный коннектором Nextcloud. Затем Nextcloud получает отредактированный файл и обновляет его сохраненную версию. Редактор может открыться нормально, но не сохранить файл, если Document Server не может отправить запрос обратно в Nextcloud.
Воспроизведите проблему с помощью тестового файла, затем сравните логи DocService и Nextcloud в этот момент. В Linux логи ONLYOFFICE находятся в каталоге /var/log/onlyoffice/documentserver/; в Docker проверьте логи контейнера или смонтированный каталог логов. Файл логов Nextcloud по умолчанию находится nextcloud.logв каталоге данных, если только log_typeили logfileне изменить это.
301, 302 или 308: перенаправления URL-адресов обратного вызова, часто между HTTP/HTTPS или именами хостов.
Ошибка тайм-аута или DNS: сервер документов не может разрешить или получить доступ к URL-адресу.
403 или 404: запрос может быть отклонен прокси-сервером, правилом доступа, переадресацией пути или настройками хоста.
Ошибка хранилища Nextcloud: поступил обратный вызов; проверьте квоту, права доступа, состояние хранилища или блокировки.
Внутренние адресные поля коннектора используются для маршрутизации между серверами в тех случаях, когда общедоступные URL-адреса недоступны с обоих серверов.
3. Исправьте URL-адрес или маршрут прокси-сервера при перенаправлении обратного вызова.
В Nextcloud откройте «Настройки» > «Администрирование» > «ONLYOFFICE» . Убедитесь, что публичный адрес ONLYOFFICE Docs совпадает с URL-адресом, который должны загружать браузеры пользователей. Если два сервера не могут связаться друг с другом по своим публичным адресам, установите соответствующие внутренние поля: «Адрес ONLYOFFICE Docs» для внутренних запросов с сервера и «Адрес сервера» для внутренних запросов от ONLYOFFICE Docs . Первый должен работать при взаимодействии Nextcloud с Document Server; второй должен работать при взаимодействии Document Server с Nextcloud.
В гипотетической конфигурации Мины функция обратного вызова использует http://cloud.example.comHTTPS и перенаправляет на него. Настройте конечный HTTPS-адрес напрямую, затем убедитесь, что DNS, правила брандмауэра и доверие к сертификатам позволяют Document Server получить к нему доступ. Прокси-сервер должен передавать функцию обратного вызова в Nextcloud без перенаправления схемы, имени хоста или пути. Пример имени хоста не подходит для реальных установок.
Проверка подключения в ONLYOFFICE может помочь подтвердить правильность настроенных адресов служб:
Запустите его из каталога Nextcloud от имени соответствующей учетной записи веб-сервера. Успешная проверка не доказывает работоспособность POST-запроса обратного вызова. Запрос HEAD, выполненный вручную, или страница в браузере по тому же имени хоста также не являются доказательством.
Этот концептуальный пример показывает, почему перенаправление в пути обратного вызова имеет значение; используйте фактические журналы Document Server для диагностики вашего маршрута.
4. Проследите за полученными данными в хранилище Nextcloud.
Если обратный вызов достигает Nextcloud, но файл по-прежнему не обновляется, проверьте журнал Nextcloud на наличие соответствующего запроса. Убедитесь, что у пользователя есть права на редактирование, что монтирование хранилища доступно, что учетная запись не превышает квоту, и что на томе данных есть свободное место и inode. Если проблема затрагивает общий файл, спросите, не изменяет ли его одновременно другой пользователь или клиент синхронизации, а затем протестируйте с копией в частной папке.
В Nextcloud транзакционная блокировка файлов координирует операции записи; не отключайте её в качестве быстрого решения. Если в журналах указывают на ошибки блокировки или базы данных, проверьте бэкэнд блокировки, а также службу Redis или Valkey. Не удаляйте oc_file_locksстроки или файлы блокировки, так как это может нарушить активные операции записи.
Если стандартная проверка папки проходит успешно, но проверка файла, хранящегося на внешнем носителе, завершается неудачей, проверьте доступность и режим аутентификации этого монтирования. В документации ONLYOFFICE описаны ограничения для некоторых режимов работы с внешними хранилищами; избегайте изменения учетных данных, пока не определите причину проблемы с монтированием.
После восстановления убедитесь, что обновленный файл находится в ожидаемой папке Nextcloud и имеет самое позднее время изменения.
5. Проверьте полный путь сохранения.
После изменения одной настройки внесите отдельные правки в небольшой тестовый документ, дождитесь завершения сохранения, затем закройте и снова откройте его в Nextcloud. Убедитесь, что изменения сохраняются и в соответствующих журналах отсутствуют перенаправления, сбои подключения или исключения хранилища.
Если тест пройден успешно, но исходный файл по-прежнему не проходит проверку, проверьте его права доступа, внешнее монтирование или одновременные изменения. Если все обратные вызовы завершаются неудачей, сохраните локальную копию и передайте управление с указанием метки времени, HTTP-статуса, версий и очищенных логов. Удалите JWT-токены, cookie-файлы, подписанные URL-адреса и имена личных файлов.
Эти шаги направлены на устранение распространенных причин ошибок сохранения, связанных с обратными вызовами, маршрутизацией и хранением данных. Точное решение зависит от первой точки сбоя в логах; одной лишь успешной проверки соединения недостаточно для подтверждения полного процесса сохранения.
Документация проверена 9 октября 2026 г. Поля коннектора и места назначения журналов могут различаться в зависимости от установленной версии приложения и конфигурации развертывания.