Erreur durant mise à jour YesWiki sur PC en local

Bonjour,
je rencontre un problème de mise à jour de YesWiki en local sur une distrib LinuxMint 22.2 Zara.
Php en version 8.3.6
MySQL en version 8.0.46

La mise à jour bloque sur l’étape : « vérification des droits sur les fichiers » > « erreur ».

Les droits d’accès au répertoire sont :

/var/www/doryphore$ ls -l
total 500
drwxr-xr-x 2 www-data root 4096 janv. 26 23:29 actions
drwxr-xr-x 4 www-data root 4096 juil. 8 14:47 cache

-rwxr-xr-x 1 www-data root 367 janv. 21 18:47 index.php

drwxr-xr-x 3 www-data root 4096 janv. 26 23:29 private

Je ne vois pas ce qui bloque pour la mise à jour.
Avez-vous une idée ?

l’ensemble du dossier /var/www/doryphore est en 755 et user www-data et groupe root?

sudo chmod 755 /var/www/doryphore -R
sudo chown www-data:root  /var/www/doryphore -R

L’ensemble des dossiers est configuré comme tu l’indiques @mrflosperso .

Si backup est configuré avec les droits en 755 avec root:root, la mise à jour bloque sur « Vérification des droits sur les fichiers » (cf. message initial).

Si backup est configuré avec les droits en 755 avec www-data : root, je ne peux pas lancer la mise à jour :

Autre idée de ce qui peut être bloquant ?

Pour bloquer le deuxième message, faut aller dans le fichier de conf et ya un paramètre « etat du wiki » qui doit être bloqué sur « archiving », faut remettre vide.
Si cela ne marche pas mieux, essayer peut etre les droits en www-data:www-data.
Sinon dans l’onglet fichier de conf on doit pouvoir mettre a false le fait de faire un backup avec mise a jour, en local tu peux facilement copier le dossier ailleurs pour faire le backup manuel.

L’état du wiki est sur la valeur par défaut : running (ou vide) dans le fichier de conf.

J’ai pu résoudre le problème avec la mise à jour bloquée « Action désactivée car ce wiki est en lecture seule… » de deux manières :

  • Passer private et backups avec les droits en chmod 775 -R
  • Désactiver la sauvegarde avant la mise à jour.

Si je n’active pas la sauvegarde avant la mise à jour, la mise à jour bloque toujours sur « Vérification des droits sur les fichiers > Erreur », après avoir téléchargé et extrait l’archive.
De quelle archive il s’agit ? Est-ce celle de la mise à jour ?
Si c’est celle de la mise à jour, dans quel répertoire est-elle extraite ?

Qu’est-ce qui bloque à ce niveau ?

La vérification des droits, c’est sur les fichiers locaux pas l’archive téléchargée.

Le dossier de récupération de l’archive c’est un dossier temporaire dans cache cf. https://github.com/YesWiki/yeswiki/blob/doryphore-dev/tools/autoupdate/entities/Files.php#L91
Il va chercher l’archive sur https://repository.yeswiki.net

Ca va être un peu long s’il faut qu’on discute l’ensemble du processus de mise à jour de YesWiki, donc pour trouver une solution, ma question c’est de quelle version de YesWiki tu pars pour faire la maj ? Si elle est un peu vieille, ya peut être un bug de cette version qui empêche les mises à jour locales. Dans ce cas peut être juste télécharger la dernière version de YesWiki depuis le zip dans le repository, et procéder a une mise a jour manuelle?
Si tu veux comprendre pourquoi il y a des soucis de droits en local, faudrait tenter avec un chmod 777 généralisé pour juste vérifier si c’est effectivement un soucis de droits d’accès en local ou un soucis dans le code, et si c’est un soucis dans le code, rechercher « Vérification des droits sur les fichiers » et remonter à l’endroit du code qui gère cela et faire afficher les fichiers qu’il teste au moment de l’erreur et tenter de comprendre ce qu’il se passe.

Je partais d’une version 4.5.5.

Edit : Le chmod 777 permet la mise à jour.
Edit : Le chmod 775 ou 755 ne permet pas la mise à jour => cela bloque toujours à « Vérification des droits sur les fichiers » Edit : si certains répertoires ne sont pas affectés aux bons propriétaires (www-data vs root).
Edit : un peu perdu, dans les chown et les chmod, et après plusieurs plantages, j’ai refait la manip proprement en repartant d’une copie du répertoire initial et en reparamétrant avec chmod 755 -R et chown www-data -R, ca a fini par fonctionner. :sweat_smile: :upside_down_face:
A un moment j’ai dû faire une manip partielle sur chown www-data, notamment en oubliant le répertoire chapeau. Désolé pour le dérangement.

1 « J'aime »