Limite d’upload Nextcloud : augmenter la taille des fichiers en 2026

Un petit document passe, mais une archive, une vidéo ou une sauvegarde échoue avant la fin. En 2026, la limite d’upload Nextcloud ne dépend pas d’un seul bouton. La requête traverse parfois un proxy, un serveur web, PHP, un espace temporaire puis le stockage final. La valeur la plus restrictive arrête le transfert.

Ce tutoriel aide à localiser cette couche avant de modifier la configuration. Il couvre PHP, Apache, Nginx, l’image Docker officielle, les envois découpés et les délais. Les valeurs d’exemple ne sont pas des recommandations universelles : partez du plus gros fichier réellement attendu, ajoutez une marge mesurée et testez la chaîne complète.

Pourquoi la limite affichée par Nextcloud ne suffit-elle pas ?

Un transfert depuis le navigateur peut envoyer un fichier par formulaire HTTP, par requête WebDAV ou en plusieurs morceaux. La documentation officielle sur les gros fichiers précise que upload_max_filesize et post_max_size ne s’appliquent pas nécessairement à une requête WebDAV PUT unique ou à un envoi découpé. Dans ces cas, les délais du serveur web et de PHP deviennent souvent la contrainte réelle.

L’architecture détermine donc le réglage à examiner :

Couche	Limite ou ressource	Symptôme fréquent
Proxy public	taille de requête, délai, tampon	erreur avant que Nextcloud n’écrive un journal
Apache ou Nginx	corps HTTP, lecture FastCGI, fichier temporaire	413, 504 ou coupure à une taille régulière
PHP	upload_max_filesize, post_max_size, délais	formulaire refusé ou traitement interrompu
Nextcloud	taille des chunks, tempdirectory	reprise difficile ou assemblage trop lent
Système	espace et permissions des dossiers temporaires	transfert qui bloque près de la fin
Stockage final	quota, espace, latence, objet distant	échec lors de l’écriture ou de l’assemblage

Le client utilisé compte aussi. Le navigateur, le client de bureau et un montage WebDAV ne découpent pas toujours les données de la même manière. Le guide Nextcloud WebDAV traite le montage et l’authentification. Ici, l’objectif est de régler la capacité du serveur, quel que soit le poste qui envoie le fichier.

Comment trouver la couche qui bloque le gros fichier ?

Ne commencez pas par placer toutes les limites à une valeur très élevée. Préparez trois fichiers sans données sensibles : un petit témoin, un fichier juste inférieur à la limite observée et un fichier légèrement supérieur. Notez pour chacun le client, l’heure de départ, la durée avant l’erreur et le code HTTP affiché par le navigateur ou le proxy.

Testez d’abord le même fichier depuis l’interface web puis depuis le client Nextcloud Desktop. Si le navigateur échoue immédiatement mais que le client de synchronisation progresse par morceaux, examinez le traitement des requêtes non découpées. Si les deux échouent au même moment, regardez plutôt le frontal, les délais, l’espace temporaire et le stockage.

Consultez les journaux dans l’ordre du trafic : proxy public, serveur web, PHP-FPM puis nextcloud.log. Une erreur absente des journaux Nextcloud peut avoir été rejetée avant l’application. À l’inverse, une exception enregistrée au moment de l’assemblage indique que la requête a déjà traversé les premières couches.

Voici des pistes de diagnostic, à confirmer dans vos propres journaux :

• 413 Request Entity Too Large conduit vers une limite de corps HTTP sur le proxy ou le serveur web ;
• 504 Gateway Timeout conduit vers un délai du frontal, de FastCGI ou du backend ;
• No space left on device impose de contrôler les partitions temporaires et finales ;
• une erreur de quota concerne le compte ou le stockage, pas upload_max_filesize ;
• une coupure après une durée constante oriente vers un délai plutôt que vers une taille.

Le guide de synchronisation Nextcloud complète cette méthode pour les conflits, les certificats, les chemins et les fichiers ignorés côté client.

Quels paramètres PHP modifier pour augmenter l’upload ?

