Bonjour
non je ne parle pas du dossier racine mais du propriétaire des fichiers / dossiers
dans votre logiciel FTP chaque ligne de fichier ou de dossier affiche les droits xrw et le propriétaire
c’est ou le nom du compte ou www-data
Je n’arrive pas à faire une capture image,
et de plus dans les propriétés , j’ai voulu cocher la case des groupes et propriétaires dans le dossier public html.
maintenant dans l’accès privé,
j’ai ce message :
Forbidden
You don’t have permission to access this resource.Server unable to read htaccess file, denying access to be safe
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.
Je ne sais plus quoi faire ?
merci,
bien cordialement
Christophe
···
Le 29/10/2024 à 08:29, Natacha Courcelles via Discuter de SPIP a écrit :
Bonjour
non je ne parle pas du dossier racine mais du propriétaire des fichiers / dossiers
dans votre logiciel FTP chaque ligne de fichier ou de dossier affiche les droits xrw et le propriétaire
c’est ou le nom du compte ou www-data
Voir le sujet ou répondre à ce courriel pour répondre.
Pour vous désabonner de ces courriels, cliquez ici.
grosse bêtise …
vous avez changé les droits du dossier racine et c’est normal que ça ne fonctionne plus
rétablissez le dossier public html en 755
je peux difficilement tenter de vous aider sans accès FTP et à l’administration
Je me permets de vous transmettre un échange avec l’hébergeur Obambu.
Merci de vos solutions,
bien cordialement
Christophe
Bonjour,
Nous sommes parvenu à reproduire le problème avec une installation « fraiche » de SPIP, ce qui confirme que le problème n’est pas spécifique à votre installation de SPIP.
Cette installation a été réalisée manuellement en téléchargeant l’archive contenant SPIP depuis son site officiel, l’utilisation de Softaculous n’est donc pas en cause.
Néanmoins, le dossier pointé par SPIP comme n’étant « pas accessible en écriture » s’avère être « accessible en écriture » comme nous l’avons démontré précédemment à l’aide d’un script PHP conçu spécifiquement pour vérifier cela.
Il semble que SPIP échoue dans sa façon de déterminer le droit en écriture ou de réaliser l’écriture dans ce dossier, ce qui indique un problème de conception au niveau de SPIP.
Dans la mesure où le problème est spécifique à un script PHP spécifique (SPIP) et non à un dysfonctionnement du serveur, la résolution de ce problème sort du cadre de notre support.
Nous rappelons que nous fournissons un service d’hébergement Web, notre rôle consiste à héberger/exécuter les scripts tels qu’ils sont installés par le client (quelle que soit l’origine ou la méthode d’installation). Les dysfonctionnements occasionnés par ces scripts PHP sortent du cadre de notre responsabilité et ne donneront lieu à aucune compensation.
Si vous pensez que le problème est imputable au serveur, nous vous invitons à le montrer à l’aide d’un script PHP aussi court que possible et démuni de toute erreur de conception.
Notre équipe reste à votre écoute pour toute question.
Cordialement - Dylan
···
Le 29/10/2024 à 10:25, Natacha Courcelles via Discuter de SPIP a écrit :
grosse bêtise …
vous avez changé les droits du dossier racine et c’est normal que ça ne fonctionne plus
rétablissez le dossier public html en 755
je peux difficilement tenter de vous aider sans accès FTP et à l’administration
Voir le sujet ou répondre à ce courriel pour répondre.
Pour vous désabonner de ces courriels, cliquez ici.
Je vois que tu as cpanel, est ce que dedans tu peux désactive memcached ou non ? et avoir opcache par contre ?
Ensuite, ton hébergeur est un revendeur de 1&1 (Ionos désormais), il te dit qu’il a reproduit mais est ce que l’on peut savoir si il a tester sur le même serveur que toi ou bien sur un autre ?
Je vois que tu as cpanel, est ce que dedans tu peux désactive memcached ou non ? et avoir opcache par contre ?
Ensuite, ton hébergeur est un revendeur de 1&1 (Ionos désormais), il te dit qu’il a reproduit mais est ce que l’on peut savoir si il a tester sur le même serveur que toi ou bien sur un autre ?
Voir le sujet ou répondre à ce courriel pour répondre.
Pour vous désabonner de ces courriels, cliquez ici.
J’ai reçu la réponse de l’hébergeur; la solution n’est pas encore trouvée.
Sans réponse positive ,
je pense que je vais me tourner vers un autre hébergeur.
Bien cordialement,
Christophe
30/10/2024 (21:17) Dylan Agent de support
Équipe
Bonjour,
Memcache et OPcache ne sont pas installés sur le serveur. Ces modules ne sont pas vraiment liés à l’écriture des fichiers dans le système de fichiers, leur absence ou présence est fort probablement sans lien avec l’erreur rencontrée.
Les vérifications deux vérifications rappelées ci-dessous ont bien été effectuées directement sur votre hébergement et donc sur le même serveur :
Installation fraiche de SPIP : celle-ci a été supprimée afin de ne pas remplir votre hébergement avec des installations qui risquent d’être « oubliées »
Le script « testobambu.php » vérifiant l’écriture dans le dossier « skel » sur une des installations SPIP concernées. Ce script PHP est toujours présent.
Notre équipe reste à votre écoute pour toute question.
Cordialement - Dylan
···
Le 30/10/2024 à 13:21, Pierre KUHN via Discuter de SPIP a écrit :
Bonjour Christophe,
c’est curieux parce que j’ai mis un phpinfo sur le SPIP de test sur ton serveur et memcached (mais pas memcache qui est différent) y apparait bien
Voici également dans cette liste un peu trop de disable à mon avis. Mais je ne suis pas experte en serveur.
[EDIT 31 octobre] Bon ces logs ne sont pas suspects rien à voir, c’est bien la fonction qui renvoie ces logs, mais c’est un classique SPIP de find_in_path qui va chercher d’abord si un fichier du nom de la fonction existe. J’ai les mêmes à la maison
log SPIP qui peut mettre sur une autre piste
13 occurrences de fichiers non trouvés depuis la fonction find_in_path ecrire/inc/utils.php:L1651:find_in_path()::Pri:info:
include_spip plugins/ajouter_dependances.php non trouve
include_spip balise/formulaire_login.php non trouve
etc …
Il en manque, vu que j’ai extrait ces lignes du log
Ce qui est assez curieux, c’est que ces fichiers n’existent pas dans SPIP natif, ce sont des fonctions.
Par exemple echapper_html_suspect
Je me suis rendu sur le site o2switch la page d’accueil est accessible avec une interface vocale.
Mais avant de basculer sur un autre hébergeur, suite aux derniers messages de @Touti
je souhaiterais avoir une confirmation que le pb vient pas de Spip ou soit du serveur ?
bien cordialement
Christophe
···
Le 31/10/2024 à 09:46, Pierre KUHN via Discuter de SPIP a écrit :
Je n’arrive pas à voir dans les messages précédents si tu as bien utilisé spip_loader.php ou pas ? Si tu as utilisé le système d’installation automatique de l’hébergeur il est possible que ce soit celui-ci qui soit bugué puisque si j’ai bien suivi @touti a installé un SPIP sans souci avec spip_loader sur ton espace.
Alors comme il semble que ton installation ne soit pas OK je repartirai de zéro en installant de nouveau le site avec spip_loader.
Le site est complet, ces fichiers n’existent pas dans SPIP, la concaténation du log dans L1651:find_in_path() fait croire que ce sont des fichiers, mais ce sont des fonctions SPIP !
Plutot comme si find_in_path n’était pas correctement joué, mais non c’est pas ça non plus.
Aucun souci d’installation ou de déploiement de SPIP.
Je reproduis le même problème sur un site de test installé en sous domaine sur le serveur de Christophe.
Son problème n’existait pas il y a quelques semaines, Christophe ayant fait la MAJ SPIP4.3.3 avant que le problème arrive.
Donc Oui, c’est bien l’hébergeur, mais lui dit que c’est SPIP et ils ont reproduit sur leur système automatisé d’installation de SPIP, même souci, impossible de se connecter à l’espace privé et impossibilité d’écrire les fichiers de cache/skel.
Ça semble remarcher, l’accès à l’admin n’est plus bloqué et les fichiers sont bien enregistrés dans tmp/cache/skl.
Je ne pourrais pas dire le pourquoi du comment, j’ai seulement (après moultes essais et tentatives il va s’en dire) retiré # le commentaire L218 flock.php function ecrire_fichier qui était devant
Je vous remercie et plus particulièrement @Touti pour son aide à résoudre ce problème d’accès.
à 20h34 Je peux toujours accéder au Bac-Office.
Je suis très content de pouvoir enfin accéder au site web !
Merci encore,
Christophe
···
Le 31/10/2024 à 19:11, touti via Discuter de SPIP a écrit :
Ça semble remarcher, l’accès à l’admin n’est plus bloqué et les fichiers sont bien enregistrés dans tmp/cache/skl.
Je ne pourrais pas dire le pourquoi du comment, j’ai seulement (après moultes essais et tentatives il va s’en dire) retiré # le commentaire L218 flock.php function ecrire_fichier qui était devant
spip_timer('ecrire_fichier');
Christophe nous dira si cela perdure (ou pas).
Voir le sujet ou répondre à ce courriel pour répondre.
Pour vous désabonner de ces courriels, cliquez ici.