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

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 !!

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?

  • 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.*)

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

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

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.

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

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 ?

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.