Identifiez d’abord le fichier php.ini chargé par le service web. La configuration de la commande php lancée dans un terminal peut différer de celle de PHP-FPM ou du module Apache. Vérifiez le SAPI qui sert Nextcloud, puis modifiez son fichier ou son pool. N’exposez pas durablement une page phpinfo() au public.

Pour autoriser un fichier de 10 Gio avec une marge sur le corps de requête, une base de travail peut être :

upload_max_filesize = 10G
post_max_size = 11G
max_input_time = 3600
max_execution_time = 3600
output_buffering = 0
upload_tmp_dir = /srv/nextcloud-upload-tmp

Le manuel PHP de post_max_size indique que cette valeur doit dépasser upload_max_filesize. La marge absorbe les autres champs d’une requête de formulaire. Les délais de 3 600 secondes illustrent une fenêtre d’une heure, mais ils doivent être adaptés au débit minimal que vous acceptez et aux règles d’exploitation du serveur.

Le dossier upload_tmp_dir doit exister, être accessible au compte PHP et disposer d’assez d’espace. Un envoi peut consommer de la capacité temporaire avant d’atteindre le stockage final. Surveillez donc la partition pendant un test représentatif, pas seulement son espace libre au repos.

Après modification, contrôlez la syntaxe, rechargez le service concerné et relisez les valeurs depuis le contexte web. Un redémarrage de PHP-FPM ne recharge pas automatiquement Nginx, et l’inverse est également vrai. Conservez une copie de la configuration précédente pour revenir à l’état connu si le service refuse de repartir.

Comment aligner Apache, Nginx et le proxy inverse ?

Sous Apache, vérifiez LimitRequestBody, les délais et le mode d’exécution de PHP. Avec mod_fcgid, les paramètres de taille propres au module peuvent aussi intervenir. Avec mod_proxy_fcgi, contrôlez ProxyTimeout. La documentation Nextcloud recense ces familles de réglages, mais leur emplacement dépend du VirtualHost et des modules réellement chargés.

Sous Nginx, les directives les plus courantes sont :

server {
    client_max_body_size 11G;
    client_body_temp_path /srv/nginx-client-tmp 1 2;

    location ~ \.php(?:$|/) {
        fastcgi_read_timeout 3600;
    }
}

client_max_body_size fixe la taille maximale du corps accepté dans ce contexte Nginx. Le manuel officiel Nginx indique qu’un dépassement renvoie une erreur 413. Le dossier client_body_temp_path doit disposer de la capacité et des permissions nécessaires. La documentation Nextcloud signale aussi fastcgi_read_timeout lors de délais 504 pendant certaines opérations d’assemblage.

Si un proxy inverse se trouve devant le serveur Nextcloud, sa limite doit être au moins aussi haute que celle du backend. Il faut également aligner ses délais de lecture et d’envoi. Modifier PHP ne change rien si le frontal rejette la requête en premier. Le tutoriel sur le reverse proxy Nextcloud explique comment valider le protocole, les en-têtes et les journaux de chaque saut.

Avant le rechargement, validez la syntaxe avec l’outil du serveur, par exemple nginx -t ou apachectl configtest. Rechargez ensuite uniquement les services modifiés, puis répétez le test avec les mêmes fichiers. Changer simultanément cinq valeurs empêche d’identifier le réglage qui a réellement corrigé l’incident.

Comment régler la limite avec l’image Docker officielle ?

Le dépôt officiel de l’image Docker Nextcloud expose PHP_UPLOAD_LIMIT. Cette variable règle post_max_size et upload_max_filesize. Pour la variante Apache, APACHE_BODY_LIMIT fixe aussi la taille maximale du corps HTTP en octets. Le dépôt indique actuellement une valeur par défaut de 512 Mio pour la première et de 1 Gio pour la seconde.

Un exemple Compose pour viser 10 Gio côté PHP et garder une enveloppe Apache de 12 Gio :

services:
  app:
    image: nextcloud:apache
    environment:
      PHP_UPLOAD_LIMIT: "10G"
      APACHE_BODY_LIMIT: "12884901888"

Ces variables ne règlent pas un Nginx, un Traefik ou un autre frontal placé devant le conteneur. Elles ne créent pas non plus l’espace temporaire. Inspectez les volumes, la capacité du système de fichiers Docker et la configuration du proxy externe avant de conclure que le conteneur accepte réellement le fichier.

