Résoudre les blocages à 99 % lors du chargement de fichiers sur ownCloud : Guide pratique de dépannage

Un chargement sur ownCloud qui atteint 99 % puis semble se bloquer ne se résout généralement pas en relançant le chargement à plusieurs reprises. À ce stade, le navigateur a peut-être déjà transféré la majeure partie, voire la totalité, du fichier pendant que le serveur effectue encore des opérations telles que la réception du dernier segment, l'assemblage des segments, le déplacement du fichier finalisé vers sa destination, la mise à jour des métadonnées ou la libération des verrous. Le pourcentage seul ne permet pas d'identifier la cause du problème ; la méthode la plus rapide consiste donc à vérifier les informations côté serveur dans un ordre précis.

Ce guide utilise la documentation d'administration actuelle d'ownCloud Server 11.0, disponible en octobre 2026. Les mêmes principes s'appliquent à de nombreux déploiements ownCloud Classic, mais les chemins de configuration et le comportement de Docker peuvent différer sur les versions antérieures. Avant de modifier les limites, vérifiez votre version installée et votre méthode de déploiement.

Liste de contrôle pour un diagnostic rapide

1. Reproduisez le problème une fois, puis examinez immédiatement les journaux.

Effectuez un seul chargement contrôlé d'un fichier reproduisant systématiquement le problème et notez l'heure exacte. Ensuite, examinez les journaux ownCloud, PHP et d'erreurs du serveur web aux alentours de cet horodatage. Évitez d'effectuer plusieurs modifications de configuration au préalable ; cela compliquerait l'identification de la couche défaillante.

La documentation officielle de dépannage d'ownCloud recommande explicitement de consulter en premier lieu les journaux PHP, Apache et ownCloud. Dans un déploiement Docker standard, ownCloud indique que les sorties Apache et PHP sont acheminées via stdout/stderr du conteneur, et suggère de suivre les journaux du conteneur avec ` docker compose logs owncloud -f.`.

Vous pouvez également obtenir le journal d'ownCloud depuis l'interface d'administration. Le journal d'ownCloud et le guide de configuration indiquent la procédure à suivre : Paramètres > Administration > Général. Une occ configreport:generateoption permet également d'obtenir un rapport de configuration plus complet.

Quels messages de journalisation devez-vous rechercher ?

Concentrez-vous sur la première erreur associée à la requête ayant échoué, et non sur tous les avertissements qui suivent. Les catégories utiles incluent les délais d'attente de requête, l'espace de stockage insuffisant, l'impossibilité de créer ou de renommer un fichier temporaire, les erreurs d'autorisation, les exceptions WebDAV, les réponses HTTP 413/502/504 et les échecs de verrouillage de fichiers. Si vous activez temporairement le niveau de journalisation DEBUG pour ownCloud, rétablissez-le au niveau normal par la suite ; ownCloud indique qu'une journalisation détaillée peut affecter les performances du serveur. Consultez la documentation officielle sur la configuration de la journalisation .

2. Vérifiez l'espace libre dans les deux emplacements temporaires et dans l'espace de stockage final.

Il s'agit d'un des contrôles les plus importants pour un blocage à 99 %. ownCloud Server 11.0 explique que les chargements peuvent utiliser plusieurs zones temporaires. Le répertoire temporaire de chargement PHP doit disposer d'espace pour les fragments actifs, tandis que le répertoire de chargement de l'utilisateur stocke les fragments d'un fichier jusqu'à la fin du chargement.

D'après la documentation d'ownCloud relative au chargement de fichiers volumineux , l'espace PHP temporaire doit être prévu en fonction du nombre de chargements simultanés multiplié par la taille des fragments. Plus important encore pour un fichier unique volumineux, le répertoire de chargement de l'utilisateur doit temporairement disposer d'un espace équivalent à la taille du fichier final, car il stocke les fragments jusqu'à la fin de l'assemblage. Une fois le chargement terminé, ownCloud écrit les fragments dans le répertoire de destination final, puis les supprime.

