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

🌐 Non-english support đŸ‡«đŸ‡· Français (french)
91

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

92

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

93

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

94

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

image
image854×250 8.04 KB

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

image
image1680×125 8.96 KB

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

95

@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 ''

96

@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

97

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

fastcgi_connect_timeout 60;
fastcgi_send_timeout 1800;
98

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 ?

99

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

100

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

Avertissements Nextcloud
Avertissements Nextcloud1500×253 18.7 KB

La documentation relative au problÚme détecté est ici : https://docs.nextcloud.com/server/26/admin_manual/installation/nginx.html
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)

101

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

102

En fait il s’agissait d’un bug au niveau de Nextcloud 26.0.2 sur Yunohost, j’ai trouvĂ© comment le corriger.
Mais pour autant cette mise à jour ne rùgle pas le problùme des gros fichiers, il est toujours possible d’uploader du client vers le serveur mais pas de downloder du serveur vers le client.
Je vais essayer cette commande : occ config:app:set files max_chunk_size --value '10485760'

1 Like
103

J’ai testĂ© Ă  nouveau tout le fonctionnement de mon Nextcloud.
Pour les fichiers inférieurs à 512 Mo tout fonctionne parfaitement.
Pour les fichiers supérieurs à 512 Mo (2,2 Go dans mes essais) :

  • La synchronisation du client vers le serveur fonctionne le fichier apparaĂźt bien sur la Webadmin du serveur et sur le disque de stockage externe du serveur
  • Le renommage d’un fichier sur le client est bien mis Ă  jour sur la Webadmin de Nextcloud et sur le disque de stockage externe du serveur
  • La suppression d’un fichier sur le client est bien prise en compte sur la Webadmin MAIS pas sur le disque de stockage externe du serveur. Un nouveau forçage de la synchronisation entraĂźne le plantage du serveur.
  • La synchronisation d’un gros fichier du serveur vers le client bloque Ă  512Mo et entraĂźne une erreur 504, voire parfois le plantage complet du serveur.

Je pense donc que l’assemblage des blocs fonctionne en Upload mais qu’il y a un problùme dans Nextcloud pour la gestion du stockage externe et un autre problùme pour le download.

104

@FelipeF en ce qui concerne le disque de stockage pour vos donnĂ©es c’est une partition ou un accĂšs diffĂ©rent ? (ex: samba, ftp 
)

105

Le stockage est sur un disque diffĂ©rent de celui qui abrite la VM de Nextcloud. En fait j’ai 2 grappes en RAID 1, l’une contient la VM de Nextcloud, l’autre le stockage externe en SMB/CIFS.

106

@FelipeF le problÚme est déjà connu avec SMB 


il faut installer php8.1-smbclient

107

@duncan-valleix pouvez vous a nouveau discuter sur ce topic? si non essayez de m’envoyer un MP.
Utilisez vous aussi SMB sur votre installation ?

108

Merci pour cette info trĂšs importante qui est peut-ĂȘtre la cause de tous mes soucis. Comme mon Nextcloud est installĂ© comme une application de Yunohost je pense que l’installation de php8.1-smbclient doit passer par Yunohost, je vais essayer de creuser de ce cĂŽtĂ© lĂ  pour Ă©viter de tout casser.

109

j’ai mis en pause mon installe pour cause de la preparation du bapteme du petit, donc j’avoue que je n’ai pas poussais mais dans quelque jours je vais me remettre dessus et voir se qu’il en ai :smiley:

1 Like
110

Bonjour @Mageunic
Le problĂšme de SMB Ă©tait bien la cause de toutes les difficultĂ©s que j’ai rencontrĂ©es. J’ai donc installĂ© php8.1-smbclient en y allant doucement :

  • J’ai d’abord fait une simulation avec sudo apt-get -s install php8.1-smbclient qui s’est dĂ©roulĂ©e correctement en m’indiquant toutefois que j’avais des paquets inutiles sur ma VM
  • J’ai donc supprimĂ© ces paquets inutiles avec sudo apt autoremove
  • Je suis passĂ© Ă  l’installation dĂ©finitive sudo apt-get install php8.1-smbclient
  • J’ai redĂ©marrĂ© mon serveur

Depuis tout fonctionne correctement sur mon Nextcloud aussi bien en Upload qu’en Download. A noter que la derniĂšre mise Ă  jour de Nextcloud 26 a rĂ©initialisĂ© toutes les modifications que nous avions faites dans Nginx, je n’ai pas rĂ©introduit les modifications, par contre les modifications dans php.ini sont restĂ©es et je n’y ai pas touchĂ©.
Un immense merci pour tout le temps que vous m’avez consacrĂ©, votre derniĂšre trouvaille Ă©tait la bonne :grinning:

1 Like