[Nextcloud] Error: Sabre\DAV\Exception\BadRequest: Expected filesize of xxx bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) yyy bytes

Services Stockage/ partage de documents
#1

Bonjour,

je vous soumets un problème Nextcloud, des fois que certain⋅es l’ont déjà résolu. J’ai beaucoup cherché et testé des solutions sur le forum Nextcloud et ownCloud, mais rien n’y fait, donc si quelque a la solution miracle :smiley: …

L’erreur dans les logs serveurs est :
Error: Sabre\DAV\Exception\BadRequest: Expected filesize of 568796 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 81920 bytes
Et ça produit chez les utilisateurs des conflits de fichiers et des erreurs de synchro récurrentes.

  • Utilisateurs : 8 postes Windows 10, 1 Mac, tous à jour 2.6.4 (pas passé la 2.6.5 qui vient de sortir)
  • Serveur LAMP sur Debian 10, Nextcloud 18.0.6

J’ai testé :

Voilà, si quelqu’un a une idée, je prends !!

#2

C’est un serveur LAMP avec mod_php ou php-fpm ? Tu as vérifié la config de PHP ? Il y a un firewall configuré sur la machine avec des règles particulières?

#3
  • LAMP avec mod_php
  • ufw (donc iptables) avec ports 80, 443 et 3478 (serveur TURN)

Pour la config de PHP, j’ai fais les modifs habituelles (post_max_size, upload_max_filesize, max_file_uploads, opcache.*)

#4

@esprit-libre je vois que tu as débusqué le bug report correspondant :slight_smile:

#5

Oui :slight_smile:
Et merci de m’aider !

Pour vous informer de là où j’en suis…
Sur mon serveur j’héberge plusieurs instances de Nextcloud, toutes en version 18.0.6. J’ai contrôlé config.php et .htaccess et je n’ai pas vu de différences (excepté les variables propres à l’instance).
Toutes les instances utilisent donc la même configuration de Apache, PHP et MariaDB, et c’est pourtant la seule instance problématique.

J’en suis donc à penser que le problème vient des postes utilisateurs. Je dois le vérifier mais j’ai l’impression que les clients font une sorte de ping-pong avec les mêmes fichiers…

Je vais donc tenter la version nc-client 2.6.5 fraichement livrée.

1 Like
#6

Bonjour,

Sinon il sera peut-être nécessaire de refaire une synchro complète.
Les rares fois où j’ai eu un problème de synchro avec un fichier, je le déplaçais hors de nextcloud, j’attendais que la synchro se fasse correctement, puis je le replaçais dans nextcloud. Cela suffisait.

#7

Après de (très) nombreuses investigations, il s’avère qu’en faisant un retour en 2.6.2 du client sur chacun des postes, le problème disparait ! La version 2.6.5 ne corrige pas le problème.

Je n’ai pas plus d’explications, juste l’intuition (en lisant les Release Notes) que les corrections/ajouts à propos de HTTP2 dans les versions qui suivent y seraient pour quelque chose. En tout cas des problèmes avec HTTP2 était une des pistes qui revenait régulièrement sur les forums.

Mais je dois être dans une configuration spéciale avec ce client, car c’est le seul qui rencontre des problèmes de synchro de ce type, et les autres clients qui ont des logs similaires (mais beaucoup moins nombreux, très ponctuels), n’ont pas de soucis.

1 Like
#8

Bonjour , j’ai ce problème récurrent quand un client resync un gros rep de fichiers pas forcément gros.

du coup ça sature très vite son upload ADSL et je penses que les echecs viennent de la , la socket est coupé coté client , ou bien qu’il y a un temps limite de transfert d’un bloc ( 1 Mo ) dans mon cas coté serveur que l’upload limité ne peux pas honorer.

est ce que cela peut etre une cause chez ton client ?

#9

Pour ce client on a réalisé plusieurs choses :

  • passage PostgreSQL : baisse notable des erreurs
  • retour en 2.6.2 de tous les postes clients : baisse légère du problème sur certains ordi seulement
  • changement de serveur pour un plus performant : autre baisse notable des erreurs

Donc il y avait clairement un problème de performance sur le serveur, et peut-être lié à MariaDB qui gère (mal?) plusieurs bases de clients différents.

Par contre, même après tous ces changements, le problème persiste sur quelques postes de façon ponctuelle. Pas de solution et j’ai laché l’affaire car cette fois le client ne s’en plaint plus.

#10

Bonjour,
J’ai ce même problème. Un dossier composé d’une multitude de petits fichiers. La synchronisation échoue avec ce message : « L’étape de découverte a échoué. »
Avez-vous réglé ce problème ?

#11

Bonjour,
Je suis tombé sur ce thread en cherchant à solutionner le même problème et malgrés un grand nombre de modifs de conf à droite à gauche (dans les tailles d’upload php, la taille des buffers dans nginx, les timeouts divers et variés) ça marchait toujours pas pour des clients avec des upload faibles.
J’ai l’impression d’avoir résolu le problème avec la modification de la taille des « tronçons » de fichier que Nextcloud gère en interne pour l’appli files. J’ai réduit cette taille pour ne pas faire sauter des timeouts dans l’appli. J’ai passé ce chunk size de 10MB à 1MB.

sudo -u www-data php occ config:app:set files max_chunk_size --value 1048000

#12

Merci pour cette réponse.
Pour ma part, pour régler temporairement mon problème j’étais repassé en 2.6.2 côté client et j’avais bloqué la version du paquet pour éviter les mise à jour sur ma distrib. J’essayerai votre solution quand j’aurais un peu de temps devant moi.