php - rectification - Comment puis-je corriger l'erreur d'autorisation lorsque j'appelle session_start()?




modifier declaration impot 2018 (10)

quand j'ai téléchargé le script sur le serveur, j'ai cette erreur

Avertissement: Inconnu: ouvert (/ tmp / sess_58f54ee6a828f04116c2ed97664497b2, O_RDWR) a échoué: autorisation refusée (13) dans Unknown sur la ligne 0

Avertissement: Inconnu: Impossible d'écrire les données de session (fichiers). Vérifiez que le paramètre actuel de session.save_path est correct (/ tmp) dans Unknown sur la ligne 0

l'erreur est apparue quand j'appelle session_start(); bien que je mette la permission du dossier / tmp à 777.


Ajouter la ligne suivante

ini_set('session.save_path', getcwd() . '/tmp');

avant

session_start(); 

Au départ, ce problème était dû au fait que nginx possédait l’emplacement / tmp et que php-fpm fonctionnait sous le nom d’utilisateur et de groupe «apache» à cause de www.conf. J'ai remplacé l'utilisateur / le groupe dans ce fichier et cela a fonctionné correctement. Vous voudrez peut-être vérifier <?php echo exec('whoami'); ?> <?php echo exec('whoami'); ?> à vérifier.


En utilisant PHP 5.6, j'avais déjà utilisé session_save_path () pour désigner un répertoire dans la structure du domaine. Cela a bien fonctionné jusqu'à ce que je passe à PHP 7.0, date à laquelle j'ai reçu l'erreur notée. Sur PHP.net j'ai trouvé plusieurs commentaires indiquant que l'attribution d'un chemin direct ne fonctionnait pas toujours, alors j'ai utilisé leur suggestion.

session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../session'));

travaillé parfaitement. N'oubliez pas de changer /../session à l'emplacement relatif de votre répertoire de session actuel.


J'ai eu ce problème dans la situation suivante:

  1. J'ai rempli des sessions avec PHP
  2. Alors que la session était encore active, je suis passé de PHP 5.4 à 5.3 sur mon hôte.
  3. Le rechargement de la page a généré l'erreur décrite ci-dessus.
  4. Réinitialisez la version de PHP à 5.4.
  5. Utilisé session_unset (); et session_destroy (); pour nettoyer la session en cours.
  6. Changement de la version de PHP en 5.3.
  7. Maintenant cela fonctionne à nouveau.

Conclusion: Pour une raison non pertinente, je devais changer de version de PHP et en changeant de session avec les sessions, celles-ci sont corrompues.


J'ai le même problème de permission, mais sur / var / lib / php / session /.

Pour y remédier, je supprime le fichier et redémarre php-fpm.

rm -rf /var/lib/php/session/sess_p930fh0ejjkeeiaes3l4395q96
sudo service php5.6-fpm restart

Maintenant tout fonctionne bien.


Je me rends compte que c'est un ancien message, mais je me suis juste heurté à ce problème et j'ai trouvé une solution facile.

Pour moi, le problème se produisait avec l'un de mes sites Web déployés localement. Je n'avais pas essayé d'accéder aux sites Web avec d'autres navigateurs, mais cela se produisait chaque fois que j'essayais d'accéder à ce site via Chrome. J'ai décidé d'aller dans les outils de développement Chrome, sous l'onglet Application - et en cliquant sur "Effacer le stockage". Voila - tout fonctionne à nouveau comme par magie.

J'espère que ceci aide quelqu'un d'autre!


Pour moi, le problème semble être un bogue WHM! J'ai un tas de domaines add on et tout fonctionne bien, mais avec un sous-domaine, cela apporte cette erreur.

Chose étrange, mais si j'utilise l'URL complète avec le domaine principal, cela fonctionne bien:

main-domain.com/my.subdomain.com

Si j'utilise directement le sous-domaine, il apporte "Autorisation refusée (13)":

my.subdomain.com

La chose est que tous les domaines addon root est:

/ home / xx /

Mais pour mon sous-domaine, ne sais pas pourquoi, la racine est: (je ne devrais pas avoir accès à ce répertoire)

/

Donc, c'est vraiment essayer d'atteindre: / tmp au lieu de / home / xx / tmp

Qui existe également mais ne dispose pas des autorisations appropriées

Pour clarifier ceci sont des exemples de tout le chemin:

/ home / mon-compte / public_html

/ home / mon-compte / tmp

/ tmp

La solution de contournement que j'ai utilisée était:

session_save_path ('/ home / my-account / tmp');

session_start ();


Si :

  • session.gc_probability> 0
  • Les fichiers de session sont créés par différents utilisateurs (par exemple, root et apache).
  • les fichiers de session sont tous stockés au même endroit (par exemple / var / lib / php / session)

Ensuite, vous verrez cette erreur lorsque, par exemple, le processus PHP Apache tente d'exécuter la récupération de place sur les fichiers de session.

Corrections:

  1. Reconfigurez PHP pour que gc_probability soit égal à 0 et que vous ayez un job cron supprimant le (s) fichier (s) ancien (s).
  2. Demandez à chaque utilisateur d'enregistrer ses fichiers de session à un endroit différent (session_save_path (), etc.).

Si vous utilisez le serveur Web Apache , la solution rapide consiste à accéder à votre ligne de commande et à saisir:

open /etc/apache2/

puis à partir de la fenêtre ouverte, ouvrez le fichier appelé httpd.conf et recherchez User ou Group changez ces 2 lignes pour:

User  _www
Group _www

Cela est dû au fait que vous souhaitez que votre serveur dispose des droits d’autorisation sur vos répertoires de systèmes, en particulier si vous souhaitez modifier l’ User ou si vous pouvez laisser votre Group au staff ou à l’ admin .


Vérifiez que vous ne rencontrez pas de problèmes d’espace disque. Si toutes les permissions sont correctes (et 777 devrait le faire pour vous), alors vous pourriez toujours avoir cette erreur (pour certaines versions de PHP et Apache) s'il n'y a pas assez d'espace pour écrire sur le disque.







warnings