file_put_contents - échec de l'ouverture du flux: autorisation refusée

97

J'essaye d'écrire une requête dans un fichier pour le débogage. Le fichier est au format database/execute.php. Le fichier dans lequel je veux écrire est database/queries.php.

J'essaye d'utiliser file_put_contents('queries.txt', $query)

Mais je reçois

file_put_contents (queries.txt) [function.file-put-contents]: échec de l'ouverture du flux: autorisation refusée

J'ai le queries.txtfichier chmod'd à 777, quel pourrait être le problème?

Hailwood
la source
Avez-vous cherché dans le php.inifichier tout ce qui pourrait refuser l'accès au fichier?
Hello71
2
assurez-vous également que le répertoire est bien chmod'd
Crayon Violent
1
essayez également d'utiliser le nom de fichier absolu. Il se peut que votre interprétation du dossier actuel soit différente de celle de PHP
laher
1
Pouvez-vous vérifier ce statut chmod?
Jonah
1
Il existe une liste de contrôle de dépannage pour ce type de problèmes: stackoverflow.com/questions/36577020/…
Vic Seedoubleyew

Réponses:

73

Essayez d'ajuster les autorisations du répertoire.

depuis un terminal, exécutez chmod 777 database(depuis le répertoire qui contient le dossier de la base de données)

apache et personne n'aura accès à ce répertoire s'il est correctement chmodd.

L'autre chose à faire est d'écho "getcwd ()". Cela vous montrera le répertoire actuel, et si ce n'est pas "/quelque chose.../database/", vous devrez changer "query.txt" par le chemin complet de votre serveur.

Jason
la source
104
Le 777 n'est-il pas un risque pour la sécurité?
hitautodestruct
12
Je soupçonne fortement que non seulement le répertoire cible doit être accessible en écriture par le compte serveur, mais que chaque répertoire parent du répertoire cible doit permettre au compte serveur d'y accéder; Je pense que ce serait + x aux autorisations.
Erhannis
2
J'ai expérimenté les théories d'Erhannis sur une nouvelle pile LAMP et la théorie est juste.
thotheolh
4
@MajidFouladpour je pense chmod +x /parent/directory, pour chaque répertoire parent de la cible. chmod +x /parent/directory, chmod +x /parent, Etc.
Erhannis
1
Il existe maintenant une liste de contrôle de dépannage pour ce type de problèmes: stackoverflow.com/questions/36577020/…
Vic Seedoubleyew
18

L'autre option

est que vous pouvez faire Apache (www-data), le propriétaire du dossier

sudo chown -R www-data:www-data /var/www

cela devrait file_put_contentsfonctionner maintenant. Mais pour plus de sécurité, il vaut mieux également définir les autorisations comme ci-dessous

find /var/www -type d -print0 | xargs -0 chmod 0755 # folder
find /var/www -type f -print0 | xargs -0 chmod 0644 # files
  • passez /var/wwwau dossier racine de vos fichiers php
azerafati
la source
7

Sachez que c'est assez ancien maintenant, mais il n'est pas nécessaire d'écrire manuellement des requêtes dans un fichier comme celui-ci. MySQL a un support de journalisation intégré, il vous suffit de l'activer dans votre environnement de développement.

Jetez un œil à la documentation du 'journal des requêtes générales':

http://dev.mysql.com/doc/refman/5.1/en/query-log.html

Adam
la source
3

Les gars, j'ai eu ce problème pendant 1 mois et j'ai tout fait mais je n'ai pas pu le résoudre, mais maintenant je connais la solution.

J'utilise un hébergement Linux partagé, lorsque mon administrateur a changé le php en 5.3, j'ai eu beaucoup d'erreurs pour le code "file_put_contents". essayez de tester mon plan:

Dans votre hôte, créez un fichier comme mytest.php, insérez ce code et enregistrez:

<?php        mail('Your-EMail','Email-Title','Email-Message');        ?>

