Comment augmenter la taille des fichiers synchronisés >512 Mo sur Nextcloud

bien le bonjour. je fais suite a ce topic car j’ai un soucis similaire avec des fichier supérieur a 2Go, que sa sois via le client (windows) ou le web (chrome) sur le client j’ai divers erreur que je n’ai pas pensais a noté, et sur le web je me retrouve avec une erreur 504 a propos des bloc. j’ai fait les modif a propos de PHP mais j’ai toujours le probleme, j’ai voulu testé les modif a propos du nginx de nextcloud mais je ne comprend pas comment integre les ligne dans fichier de config nginx.conf

client_max_body_size 0; 
proxy_connect_timeout 1d;
proxy_send_timeout 1d;
proxy_read_timeout 1d;
send_timeout 1d;

c’est a mettre a la suite dans http

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    include /config/nginx/resolver.conf;
    server_tokens off;
    client_max_body_size 0;
    sendfile on;
    tcp_nopush on;

Bonjour,
Vous insérez

proxy_connect_timeout 1d;
proxy_send_timeout 1d;
proxy_read_timeout 1d;
send_timeout 1d;

après

client_max_body_size 0; 

ceci dit ça n’avait rien changé quand j’ai fait ces modifications.
J’ai constaté la résolution du problème en upload vers le serveur après la MAJ du client Nextcloud PC, par contre le download génère toujours une erreur 504. Je pense donc que c’est le client Nextcloud qui est en cause, mais nous n’avons pas la main dessus, espérons une prochaine MAJ qui résolve le download.

j’ai oublier de précisé que moi c’est vraiment quand j’UPLOAD sur le serveur NEXTCLOUD via le web ou le client que sa passe pas, j’ai pas testé dans l’autre sens

C’était aussi mon cas avant la MAJ du client Nextcloud il y a 3 jours, depuis il n’y a que le download qui me pose encore problème. Avez-vous effectué la MAJ du client Nexcloud PC ? Je n’utilise pas la webadmin qui est pour moi secondaire mais j’essaierai ce soir pour voir s’il y a un problème

je viens de vérifier je suis déjà dans la dernière version du client (windows)

mais faudrait déjà que j’arrive a faire fonctionné le web correctement avant de me penché sur le client.

Votre client Nextcloud est à jour, vous devriez décocher “Demander confirmation avant de synchroniser les dossiers de la taille supérieure à” et aussi la coche suivante si vous avez un stockage externe.
En ce qui me concerne l’utilisation de la webadmin génère une erreur 504 tout le temps. Le upload fonctionne vers le serveur, le download génère une erreur 504 par le client Nexcloud.

@duncan-valleix normalement la résolution devrait fonctionner dans votre cas pour l’upload.

@FelipeF pour le moment je n’ai pas trouver de moyen pour résoudre votre problème et j’ai peu de temps pour m’y pencher.

Peut être que ce post peut vous aider : Error when assembling chunks, status code 504 when using S3 · Issue #17992 · nextcloud/server · GitHub

https://docs.nextcloud.com/server/stable/admin_manual/installation/nginx.html?highlight=nginx#upload-of-files-greater-than-10-mib-fails

Comment avez vous installé nextcloud sur votre distribution ? (snapd, installation manuelle, script …)

Qu’avez vous comme valeur pour ce paramètre pour nginx ?
client_body_timeout

je suppose que vous n’avez pas modifié la taille des chunks créé par nextcloud pour le transfert ?

je te confirme que j’ai toujours l’erreur pour 1 fichier de 4,18Go, pour un transfere qui a pris environ 2h par contre
image
image

je viens de voir que la taille maximal est repassé a 2Go

J’ai bien conscience du temps que vous me consacrez et je vous en remercie bien sincèrement.

J’ai essayé d’ajouter

fastcgi_read_timeout 3600s;

ça résolvait le téléversement par la webadmin mais ça perturbait le fonctionnement du client Nextcloud, du coup je suis revenu en arrière et je l’ai supprimé.

A partir des applications proposées dans Yunohost

