Lorsque les chargements sur ownCloud se bloquent à 99 %, vérifiez ces limites.

Lorsque la page des fichiers ownCloud reste bloquée à 99 %, vérifiez d'abord si le fichier complet se trouve déjà dans le dossier de destination avant de réessayer. S'il est manquant ou incomplet, demandez à l'administrateur de vérifier le quota utilisateur, l'espace libre dans les répertoires temporaires PHP et les répertoires de fragments ownCloud, ainsi que les limites de requêtes du serveur PHP et du serveur web. Un indicateur de 99 % ne suffit pas à identifier l'origine du problème.

Ce guide pratique explique comment téléverser des fichiers via l'interface web d'ownCloud Server (Classic) 10.16. Les téléversements en mode Infinite Scale et la synchronisation avec votre ordinateur utilisent des chemins d'accès et des journaux différents. Les exemples sont conformes à la documentation officielle de la version 10.16 ; adaptez les paramètres et les chemins d'accès à votre propre déploiement.

Triage rapide

1. Vérifiez l'état du téléchargement avant de réessayer.

Ouvrez le dossier de destination dans un nouvel onglet ou actualisez-le une fois le chargement terminé. Si le fichier est présent, comparez sa taille avec celle du fichier original local et ouvrez-le. Un fichier complet dont la barre de progression est figée indique un problème de confirmation de fin de chargement ou d'affichage du navigateur ; il est alors inutile de charger une deuxième copie.

Si le fichier est absent ou trop petit, essayez un petit fichier de test dans le même dossier, puis essayez le fichier original depuis un autre navigateur ou réseau si possible. Notez la taille du fichier, l'utilisateur, la destination, l'heure approximative et si le test a échoué. Ces comparaisons permettent de distinguer un problème lié à un seul fichier ou au client d'un problème global du serveur. Évitez d'annuler et de relancer sans cesse un chargement important pendant que le serveur le traite.

2. Vérifiez le quota, l'espace temporaire et les autorisations.

Demandez à l'administrateur d'ownCloud de vérifier le quota de l'utilisateur concerné et les droits d'écriture du dossier de destination. Une limite de quota peut empêcher l'enregistrement d'un nouveau fichier, même si le navigateur a déjà envoyé la plupart de ses données. Si la destination est un montage externe, vérifiez également l'espace disponible et les droits d'écriture de ce serveur.

Sur le serveur, vérifiez les blocs et inodes libres dans le répertoire de données et dans tous les répertoires temporaires concernés. Un inode est l'enregistrement du système de fichiers utilisé pour créer un fichier ; un volume peut avoir des gigaoctets libres mais aucun inode disponible. Utilisez les chemins d'accès réels définis dans votre configuration PHP et ownCloud :

df -h /path/to/owncloud-data /path/to/php-temp /path/to/chunk-temp
df -i /path/to/owncloud-data /path/to/php-temp /path/to/chunk-temp

Les fichiers PHP upload_tmp_dirdoivent être accessibles en écriture par le compte PHP/serveur web. ownCloud dispose également d'un paramètre de répertoire temporaire, et les chargements de fichiers sont stockés par défaut dans le répertoire de chargement de l'utilisateur. Lors de l'assemblage, ownCloud peut nécessiter un espace temporaire équivalent à la taille finale du fichier. Cet dav.chunk_base_diremplacement peut être modifié dans la configuration. Vérifiez tous ces volumes, et pas seulement le disque principal.

3. Adapter les limites de téléchargement et les délais d'expiration au fichier.

Si les petits fichiers fonctionnent mais pas les plus volumineux, comparez leur taille avec les paramètres PHP web effectifs : `<file>` upload_max_filesizeet `<file> post_max_size`. PHP exige post_max_sizeque `<file>` soit supérieur à upload_max_filesize`<file>`. Vérifiez la configuration PHP utilisée par le serveur web ou PHP-FPM ; la configuration PHP en ligne de commande peut être différente. Dans les configurations PHP-FPM, ownCloud indique que les paramètres PHP doivent être définis dans `<file>` .user.iniou la configuration FPM, et non uniquement dans `<file>` .htaccess.

Vérifiez également max_input_timeles temps de chargement anormalement longs et les délais d'attente d'exécution PHP si les journaux en font état. Définissez des limites adaptées à votre charge de travail prévue plutôt que de copier un exemple ; redémarrez PHP et le serveur web après toute modification de la configuration. Consultez la documentation de configuration du chargement de fichiers volumineux d'ownCloud et la documentation de la directive upload de PHP .

Vérifiez ensuite chaque couche HTTP en amont de PHP. Nginx client_max_body_sizerejette les requêtes trop volumineuses avec une erreur HTTP 413 ; configurez une limite suffisamment élevée pour la taille des requêtes utilisées par votre serveur d'envoi. Apache peut LimitRequestBodyégalement mod_reqtimeoutlimiter les envois. ownCloud signale spécifiquement que les proxys inverses, Cloudflare, les limites d'E/S de l'hébergement et les paramètres de délai d'expiration des requêtes Apache peuvent affecter les envois volumineux. Modifiez uniquement la couche concernée par les journaux et évitez de désactiver globalement les modules de sécurité comme première solution. Consultez la documentation officielle de Nginx concernant les corps de requêtes .

4. Utilisez les journaux pour localiser la couche défaillante.

Reproduisez le problème une fois en notant l'heure, puis consultez le journal d'ownCloud et le journal d'erreurs du serveur web ou du proxy pour la même minute. Le journal d'ownCloud se trouve généralement dans le répertoire de données configuré ; le chemin exact peut être modifié dans la configuration config.php. Recherchez les messages relatifs aux quotas, aux permissions, aux fichiers temporaires, aux verrous, à la taille des requêtes ou aux délais d'attente. Si la requête n'apparaît pas dans le journal d'ownCloud, examinez d'abord le proxy ou le serveur web.

tail -n 100 /path/to/owncloud.log

Remplacez l'espace réservé par le chemin configuré sur votre installation. Cette commande affiche uniquement les lignes de journal récentes ; elle ne modifie pas les données du serveur. Évitez de publier publiquement les journaux bruts sans supprimer les noms d'utilisateur, les chemins de fichiers, les adresses IP et les jetons. ownCloud explique l'emplacement des journaux dans sa documentation de débogage .

Vérifier la correction

• Téléversez un petit fichier, puis réessayez une fois avec le fichier concerné.
• Vérifiez que la copie de destination a la taille attendue et s'ouvre correctement.
• Vérifiez qu'aucune erreur de quota, de stockage, HTTP 413, d'autorisation ou de délai d'attente n'apparaît lors du chargement.
• Si le problème persiste, indiquez à l'administrateur la taille du fichier, sa destination, l'horodatage et l'entrée de journal correspondante afin qu'il puisse identifier la couche qui a bloqué la requête.

N’augmentez pas toutes les limites et ne désactivez pas les protections contre les requêtes simultanément. Une modification ciblée, suivie d’une seule tentative contrôlée, facilite la confirmation de la cause et préserve l’intégrité du reste de la configuration du serveur.