Ouvrez l'URL "www.votre-domaine.com/mytest.php" une fois, puis vérifiez votre messagerie. vous devriez avoir un e-mail de votre hôte avec les informations que vous avez saisies dans mytest.php, vérifiez le nom de l'expéditeur. si c'est de Personne, vous avez un problème avec "Permission Denied" parce que quelque chose n'est pas défini et si le nom de l'expéditeur est comme mon id: [email protected] vous n'avez pas de prob.

Mon administrateur a changé le serveur et a réinstallé l'hôte, je pense, et le problème a été résolu, dites à votre administration hôte ce que je vous ai dit et peut-être qu'il trouve la réponse.

j'espère que cela vous aide!

Hesam
la source
Je suis complètement perdu !! Qu'est-ce que tu essayes de dire? Si vous dites que l'utilisateur apache n'a pas pu obtenir le nom d'hôte sur le serveur (partagé ou autre), il est grand temps que vous reconsidériez votre choix de service d'hébergement.
Fr0zenFyr
3

Je sais que c'est une question très ancienne, mais je voulais ajouter la bonne solution avec une explication approfondie. Vous devrez exécuter deux instructions sur des systèmes comme Ubuntu, puis cela fonctionnera comme un charme.

Les autorisations sous Linux peuvent être représentées par trois chiffres. Le premier chiffre définit l'autorisation du propriétaire des fichiers. Le deuxième chiffre les autorisations d'un groupe spécifique d'utilisateurs. Le troisième chiffre définit les autorisations pour tous les utilisateurs qui ne sont ni le propriétaire ni membre du groupe.

Le serveur Web est censé s'exécuter avec un identifiant membre du groupe. Le serveur Web ne doit jamais fonctionner avec le même identifiant que le propriétaire des fichiers et répertoires. Dans Ubuntu exécute apache sous l'id www-data. Cet identifiant doit être membre du groupe pour lequel les autorisations sont spécifiées.

Pour donner au répertoire dans lequel vous souhaitez modifier le contenu des fichiers les droits appropriés, exécutez l'instruction:

find %DIR% -type d -exec chmod 770 {} \;

Cela impliquerait dans la question de l'OP que les permissions du répertoire% ROOT% / database devraient être modifiées en conséquence. Il est donc important de ne pas avoir de fichiers dans ce répertoire qui ne devraient jamais être modifiés ou supprimés. Il est donc recommandé de créer un répertoire distinct pour les fichiers dont le contenu doit être modifié.

Les permissions de lecture (4) pour un répertoire signifie être capable de collecter tous les fichiers et répertoires avec leurs métadonnées dans un répertoire. Les permissions d'écriture (2) donnent la permission de changer le contenu du répertoire. Impliquant l'ajout et la suppression de fichiers, la modification des autorisations, etc. L'autorisation d'exécution (1) signifie que vous avez le droit d'aller dans ce répertoire. Sans ce dernier, il est impossible d'approfondir le répertoire. Le serveur Web a besoin d'autorisations de lecture, d'écriture et d'exécution lorsque le contenu d'un fichier doit être modifié. Pour cela, le groupe a besoin du chiffre 7.

La deuxième affirmation concerne la question du PO:

find %DOCUMENT_ROOT%/database -type f -exec chmod 760 {} \;

Être capable de lire et d'écrire un document est requis, mais ce n'est pas obligatoire pour exécuter le fichier. Le 7 est donné au propriétaire des fichiers, le 6 au groupe. Le serveur Web n'a pas besoin d'avoir l'autorisation d'exécuter le fichier pour modifier son contenu. Ces autorisations d'écriture ne doivent être accordées qu'aux fichiers de ce répertoire.

Tous les autres utilisateurs ne doivent recevoir aucune autorisation.

Pour les répertoires qui ne nécessitent pas de modifier ses fichiers, les autorisations de groupe de 5 sont suffisantes. Documentation sur les autorisations et quelques exemples:

https://wiki.debian.org/Permissions

https://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions

http://www.linux.org/threads/file-permissions-chmod.4094/

Loek Bergman
la source
3