Vérifiez le système de fichiers contenant le répertoire de données, le répertoire temporaire PHP et tout emplacement configuré OWNCLOUD_DAV_CHUNK_BASE_DIR. Vérifiez également la destination réelle, surtout s'il s'agit d'un stockage externe. Un serveur peut disposer de beaucoup d'espace libre /alors qu'un volume de données distinct peut être plein.

Ne déplacez pas manuellement de fichiers dans ou hors du répertoire de données ownCloud pour « finaliser » le chargement. ownCloud avertit que son répertoire de données est exclusif à l’application ; toute modification directe peut entraîner des incohérences de synchronisation et de base de données.

3. Confirmer le quota avant d'augmenter les limites techniques

Un quota utilisateur peut bloquer un fichier final volumineux, même si la zone de transit dispose de suffisamment d'espace. Vérifiez le quota de l'utilisateur concerné et, le cas échéant, la capacité et les autorisations du périphérique de stockage externe. Un test utile consiste à transférer le même fichier vers un autre compte ou une autre destination disposant manifestement d'un espace suffisant. Si l'échec est lié à l'utilisateur ou au dossier plutôt qu'au fichier, le quota ou la politique de stockage est alors la cause principale.

4. Vérifiez les paramètres de téléchargement PHP et ownCloud

Si les journaux font état de limites de taille de requête ou d'exécution, vérifiez les paramètres PHP effectifs plutôt que de supposer que les valeurs d'un php.inifichier aléatoire sont actives. Les directives courantes incluentpost_max_size : ` upload_max_filesizerequest_size`, ` request_size`, `request_size`, `request_size` , `request_size` et ` upload_tmp_dirrequest_size` .max_input_timemax_execution_timememory_limit

Pour la configuration du serveur ownCloud 11.0 Dockerisé prise en charge, la documentation associe ces éléments aux variables d'environnement suivantes : OWNCLOUD_MAX_UPLOAD`<environment_var> `, OWNCLOUD_TEMP_DIRECTORY`<environment_var> `, OWNCLOUD_MAX_INPUT_TIME`<environment_var> OWNCLOUD_MAX_EXECUTION_TIME`, `<environment_var>` et ` OWNCLOUD_MEMORY_LIMIT<environment_var>`. Ceci est important car ownCloud indique que les déploiements utilisant sa configuration Docker doivent utiliser les variables d'environnement fournies plutôt que de s'appuyer sur d'anciens .htaccessmodèles PHP ou de personnalisation.

N'imposez pas systématiquement des limites extrêmement élevées. Mieux vaut viser une valeur qui prenne en compte la taille maximale de vos fichiers et la connexion la plus lente possible, tout en garantissant la continuité de service.

5. Vérifiez la durée de la session pour les chargements lents.

ownCloud précise que cette valeur session_lifetimene doit pas être inférieure à la durée maximale d'envoi prévue. Si vous l'avez personnalisée, définissez-la sur au moins la durée en secondes de l'envoi le plus long prévu, ou supprimez toute valeur personnalisée inutile et rétablissez le comportement par défaut.

Il est particulièrement important de vérifier cela lorsqu'un fichier de 500 Mo se termine correctement, mais qu'un fichier de plusieurs gigaoctets échoue systématiquement après un laps de temps sensiblement équivalent.

6. Testez séparément le proxy inverse ou le CDN.

La documentation d'ownCloud concernant les fichiers volumineux indique que les proxys côté client et les services comme Cloudflare peuvent restreindre les chargements. Par conséquent, même avec une configuration ownCloud/PHP optimale, un problème peut survenir si un autre serveur limite la taille de la requête, met en mémoire tampon une requête longue, ferme une connexion inactive ou attend la fin du processus de chargement sur ownCloud.

Si votre architecture permet un test d'administration sécurisé, comparez le même chargement via la voie publique habituelle et via un chemin contournant le proxy inverse ou le CDN. Si le chemin direct réussit, consultez la documentation officielle de cet intermédiaire concernant la taille des requêtes, le délai d'expiration du chargement, la mise en mémoire tampon et le comportement WebDAV. Ne fragilisez pas le protocole TLS et n'exposez pas le serveur publiquement pour effectuer ce test.

7. Vérifier le verrouillage des fichiers en cas d'échec des chargements lors de la finalisation.