Après modification du fichier Compose, recréez le service selon votre procédure de déploiement, puis contrôlez son état et ses journaux. Ne supprimez pas les volumes persistants. Si vous utilisez l’image FPM plutôt que la variante Apache, APACHE_BODY_LIMIT ne traite pas le serveur web externe : la limite correspondante reste à définir dans Nginx ou le frontal choisi.

Faut-il modifier la taille des chunks Nextcloud ?

Les clients récents peuvent fractionner un gros fichier, envoyer les morceaux puis demander leur assemblage. Cette méthode facilite la reprise, mais elle ne supprime ni les délais ni le besoin d’espace temporaire. Une dernière opération peut encore déplacer ou assembler les données, ce qui explique certains 504 en fin de transfert.

Nextcloud propose files.chunked_upload.max_size. La documentation officielle indique une valeur par défaut de 100 Mio et conseille de rester entre 10 Mio et 5 Gio. Ne modifiez ce réglage qu’après avoir identifié un motif : réseau instable, frontal contraignant, stockage objet ou trop grand nombre de requêtes.

Pour fixer des morceaux de 20 Mio sur une installation classique :

sudo -E -u www-data php /var/www/nextcloud/occ \
  config:system:set files.chunked_upload.max_size \
  --type int --value 20971520

Une taille plus petite réduit le travail perdu après une coupure, mais augmente le nombre de requêtes et l’activité d’assemblage. Une taille plus grande diminue ce nombre, au prix de requêtes plus longues. Mesurez le résultat sur un fichier test et conservez la valeur précédente pour pouvoir revenir en arrière.

Si PHP ne peut pas utiliser un dossier temporaire adapté, Nextcloud permet aussi de définir tempdirectory dans config.php. Placez si possible les zones temporaires du serveur web, de PHP et de Nextcloud sur des partitions dimensionnées et rapides. La documentation recommande de limiter les déplacements entre systèmes de fichiers lors de l’assemblage.

Quelle recette valider avant la mise en production ?

Préparez une matrice avec l’interface web, le client de bureau et les autres clients réellement utilisés. Pour chaque parcours, envoyez un petit fichier, un fichier proche de la cible et le plus gros volume autorisé. Contrôlez le temps, le code HTTP, le journal correspondant et l’espace temporaire maximal consommé.

Validez ensuite ces points :

1. le proxy public accepte la taille et la durée prévues ;
2. Apache ou Nginx applique la nouvelle limite dans le bon VirtualHost ;
3. PHP-FPM charge le bon php.ini et les bonnes valeurs ;
4. les dossiers temporaires restent accessibles et suffisamment dimensionnés ;
5. le quota utilisateur et le stockage final disposent de la capacité nécessaire ;
6. le transfert reprend correctement après une coupure contrôlée si le client le permet ;
7. les journaux ne montrent ni délai, ni manque d’espace, ni erreur d’assemblage ;
8. les limites sont documentées avec leur unité et leur emplacement.

N’utilisez pas un fichier client réel pour la recette. Générez des données sans valeur, puis supprimez-les après les contrôles. Pour comprendre les autres composants de la plateforme, consultez le guide complet de Nextcloud.

Conclusion

Augmenter la limite d’upload Nextcloud consiste à aligner toutes les couches, pas à modifier une seule valeur PHP. Mesurez d’abord l’échec, identifiez le premier journal concerné, puis réglez le proxy, le serveur web, PHP, les chunks et l’espace temporaire. Testez plusieurs tailles avec les clients utilisés en production et gardez des plafonds adaptés au besoin réel afin de préserver les ressources du serveur.

Découvrir l’hébergement Nextcloud GaprodEspace Nextcloud géré en France, sans administration du serveur

Sources officielles

• Nextcloud : configuration des envois de gros fichiers
• Nextcloud : ajuster la taille des chunks
• Image Docker officielle Nextcloud : limites PHP et Apache
• PHP : directive post_max_size
• Nginx : directive client_max_body_size
• Apache HTTP Server : directive LimitRequestBody