Je n’ai pas ce paramètre dans nginx

Non, je ne sais même pas comment modifier cette taille

après un autre essaie avec comme valeur 100Gb et 3h de max_execution_time toujours le même soucis

par contre dans le log (journalisation) j’ai ceci comme erreur, mais elle date de hier quand php était réglé a 2Gb

!!! j’ai un message du forum comme quoi je ne peux plus posté car je suis un nouveau membre !!!

@FelipeF peut être qu’en modifiant la taille on peut contourner le problème :
faites la commande suivant : occ config:app:set files max_chunk_size --value '10485760'
la valeur peut être modifié a l’aide de cette formule : 10 * 1024 * 1024
La valeur 10 correspond a une taille de fichier de 10 Mo.
pour désactiver cette fonction entrer simplement : occ config:app:set files max_chunk_size --value ''

@duncan-valleix les messages d’erreur correspondent a un transfert de fichier interrompu vers le serveur. Pour le transfert de gros fichiers, je vous conseille de modifier la taille des chunks, ça vous prendra un peu moins de temps. voir le message au dessus.
Utilisez vous php-fpm ?
En ce qui concerne votre serveur nextcloud, quel type d’installation utilisez vous ? (docker, snap, installation manuelle, …)
peut être que ce topic peut vous aider : Error when assembling chunks, status code 504

avez vous aussi essayer ces lignes avec la précédente ?

fastcgi_connect_timeout 60;
fastcgi_send_timeout 1800;

J’ai essayé, ça ne change rien, au contraire ça casse l’upload (de client vers serveur) de gros fichiers (2,2 Go) qui fonctionne. La suppression ensuite de ces lignes ne rétablit pas le bon fonctionnement de l’upload, heureusement j’avais sauvegardé ma VM avant et j’ai rétabli la sauvegarde pour retrouver un fonctionnement correct de l’upload. Par contre c’est le download de serveur vers client qui ne fonctionne toujours pas, ça bloque à 512Mo.

Je n’ai pas trouvé où insérer cette commande, dans nginx ? dans php.ini ?

@FelipeF cette commande est a effectuer dans un terminal avec l’utilisateur linux permettant le fonctionnement de nextcloud c’est une commande occ

Aujourd’hui j’ai eu une mise à jour de Nextcloud 25 à Nexcloud 26 à travers Yunohost
Après la mise à jour j’ai eu ce message dans la webadmin de Nextcloud


La documentation relative au problème détecté est ici : NGINX configuration — Nextcloud latest Administration Manual latest documentation
Voici mon nginx :