Le verrouillage transactionnel des fichiers est activé par défaut et les protège contre les modifications simultanées. ownCloud indique que ce verrouillage est également important lors de l'assemblage des chargements par blocs. Sur les serveurs très sollicités, un problème de verrouillage peut se manifester par un transfert terminé mais n'ayant pas pu être validé correctement.

Avant de modifier ce sous-système, veuillez consulter la documentation relative au verrouillage transactionnel des fichiers . ownCloud recommande l'utilisation d'un cache en mémoire pour le verrouillage lors de charges de travail importantes, plutôt que de s'appuyer sur le verrouillage de la base de données. Dans les déploiements en cluster, le verrouillage Redis partagé est particulièrement important, car chaque nœud d'application doit avoir accès au même état de verrouillage.

Il existe également un cas particulier documenté pour les chargements très longs vers les dossiers publics lorsque le découpage en segments n'est pas activé. ownCloud indique que les chargements durant plus d'une heure peuvent nécessiter un espace disque suffisamment importantOWNCLOUD_FILELOCKING_TTL ; sinon, le nettoyage de la mémoire par Redis peut supprimer le verrou acquis au début de l'opération. Ne modifiez pas ce paramètre sauf si votre chemin de chargement correspond à ce scénario.

8. Procéder à un nouveau test méthodique après chaque modification.

Après avoir corrigé un problème identifié, réessayez avec le même fichier, le même compte, la même destination, le même navigateur et le même chemin réseau. Vérifiez ensuite trois points : le transfert doit être terminé, le fichier doit apparaître à la destination avec la taille attendue et les journaux ne doivent contenir aucune nouvelle erreur pour cette requête.

Une progression utile consiste à procéder par petits fichiers, puis par fichiers de taille moyenne, et enfin par fichiers de la taille ayant initialement posé problème. Si les petits fichiers sont toujours acceptés, mais que les échecs surviennent au-delà d'une certaine taille, concentrez-vous sur la capacité de stockage et les limites de taille. Si les échecs surviennent après une durée constante, examinez les sessions et les délais d'expiration. Si les échecs se produisent uniquement via un nom d'hôte ou un chemin réseau spécifique, concentrez-vous sur les serveurs proxy et les équilibreurs de charge.

Ce qu'il ne faut pas faire

• Ne réessayez pas systématiquement un transfert de plusieurs gigaoctets sans consulter les journaux. Les échecs répétés de transfert de fichiers consomment du temps et peuvent temporairement saturer l'espace de stockage.
• Ne modifiez pas manuellement le répertoire de données ownCloud. Utilisez ownCloud, WebDAV ou les outils d'administration compatibles.
• Ne désactivez pas le verrouillage des fichiers comme première solution. Le verrouillage protège l'intégrité des données ; il est préférable de diagnostiquer le système sous-jacent.
• Ne présumez pas qu'un paramètre PHP est effectif simplement parce qu'il figure dans un fichier de configuration. Les conteneurs, PHP-FPM, les modules Apache et plusieurs emplacements INI peuvent produire des paramètres effectifs différents.
• N'augmentez pas indéfiniment le délai d'attente. Identifiez la couche qui ferme la requête et définissez une limite adaptée à la taille maximale des données transmises.

Chemin de décision pratique

Si vous avez besoin d'une procédure simplifiée, suivez cet ordre : reproduire le problème une fois ; consulter les journaux ownCloud/PHP/serveur web ; vérifier le stockage des données, temporaire et par blocs ; vérifier le quota ; confirmer les paramètres de chargement et de durée effectifs ; examiner la durée de vie des sessions ; contourner ou examiner le proxy inverse/CDN ; puis analyser le verrouillage transactionnel. Cet ordre privilégie les preuves et les contraintes d'infrastructure les plus probables avant d'entreprendre des modifications de configuration risquées.

Il est important de noter que « 99 % » n’est pas un code d’erreur en soi. Cela indique où l’utilisateur a constaté le problème, et non quel composant en est la cause. La solution fiable consiste à faire correspondre l’horodatage de l’échec de chargement avec les données stockées, le délai d’attente, le proxy, la session ou le verrouillage sur le serveur.