Bonsoir,
Je suis un peu dépité !
J’ai mis en route un Nextcloud et il est très instable. Erreurs diverses et variées à la pelle.
Très très courante : déconnexion intempestives (bandeau « erreur, raffraichissement dans 5, 4, 2… »)
Mais aussi :
Souvent des erreurs quand je veux supprimer un répertoire (vide je précise)
des affichages « Erreur inconnue, impossible de … (variable selon les fois) »
J’ai des fichiers de nextcloud.log de plusieurs mega en quelques jours
BREF ! Je voulais savoir si c’était le cas des autres utilisateurs ou bien si mon install est foireuse.
Pour info, voici la liste des erreurs de config relevées par Nexcloud/Paramètres/Vue d’ensemble
Merci pour votre aide
jean-françois
Il y a quelques erreurs concernant votre configuration.
Des fichiers n’ont pas passé la vérification d’intégrité. Vous trouverez plus d’information sur comment résoudre ce problème dans notre documentation. ([Liste des fichiers invalides…]) / Rescanner…
La fonction PHP « set_time_limit » n’est pas disponible. Cela pourrait entraîner l’arrêt des scripts à mi-exécution en bloquant votre installation. Nous vous recommandons vivement d’activer cette fonction.
La limite de mémoire PHP est inférieure à la valeur recommandée de 512 Mo.
MySQL est utilisée comme base de données mais ne supporte pas les caractères codés sur 4 octets. Pour pouvoir manipuler les caractères sur 4 octets (comme les émoticônes) sans problème dans les noms de fichiers ou les commentaires par exemple, il est recommandé d’activer le support 4 octets dans MySQL. Pour plus de détails, lisez la page de documentation à ce sujet
L’en-tête HTTP « Strict-Transport-Security » n’est pas configurée à au moins « 15552000 » secondes. Pour renforcer la sécurité, nous recommandons d’activer HSTS comme décrit dans nos conseils de sécurisation .
La configuration du serveur web ne permet pas d’atteindre « /.well-known/caldav ». Vous trouverez plus d’informations dans la documentation.
La configuration du serveur web ne permet pas d’atteindre « /.well-known/carddav ». Vous trouverez plus d’informations dans la documentation.
Aucun cache mémoire n’est configuré. Si possible, configurez un « memcache » pour améliorer les performances. Pour plus d’informations consultez la documentation.
Oui c’est malheureusement un problème connu avec les Nextcloud hébergés sur la plateforme, particulièrement ce problème de déconnexions intempestives, qui est très fréquent quand la plateforme est chargée.
La panne de la semaine dernière et l’absence de notre propre serveur de fichiers en ce moment ne doit pas arranger les choses.
Concernant les avertissements, vous pouvez les ignorer sauf :
Des fichiers n’ont pas passé la vérification d’intégrité…, ou vous devez afficher la liste des fichiers invalides et les traiter
L’en-tête HTTP « Strict-Transport-Security » n’est pas configurée à au moins…, ou vous pouvez ajouter l’en-tête via une ligne dans le fichier .htaccess.
Un ticket a été ouvert le 30 septembre dernier sur Github :
Apparemment, il s’agit d’un vieux bug ayant fait l’objet d’autres tickets par le passé. Et jamais corrigé. Il semble donc nécessaire de « se débrouiller » avec !
L’auteur du ticket propose un moyen de le contourner.
Workaround
The only method that seems to work is to switch the php.ini configuration back to using session.save_handler=files and session.save_path="/tmp" (which of course is not optimal given a server may be serving other apps that can tremendously benefit by memcached or redis session storage).
Je viens de passer de nombreuses heures à mettre en place un Nextcloud pour un client… et je ne me vois pas le lui livrer en lui disant « Ca déconnecte souvent, mais j’y peux rien » !
Deux questions :
Est-il envisageable de mettre le workaround proposé ci-dessus en place sur le serveur Ouvaton ?
Est-ce que OwnCloud est plus stable (ça m’arrange pas mais s’il le faut je recommencerai le boulot sur OwnCloud !)
Dommage ! Donc pas de solution en vue
Autant pour un usage privé je pourrais faire avec, autant pour une utilisation pro ça va pas être possible.
C’est vraiment dommage : la possibilité d’utiliser un NextCloud était ce que qui m’avait décidé à migrer mes sites vers Ouvaton
Je vais ouvrir un fil pour voir si Owncloud est plus stable sur Ouvaton. Ca m’obligerait à recommencer tout le boulot de mise en place mais au moins si ça marche…
Jean-François
Merci pour ces infos. Malheureusement l’utilisation de l’appli n’est pas possible dans mon cas.
Je voulais essayer OwnCloud pour voir si c’était plus stable. Mais sauf erreur de ma part ce n’est plus possible (ce n’est pas proposé sur l’onglet « Web » de Ouvadmin dans les installations possible) contrairement à ce que j’avais lu sur la page d’info des outils disponibles sur ouvaton.coop (https://ouvaton.coop/la-cooperative/outils-en-partage/)
J’ai donc poussé les recherches et trouvé une page très intéressante qui traite de ce problème. En fin de page le problème semble bien identifié et plusieurs solutions sont proposées.
Je ne sais pas à quel point l’infogérant s’est penché sur ce problème. Est-ce qu’il a étudié cette page ? A-t-il testé les solutions proposées ? Merci de m’en informer pour que je comprenne la situation et vois ce que je peux (ou pas) faire pour aider.
L’installation de owncloud est possible, mais doit se faire manuellement: ce n’est pas dans les logiciels proposés à l’installation automatique, mais c’est tout à fait possible de l’installer en téléchargeant les fichiers (là: https://owncloud.com/download-server/), les dézippant, et en les mettant dans le dossier httpdocs de votre espace, via ftp.
Je pensais qu’une installation « automatique » était possible. « Manuellement » je le sens moins Ou plutôt je sens bien les longues heures de boulot pour réussir à le faire tourner
Et plutôt que passer ces heures sur MON petit cloud à moi, je préférerais les passer pour trouver une solution qui profite aux dizaines de NextCloud installés sur Ouvaton.
D’où mes questions : à quel point la solution de ce bug a déjà été recherchée ? dans quelle mesure je peux aider ?
Bonsoir Philippe,
J’ai exactement les mêmes problèmes que JFCavalier, après avoir réinstallé plusieurs fois et même changé de version de PHP pour voir.
Cependant, ce n’est pas durant l’activité du script d’installation apparemment ; du moins, celui-ci doit, selon moi, effectuer une vérification à la fin de son installation, et il ne me dit rien.
J’ai bien peur que ce soit durant l’exécution des scripts qu’ils plantent de façon erratique mais très fréquente.
Je m’en vais quand même tout effacer à nouveau pour la nième fois (ce qui en FTP de chez moi prend 15mn) et tenter d’uploader tous les fichiers un à un, à l’ancienne (ce qui va prendre la nuit…)
Contrairement à JFCavalier, cela fait des années que j’utilise NextCloud sur une instance Ouvaton (et OwnCloud auparavant), et tout marchait très bien jusqu’à ce qu’une mise à jour de NC impose un PHP plus récent, ou l’inverse : toujours est-il que ça plante depuis ce moment-là.
Quelque part j’ai l’impression que c’est aussi cette escalade, entre PHP plus exigeant et NC encore plus exigeant aussi, qui surcharge Ouvaton. Par exemple, dans les brèves rémissions avant plantage où j’arrive à regarder les paramètres de NC, je vois des warnings du genre « PHP n’obtient pas la mémoire recommandée de 512Mo », ce qui me semble quand même démentiel…
[edit] Je suis en train de télécharger l’archive NC. 136Mo quand même pour le zip. ça va donner, lorsque je devrai ré-uploader tout ça chez Ouvaton en version dézippée…
[edit 2] il n’y a aucune différence entre télécharger durant des heures les fichiers un par un ou lancer le « setup-nextcloud », qui est cent fois plus rapide.
Bonjour,
J’ai également eu cette erreur là, mais c’est arrivée seulement quelques fois, alors que l’erreur de déconnexion intempestive arrive
- environ 3 fois sur 4
- toujours quelques secondes après la connexion
- je dois me relogger la plupart du temps 1 ou 2 fois et après c’est ok pour toute la session
- il arrive parfois que je doive me relogger une dizaine de fois avant que ça « tienne ».
- dans presque 100% des cas, une fois que ça a « tenu » une dizaine de secondes, ça tient toute la session.
Je me demande si tout le monde subit ces problèmes ou si nous sommes quelques uns seulement. Parce que dans le second cas, en voyant ce qui est différent, on pourrait trouver la source du bug…
Jean-François
Je reviens sur cet étrange problème pour dire que ma piste précédente (caractère + dans le token) n’était pas viable.
C’est bel est bien une session qui se perd (les cookies de sessions changent d’id à un moment) dans les appels faits initialement … et de manière assez aléatoire.
Il y a pas mal de choses faites à ce moment là j’ai l’impression (comme par exemple la mise en cache de feuilles de styles CSS générées depuis du Sass) et je me demande si ce n’est pas une erreur silencieuse quelque part qui génère cette déconnexion.
J’ai tenté de relocaliser le path des sessions dans un dossier auquel je peux accéder en FTP et il y a un grand nombre de sessions créées alors que je suis seul à me connecter.
… j’abandonne pour ce soir, suite au prochain épisode. En mettant en commun nos analyses j’espère que nous y parviendrons !
PS : j’ai une instance de Nextcloud sur un tout autre serveur, avec la même version et n’ai jamais rencontré ce soucis.
Pierre quelle est la version de ton instance Nextcloud qui fonctionne?
Ici j’ai pratiquement les mêmes problèmes sur la version 20, la 16 et la 15 (qui m’impose de régresser ma version de PHP)
Si quelqu’un veut tenter la 14 ou la 17…
Sinon je signale que si l’on veut installer une version inférieure à 20, au lieu de passer la moitié de la nuit (pour nous autres pas sur la fibre) à uploader du FTP, il y a un moyen simple qui est d’éditer le petit fichier « setup-nextcloud.php » (qu’il suffit d’uploader et de pointer pour cette version 20, et il charge tout seul les fichiers à votre place).
Une seule ligne est à changer : define(‹ NC_VERSION ›, ‹ latest ›);
que vous remplacez, par exemple pour la version 16, par define(‹ NC_VERSION ›, ‹ latest-16 ›);
Après vous faites comme avant : upload de ce petit script, on pointe dessus, et il va télécharger tout seul la version qu’on a dit…
[edit] les versions 14 (en PHP7.3) et 18 plantent aussi. Perso j’arrête, mais je suivrai ce fil.
La piste que tu suis me fait penser à une des deux pistes les plus sérieuses listées sur la page Githug que j’ai donné en référence plus haut :
I just came along this problem myself and solved it for my DomainFactoy webspace by making a tmp directory in my webspace and adapting the session.save_path in my php.ini like this: session.save_path = /kunden/accountNumber/tmp
Comment as-tu pu modifier le path des sessions sans toucher au php.ini ?!
Ca m’intéresse vu qu’il est clair que le bug tourne autour de la gestion des sessions.
Merci Jean-François!
Il y a quand même une chose, c’est qu’il y a quelques mois tout marchait bien quand même sur Ouvaton…
(Maintenant, les versions de Nextcloud se suivent à une vitesse tellement frénétique… Cela dit la 12 sur le serveur de NC semble dater de 2018…)
Bilan : ça marche pas mieux ! Mais par contre effectivement on peut rapatrier les sessions, ce qui est un bon début.
J’ai constaté quelque chose de peut-être intéressant : lorsque ça bugge, le fichier de sessions fait 420 octets, alors que quand ça bugge pas (pas d’erreur « Rechargement dans … » après s’être loggé), le fichier de session fait 1028 octets (systématiquement).
Il est possible que quelque chose tourne mal au moment de la création du fichier de session.
Mais c’est à prendre avec des pincettes : après, durant l’utilisation de NextCloud, la taille du fichier de session augmente. Donc aussi bien, c’est juste que comme ça bugge, certaines infos n’y sont pas inscrites, mais que leur absence n’est pas la source du bug.
.
Ou plutôt je sens bien les longues heures de boulot pour réussir à le faire tourner 