Comment puis-je fixer la Permission d'erreur lorsque j'appelle la fonction session_start()?

lorsque j'ai téléchargé le script sur le serveur j'ai eu cette erreur

Warning: Unknown:
open(/tmp/sess_58f54ee6a828f04116c2ed97664497b2,
O_RDWR) failed: Permission denied (13)
in Unknown on line 0

Warning: Unknown: Impossible d'écrire
session de données (fichiers). Veuillez vérifier
que le réglage actuel de
session.save_path est correcte (/tmp) en
Unknown on line 0

l'apparition de l'erreur quand je l'appelle session_start();
bien que j'ai défini la permission de dossier /tmp en 777 .

InformationsquelleAutor Waseem Abu Senjer | 2011-01-03
  1. 25

    Changer de session chemin d'accès où vous pouvez écrire des données ou contactez l'administrateur du serveur sur /tmp problème

    http://php.net/manual/en/function.session-save-path.php

    InformationsquelleAutor Tadas Šubonis
  2. 9

    vous aurez besoin de changer votre session.save_path php.directive ini

    Vous pouvez le faire en utilisant session_save_path

    InformationsquelleAutor German Rumm
  3. 6

    Si vous avez un accès SSH, voici comment corriger l'autorisation et la propriété

    sudo chown -R NAME_OF_USER /tmp

    Remplacer NAME_OF_USER par l'utilisateur sous lequel s'exécute le php. Vous pouvez trouver: il suffit de mettre ces lignes dans un fichier php:

    $processUser = posix_getpwuid(posix_geteuid());
print $processUser['name'];
exit;
    • Génial, merci
    InformationsquelleAutor pixeline
  4. 3

    En outre, vous pouvez utiliser ini_set('session.save_path', '/dir/here'); en supposant que vous avez accès à cette fonction. Les autres moyens proposés sont valables.

    InformationsquelleAutor Norm
  5. 2

    J'ai juste eu exactement le même problème avec un de mes scripts PHP, et j'étais comme ce que je n'ai casser 'cos il a parfaitement fonctionné la veille et je suis en cours d'exécution à partir de ma propre local Chiot Linux de la machine de sorte qu'il n'est même pas un hôte ou quoi que ce soit.

    La seule chose que j'avais fait avant qui essayait de se Java fonctionne dans le navigateur web, de sorte que certains comment j'avais réussi à obtenir que Java fonctionne mais est tombé en PHP - oups!

    De toute façon je ne me souviens que, tout en essayant d'obtenir Java de travail, j'ai supprimé le contenu du dossier /tmp pour essuyer quelque chose qui peut être à l'origine du problème (en fait, il s'est avéré avec Java j'utilise le plugin ancienne oij avec le nouveau Firefox)

    Pour résoudre ce problème, j'ai ouvert Gestionnaire de Fichiers Rox, est allé à l' /dossier et clic droit sur la tmp folder -> Mount Point 'tmp' and clicked properties.

    J'ai remarqué que les autorisations ont été définies en tant que Propriétaire - Lire, Écrire, Exec, mais le Groupe et le Monde était mis à Lire et Exec et ne pas Écrire. J'ai mis une croix en Écriture pour le Groupe et le Monde et maintenant, PHP fonctionne bien à nouveau.

    Je ne sais pas à quel point les autorisations pour tmp doit être changé, mais pour le PHP pour l'utiliser, il doit être réglé pour avoir des autorisations d'Écriture.

    InformationsquelleAutor TheKLF99
  6. 2

    Vérifier que vous n'êtes pas en cours d'exécution dans l'espace de disque problèmes. Si toutes les autorisations sont correctes (et 777 devrait le faire pour vous), alors vous pouvez toujours obtenir cette erreur (pour certaines versions de PHP et d'Apache) si il n'y a pas assez d'espace pour écrire sur le disque.

    InformationsquelleAutor Haz
  7. 2

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

    1. J'ai rempli session de certains vars avec PHP
    2. Alors que la session était encore actif, j'ai changé de PHP 5.4 5.3 sur mon hôte.
    3. Le rechargement de la page a donné l'erreur décrite ci-dessus.
    4. Réinitialiser la version de PHP 5.4 nouveau.
    5. Utilisé session_unset(); et session_destroy(); pour nettoyer la session en cours.
    6. Changé la version de PHP de retour à 5.3.
    7. Maintenant il fonctionne à nouveau.

    Conclusion: Pour une pertinence raison, j'ai dû changer ma version de PHP, et tout en passant par des sessions en vie, les séances d'obtenir endommagé.

    InformationsquelleAutor Erwin Okken
  8. 2

    Je me rends compte que c'est un vieux post, mais je viens de tomber sur ce problème et trouvé une solution de facilité.

    Pour moi, la question qui se passait avec l'un de mes sites déployés localement. Je n'avais pas essayé d'accéder à des sites web en utilisant d'autres navigateurs, mais c'était la même chose à chaque fois que j'ai essayé d'accéder à ce site via google Chrome. J'ai décidé d'aller dans les outils de développement Chrome, sous l'onglet application, -- et en cliquant sur "Effacer la mémoire". Voila-tout fonctionne comme par magie à nouveau.

    Espère que cela aide quelqu'un d'autre!

    InformationsquelleAutor Whipenstein
  9. 2

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

    Pour le fixer, j'ai supprimer le fichier et redémarrer php-fpm.

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

    Maintenant tous fonctionne bien.

    • a travaillé pour moi, l'homme thx
    InformationsquelleAutor oussaka
  10. 1

    Ajoutez la ligne suivante

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

    avant 

    session_start();
    InformationsquelleAutor Ozan Olmez
  11. 1

    Si :

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

    Alors vous allez voir ce message d'erreur lorsque par exemple, Apache, PHP processus tente d'exécuter la collecte des ordures sur les fichiers de session.

    Correctifs :

    1. Reconfigurer PHP donc gc_probability est 0, et ont une tâche cron le retrait de l'ancien/rassis fichier(s).
    2. Ont chacun différents utilisateurs de sauvegarder leurs fichiers de session séparées(s) (session_save_path (), etc).
    InformationsquelleAutor David Goodwin
  12. 1

    si vous utilisez Apache serveur web, la solution est d'aller à votre ligne de commande et tapez:

    open /etc/apache2/

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

    User  _www