La collecte d'informations à partir de ce lien stackoverflow-image save ne fonctionne pas avec chmod 777 et à partir de l'utilisateur azerafati et Loek Bergman

si vous regardez sous le fichier / etc / apache / envvars, vous verrez quelque chose comme:

export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data

Apache est exécuté sous le nom d'utilisateur 'www-data'

«0755» signifie que le propriétaire du fichier peut lire / écrire / exécuter mais que le groupe et les autres utilisateurs ne peuvent pas écrire. donc dans votre terminal, cd dans le dossier contenant votre dossier «images». puis tapez:

find images -type d -exec chmod 0755 {} \;
find images -type f -exec chmod 0755 {} \;
sudo chown -R www-data:www-data images

vous devez d'abord modifier les autorisations avant de changer de propriétaire. entrez votre mot de passe lorsque vous y êtes invité. cela rendra "www-data" propriétaire du dossier images.

votre téléchargement devrait maintenant fonctionner.

Bruce Tong
la source
1

Pour toute personne utilisant Ubuntu et recevant cette erreur lors du chargement de la page localement, mais pas sur un service d'hébergement Web,

Je viens de résoudre ce problème en ouvrant nautilus ( sudo nautilus) et en faisant un clic droit sur le fichier que vous essayez d'ouvrir, cliquez sur Propriétés> Paramètres> et donnez la lecture-écriture à `` tout le monde ''

d -_- b
la source
0

eu le même problème; mon problème était que selinux était mis en application.

J'ai continué à recevoir l'erreur «Échec de l'ouverture du flux: Autorisation refusée» même après avoir chmoding à 777 et m'être assuré que tous les dossiers parents avaient des autorisations d'exécution pour l'utilisateur apache. Il s'avère que mon problème était que selinux était configuré pour appliquer (je suis sur centos7), c'est une devbox, donc je l'ai désactivée.

DaveS
la source
0

Cela peut être résolu en procédant comme suit:

1. $ php artisan cache:clear

2. $ sudo chmod -R 777 storage

3. $ composer dump-autoload

J'espère que ça aide


la source
0

Si vous tirez de git du local vers le serveur, vous devrez parfois vider le cache à cause des fichiers de vue qu'il est téléchargé avec lui / ou d'autres fichiers mis en cache.

php artisan cache:clear

Parfois, cela peut être le cas si votre application fonctionnait avant le pull git

Deepesh Thapa
la source
0

cela pourrait aider. Cela a fonctionné pour moi. essayez-le dans le terminal

setenforce 0

Lithin Joseph
la source
-2

Il existe 2 façons de résoudre ces problèmes
1. utilisez chmod 777 path-to-your-directory.
si cela ne fonctionne pas,
indiquez simplement le chemin complet de votre fichier query.txt.

Salman Mohammad
la source
2
C'est une pratique horriblement peu sûre et extrêmement mauvaise. Il est également difficile à détecter et à corriger lors du développement d'applications personnalisées et peut être facilement ignoré. Veuillez trouver les bonnes autorisations.
ftrotter le
-3

Voici la solution. Pour copier une image depuis une URL. cette URL:http://url/img.jpg

$image_Url=file_get_contents('http://url/img.jpg');

créer le chemin souhaité terminer le nom avec .jpg

$file_destino_path="imagenes/my_image.jpg";

file_put_contents($file_destino_path, $image_Url)
masterhoo
la source
-11

En outre, comme on dit dans file_put_contents man pageen php.net, méfiez - vous de nommer des questions.

file_put_contents($dir."/file.txt", "hello");

peut ne pas fonctionner (même si la syntaxe est correcte), mais

file_put_contents("$dir/file.txt", "hello");

travaux. J'ai vécu cela sur différents serveurs installés en PHP.

Kivanc
la source
17
Ce n'est pas correct. $dir."/file.txt"est fonctionnellement équivalent à "$dir/file.txt"dans tous les cas, en supposant qu'il $dirs'agit d'une chaîne. De plus, ce comportement n'est pas documenté sur php.net, comme le prétend Kivanc.
mattbasta