J’ai eu un problème avec Nextcloud sur le NAS OMV, à savoir que les fichiers de plus de 1GB que je partageais échouaient systématiquement au téléchargement. 😳

Je me suis dit que la première chose à faire, c’était de mettre à jour Nextcloud à la dernière version (vieux réflexe de support). Comme je ne m’étais pas encore penché sur la façon de mettre à jour mes containers docker, c’était l’occasion. Je vais ainsi passer Nextcloud de la version 20.0.5 à la 20.0.12, puis à la 21.0.4.

Cela ne suffira pas à régler le problème d’origine, je me suis alors attaqué au problème de taille de fichiers partagés. Et je suis tombé sur deux limites à traiter : 1Go et 2Go. La première est due aux paramètres du proxy (swag), la seconde à l’architecture 32 bits de mon NAS.

Voyons voir tout cela…

Mise à jour du Container Plex

J’ai mis à jour récemment (27/12/22) le container Plex, et j’indique ici la méthode, même si je n’ai pas pris les screenshots au bon moment !) :

Dans l’onglet Image de Portainer, on télécharge la dernière version :

Une nouvelle image apparaît en bas dans la liste, avec une date récente. Elle est marquée « unused ».

On passe maintenant dans l’onglet Containers de Portainer, on arrête l’image plex actuelle, et on clique sur le nom du container. On renomme alors de « plex » à « plex.save » (cliquer sur le petit crayon) :

Puis on clique sur le bouton « Duplicate/Edit », et :

• On remet le nom « plex » d’origine.
• On désactive « Always pull the image ».
• On clique sur « Deploy the container ».

Et voilà ! le nouveau container est démarré, avec la dernière version de l’image ! Après avoir vérifié que tout fonctionne comme attendu, on peut supprimer l’ancien container (plex.save) et l’ancienne image.

Simple et efficace.

Mise à jour des images docker (à vérifier)

Tant que j’y suis, je vais mettre à jour toute la stack : nextcloud, mariadb, et swag.

Comme j’utilise une image Docker, je suis d’abord allé voir sur la page du container linuxserver/nextcloud ce qu’ils disaient à ce propos : Nextcloud fait partie des rares applications que l’on peut mettre à jour via l’interface graphique (tant mieux) à condition d’avoir vérifié que l’on utilise la dernière image docker disponible.

Pour ce faire, Docker sur OpenMediaVault est fourni avec Portainer comme interface de gestion des containers. Il faut donc aller sur la page Portainer, puis choisir « Images » dans la partie gauche, entrer le nom de votre image docker, puis cliquer sur « Pull the image ». Voilà l’exemple pour linuxserver/swag :

Et on fait la même chose pour linuxserver/nextcloud et linuxserver/mariadb. Une fois ceci fait, on observe en bas de la fenêtre que les images <latest> sont bien les dernières téléchargées, et que mes anciennes images (datant de janvier dernier) sont tagguées en <none>.

Elles sont encore marquées « Unused », c’est normal. Il va falloir maintenant redémarrer les containers. Comme je les avais installés en créant une « Stack » (on installe les 3 containers d’un coup, et cela permet d’indiquer la dépendance de Nextcloud vis-à-vis de mariadb), il faut cliquer sur « Stack » dans la partie gauche de la fenêtre, cliquer sur « nextcloud » (le nom de ma stack), puis sur « Stop this stack » :

Il suffit alors de redémarrer la Stack, et les versions <latest> que l’on vient de télécharger vont être automatiquement utilisées. On se retrouve donc avec les anciennes versions marquées « Unused » :

Il est recommandé par la suite de les effacer, cela prend de la place sur le disque pour rien. Mais attendez tout de même de vérifier que les nouvelles fonctionnent correctement ! 😉

Voilà, j’ai récupéré et mis en service les dernières versions des images docker fournies par Linuxserver pour swag, nextcloud et mariadb. Concernant Nextcloud, je peux donc passer à la mise à jour via l’interface graphique.