location ^~ /.well-known {

The following 6 rules are borrowed from .htaccess

The following 2 rules are only needed for the user_webfinger app.

Uncomment it if you’re planning to use this app.

#rewrite ^/.well-known/host-meta.json /nextcloud/public.php?service=host-meta-json last;
#rewrite ^/.well-known/host-meta /nextcloud/public.php?service=host-meta last;
location = /.well-known/carddav { return 301 /nextcloud/remote.php/dav/; }
location = /.well-known/caldav { return 301 /nextcloud/remote.php/dav/; }
location = /.well-known/webfinger { return 301 /nextcloud/index.php$uri; }
location = /.well-known/nodeinfo { return 301 /nextcloud/index.php$uri; }
try_files $uri $uri/ =404;
}
rewrite ^/nextcloud$ /nextcloud/ permanent;
location ^~ /nextcloud/ {

Path to source

alias /var/www/nextcloud/;

Add headers to serve security related headers

more_set_headers “Strict-Transport-Security: max-age=15768000; includeSubDomains; preload;”;
more_set_headers “Referrer-Policy: no-referrer”;
more_set_headers “X-Content-Type-Options: nosniff”;
more_set_headers “X-Download-Options: noopen”;
more_set_headers “X-Frame-Options: SAMEORIGIN”;
more_set_headers “X-Permitted-Cross-Domain-Policies: none”;
more_set_headers “X-Robots-Tag: noindex, nofollow”;
more_set_headers “X-XSS-Protection: 1; mode=block”;

Set max upload size

client_max_body_size 10G;
fastcgi_buffers 64 4K;

Enable gzip but do not remove ETag headers

gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json>

Pagespeed is not supported by Nextcloud, so if your server is built

with the ngx_pagespeed module, uncomment this line to disable it.

#pagespeed off;

Remove X-Powered-By, which is an information leak

fastcgi_hide_header X-Powered-By;

Specify how to handle directories – specifying /nextcloud/index.php$request_uri

here as the fallback means that Nginx always exhibits the desired behaviour

when a client requests a path that corresponds to a directory that exists

on the server. In particular, if that directory contains an index.php file,

that file is correctly served; if it doesn’t, then the request is passed to

the front-end controller. This consistent behaviour means that we don’t need

to specify custom rules for certain paths (e.g. images and other assets,

/updater, /ocm-provider, /ocs-provider), and thus

try_files $uri $uri/ /nextcloud/index.php$request_uri

always provides the desired behaviour.

index index.php index.html /nextcloud/index.php$request_uri;

Rule borrowed from .htaccess to handle Microsoft DAV clients

location = /nextcloud/ {
if ( $http_user_agent ~ ^DavClnt ) {
return 302 /nextcloud/remote.php/webdav/$is_args$args;
}
}
location = /nextcloud/robots.txt {
allow all;
log_not_found off;
access_log off;
}

Rules borrowed from .htaccess to hide certain paths from clients

location ~ ^/nextcloud/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/) { return 404; }
location ~ ^/nextcloud/(?:.|autotest|occ|issue|indie|db_|console) { return 404; }

Ensure this block, which passes PHP files to the PHP process, is above the blocks

which handle static assets (as seen below). If this block is not declared first,

then Nginx will encounter an infinite rewriting loop when it prepends

/nextcloud/index.php to the URI, resulting in a HTTP 500 error response.

location ~ .php(?:$|/) {
# Required for legacy support
# https://github.com/nextcloud/documentation/pull/2197#issuecomment-721432337
# This line fix the ldap admin page
rewrite ^/nextcloud/(?!index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|oc[ms]-provider/.> fastcgi_split_path_info ^(.+?.php)(/.*)$;
set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $request_filename;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
fastcgi_param modHeadersAvailable true; # Avoid sending the security headers twice
fastcgi_param front_controller_active true; # Enable pretty urls
fastcgi_param HTTP_ACCEPT_ENCODING “”; # Disable encoding of nextcloud response to inject ynh scripts
fastcgi_pass unix:/var/run/php/php8.1-fpm-nextcloud.sock;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
}
location ~ .(?:css|js|svg|gif)$ {
try_files $uri / /nextcloud/index.php$request_uri;
expires 6M; # Cache-Control policy borrowed from .htaccess
access_log off; # Optional: Don’t log access to assets
}
location ~ .woff2?$ {
try_files $uri / /nextcloud/index.php$request_uri;
expires 7d; # Cache-Control policy borrowed from .htaccess
access_log off; # Optional: Don’t log access to assets
}
location ~ / {
if ($request_method ~ ^(PUT|DELETE|PATCH)$) {
rewrite ^ /nextcloud/index.php$request_uri last;
}
try_files $uri / /nextcloud/index.php$request_uri;
}

show YunoHost panel access

include conf.d/yunohost_panel.conf.inc;
}

J’ai essayé de corriger Nginx en suivant les recommandations mais ça a planté ma VM, j’ai donc réinstallé la sauvegarde .

@Mageunic pouvez-vous m’aider ? (si vous en avez le temps bien entendu)

dans la doc cette ligne n’est pas exactement pareil …


rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

le ^/nextcloud/ n’est pas un problème mais la suite la fin de la ligne est différente … malheureusement je n’utilise pas nginx pour mon installation, je ne connais donc pas si c’est la bonne version de la ligne

essayer de faire la commande occ suivante dans un terminal en étant situé dans le dossier nextcloud: php occ maintenance:update:htaccess