Group _www

    C'est parce que vous voulez que votre serveur pour avoir l'autorisation de vos répertoires systèmes, en particulier vous voulez changer le User ou vous pouvez laisser votre Group soit staff ou admin.

    InformationsquelleAutor Hassan Azimi
  13. 0

    Pour moi, le problème semble être un WHM bug!
    J'ai un tas d'ajouter sur les domaines et tous fonctionnent très bien, mais avec un sous-domaine, il apporte cette erreur.

    Chose d'étrange, mais si j'utilise l'URL complète avec le nom de domaine principal, il fonctionne très bien:

    main-domain.com/my.subdomain.com

    Si j'utilise le sous-domaine directement, il apporte de la "Permission denied (13)":

    my.subdomain.com

    La chose, c'est tous les domaines compagnons de la racine est:

    /home/xx/

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

    /

    Si ses vraiment essayer de l'atteindre: /tmp au lieu de /home/xx/tmp

    Qui existe aussi, mais n'ont pas le droit d'autorisations

    Pour clarifier ce sont des exemples de l'ensemble du chemin:

    /home/mon-compte/public_html

    /home/mon-compte/tmp

    /tmp

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

    session_save_path('/home/mon-compte/tmp');

    session_start();

    InformationsquelleAutor ebelendez
  14. 0

    J'ai d'abord eu ce problème, en raison de nginx posséder le /tmp emplacement et php-fpm était en cours d'exécution en vertu de l' 'apache' utilisateur et de groupe en raison de la http://www.conf. J'ai troqué l'utilisateur/groupe dans ce fichier, et puis il a travaillé sur ok. Vous voudrez peut-être vérifier <?php echo exec('whoami'); ?> pour vérifier.

    InformationsquelleAutor Mark
  15. 0

    À l'aide de PHP 5.6 j'avais déjà utilisé session_save_path() pour pointer vers un répertoire dans le domaine de la structure. Il a bien fonctionné jusqu'à ce que j'ai mis à jour à la version 7.0, au moment où j'ai reçu le relevé d'erreur. Au PHP.net j'ai trouvé plusieurs commentaires qui indique l'affectation d'un chemin direct ne fonctionne pas toujours, j'ai donc utilisé leur suggestion.

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

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

    InformationsquelleAutor JBH