Mise à jour de Nextcloud

C’est très simple, il suffit d’aller sur la page d’administration (https://your.nextcloud.fr/settings/admin/overview), puis de suivre les instructions. Là, on me propose de passer de la v20.0.5 à la 20.0.12, soit une upgrade mineure. Bon, pourquoi pas ? Après toute une série de vérifications, de téléchargement de la nouvelle version, etc… l’assistant vous propose de continuer avec le « web based updater » :

On valide, et l’on retrouve les habituelles instructions de sauvegarde avant de lancer pour de bon la mise à jour de Nextcloud :

Une fois cette « mini » mise à jour terminée, je retourne sur la page d’administration, et là je vois qu’une nouvelle mise à jour m’est proposée : celle vers la v21.0.4 ! Cette fois, c’est beaucoup plus intéressant, je vais passer de la v20 à la v21 :

La mise à jour s’effectue sans souci particulier, et après quelques minutes, j’ai ma nouvelle version Nextcloud qui tourne et est opérationnelle.

Sauf qu’après un test rapide, mon problème de téléchargement de gros fichiers est toujours présent. Il va falloir investiguer pour de bon !

Le problème de téléchargement

Le problème était donc le suivant : je créais sous Nextcloud un lien public pour partager un fichier avec des amis, et lorsque le fichier faisait plus de 1Go, le téléchargement échouait systématiquement. En investiguant, je suis donc tombé sur deux limites : 1Go et 2Go.

Limite 2Go

Je commence par regarder les logs Nextcloud, et je vois ce genre de message :

Si j’en crois ce message, le problème se situe quand le fichier dépasse 2Go… Quelques recherches sur le net m’apportent vite la réponse : mon serveur (un odroidhc2) a un processeur armv7l, soit une architecture 32 bits :

pascal@odroidhc2:~$ sudo lshw
odroidhc2                   
    description: ARMv7 Processor rev 3 (v7l)
    product: Hardkernel Odroid XU4
    width: 32 bits
    capabilities: smp

Or la version PHP utilisée par Nextcloud ne gère pas les fichiers de cette taille ! On trouve d’ailleurs cette information dans la doc :

Cette histoire de 32 bits ne m’avait pas tracassé à l’achat, mais là, je me rends compte qu’il est préférable d’avoir une architecture x64 de nos jours ! 🙁 Le pire, c’est que cela pourrait être facilement corrigé, il y a longtemps que cette limite a été dépassée au niveau OS, mais il semble que les efforts de développement de Nextcloud préfèrent se porter ailleurs, et donc ce problème ne sera à priori pas corrigé.

Bon, je retiens qu’il vaut mieux éviter le 32 bits désormais, ça commence à être un peu trop vieux !

Ceci dit, cela ne m’affecte que si j’utilise l’upload par la page web, ou par l’adresse WebDav, lorsque je veux copier mon fichier dans Nextcloud. J’ai alors copié le fichier en ligne de commande sur la machine pour contourner le problème. J’ai créé un dossier « Public » dans Nextcloud, et dans mon cas le répertoire physique est /srv/dev-disk-by-label-DATA/AppData/Nextcloud/data/pascal/files/Public.

Saut qu’en copiant le fichier de cette manière, Nextcloud ne l’indexe pas, et il n’apparaît donc pas dans l’interface, pas moyen donc de le partager ! Là encore, il y a une solution : Via Portainer, on se connecte en mode console, et on lance l’indexation avec la commande suivante : occ files:scan pascal (pascal étant le nom de l’utilisateur nextcloud) :

L’opération est plutôt longue, plus de 20 minutes dans mon cas… Mais une fois terminée, on voit apparaître notre fichier de plus de 2Go dans le dossier Nextcloud, et l’on peut enfin créer le lien de partage :

En procédant de cette manière, on contourne la limitation de 2Go qui en fait ne concerne que la phase « d’upload » du fichier vers Nextcloud. La phase « Download » fonctionnera très bien, quand il s’agira de « récupérer » le fichier.

Limite de 1Go

Mais avant que cela fonctionne, il reste une autre limite à régler, car les téléchargements échouent à 1Go, et cette fois sans aucun message d’erreur.

Mon premier souci a été de reproduire le problème : en effet, sur mon réseau local, le téléchargement s’effectuait sans souci. Comme j’ai un abonnement VPN, j’ai activé celui-ci sur le PC, et cette fois j’ai pu reproduire l’erreur :

En surveillant de près la progression, c’était bien dès que le téléchargement en cours atteignait la taille de 1 Go que ce dernier s’arrêtait et s’affichait en « Échec » dans Firefox. Mais je n’avais aucun log, aucune autre information (enfin je n’ai rien trouvé en tout cas).

Tout de même, comme cela fonctionnait sur le réseau local, je pouvais orienter mes recherches du côté du serveur proxy, à savoir le container swag.

Un petit essai avec wget en ligne de commande me confirmait le problème : pour ce faire, il faut d’abord récupérer le lien direct dans Nextcloud en affichant la page du lien partagé, puis cliquer sur les trois petits points :

Puis dans un terminal, utiliser wget avec l’option –no-check-certificate suivi du lien direct fourni par Nextcloud :

wget --no-check-certificate https://Lien.direct.de.Netxcloud

En procédant de la sorte, j’ai pu voir que wget affichait « connection closed », puis « retrying », et arrivait ensuite à finir le téléchargement en reprenant le téléchargement à l’endroit où il s’était arrêté (désolé, je n’ai pas fait de capture d’écran). Mais cela renforçait la piste du proxy et le problème de la connexion https qui est fermée, sans doute pour un problème de taille…

Après moultes recherches sur le net, je suis tombé sur cette page, très intéressante, et qui fournit beaucoup d’infos sur les problèmes de performance liés à Nextcloud. Concernant les téléchargements qui échouent à 1GB, ils indiquent 4 paramètres à ajouter au « ssl server block in your Nginx configuration for Nextcloud » :

proxy_buffering off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
fastcgi_max_temp_file_size 0;

Restait à trouver le fichier correspondant pour swag ! Rappel : lors de l’installation du container, j’ai défini le volume suivant :

/srv/dev-disk-by-label-DATA/AppData/swag:/config

Le fichier que je cherche est finalement :

/srv/dev-disk-by-label-DATA/AppData/swag/nginx/ssl.conf

Les deux premiers paramètres sont déjà présents, je n’ai donc ajouté que les deux derniers. Et d’après la page, c’est fastcgi_max_temp_file_size qui par défaut limite la taille des fichiers à 1GB. En le mettant à 0, on supprime la limite.

Voilà, je redémarre le proxy, et je relance le download, et cette fois le téléchargement s’effectue jusqu’au bout sans souci :

Je teste avec un fichier de plus de 2 Go, cela fonctionne également !

Conclusion

Toute cette affaire m’a appris à mettre à jour mes containers, et c’est plutôt facile. Bonne nouvelle, je suis pour l’instant très satisfait de l’utilisation de Docker.

Cette limite de 1 Go par défaut pour la taille de fichiers est surprenante, je me demande bien pourquoi le paramètre n’est pas ajusté en conséquence ? Par contre, ce n’est pas un problème Nextcloud, mais du Proxy que l’on utilise… Ici, c’est Swag, un container fournissant un web serveur nginx avec php7, fail2ban (pour les intrusions), et Let’s Encrypt (pour les certificats) : plutôt pratique quand même ! 😉

Enfin, l’architecture 32 bits, qui commence à être abandonnée par les éditeurs (Ubuntu par exemple), est à éviter de nos jours. Ici, c’est un bug connu qui ne sera pas corrigé. Si j’avais su, j’en aurai tenu compte lors de l’achat de mon NAS, mais je retiens la leçon.