file_put_contents: no se pudo abrir la transmisión: permiso denegado


97

Estoy tratando de escribir una consulta en un archivo para depurarlo. El archivo está en formato database/execute.php. El archivo en el que quiero escribir es database/queries.php.

Estoy tratando de usar file_put_contents('queries.txt', $query)

Pero estoy consiguiendo

file_put_contents (queries.txt) [function.file-put-contents]: no se pudo abrir la transmisión: permiso denegado

Tengo el queries.txtarchivo chmod'd a 777, ¿cuál podría ser el problema?


¿Ha mirado el php.iniarchivo en busca de algo que pueda denegar el acceso al archivo?
Hola 71

2
también asegúrese de que el directorio tenga la modificación correcta
Crayon Violent

1
también intente usar el nombre de archivo absoluto. Podría ser que su interpretación de la carpeta actual sea diferente de la de PHP
laher

1
¿Puedes verificar el estado de chmod?
Jonás

1
Hay una lista de verificación de solución de problemas para este tipo de problemas: stackoverflow.com/questions/36577020/…
Vic Seedoubleyew

Respuestas:


73

Intente ajustar los permisos del directorio.

desde una terminal, ejecutar chmod 777 database(desde el directorio que contiene la carpeta de la base de datos)

apache y nadie tendrá acceso a este directorio si se chmodd'ed correctamente.

La otra cosa a hacer es hacer eco de "getcwd ()". Esto le mostrará el directorio actual, y si no es '/something.../database/', entonces deberá cambiar 'query.txt' por la ruta completa de su servidor.


104
¿No es 777 un riesgo de seguridad?
hitautodestruct

12
Sospecho firmemente que no solo la cuenta del servidor debe poder escribir en el directorio de destino, sino que cada directorio principal del directorio de destino debe permitir que la cuenta del servidor navegue por él; Creo que esto sería + x a los permisos.
Erhannis

2
Experimenté las teorías de Erhannis en una nueva pila LAMP y la teoría es correcta.
thotheolh

4
@MajidFouladpour, creo chmod +x /parent/directory, para cada directorio principal del objetivo. chmod +x /parent/directory, chmod +x /parent, Etc.
Erhannis

1
Ahora hay una lista de verificación de solución de problemas para este tipo de problemas: stackoverflow.com/questions/36577020/…
Vic Seedoubleyew

18

La otra opcion

es que puede hacer Apache (www-data), el propietario de la carpeta

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

eso debería file_put_contentsfuncionar ahora. Pero para mayor seguridad, es mejor que también configure los permisos como se muestra a continuación

find /var/www -type d -print0 | xargs -0 chmod 0755 # folder
find /var/www -type f -print0 | xargs -0 chmod 0644 # files
  • cambie /var/wwwa la carpeta raíz de sus archivos php

7

Tenga en cuenta que esto es bastante antiguo ahora, pero no es necesario escribir consultas manualmente en un archivo como este. MySQL tiene soporte de registro integrado, solo necesita habilitarlo dentro de su entorno de desarrollo.

Eche un vistazo a la documentación del 'registro de consultas general':

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


3

Chicos, tuve este problema durante 1 mes e hice todo, pero no pude solucionarlo, pero ahora conozco la solución.

Utilizo un alojamiento Linux compartido, cuando mi administrador cambió el php a 5.3 recibí muchos errores para el código "file_put_contents". intenta probar mi plan:

En su host, cree un archivo como mytest.php, ingrese este código y guárdelo:

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

Abra la URL "www.your-domain.com/mytest.php" una vez y luego verifique su correo electrónico. debe tener un correo electrónico de su anfitrión con la información que ingresó en mytest.php, verifique el nombre del remitente. si es de Nadie , tienes un problema con "Permiso denegado" porque algo no está definido y si el nombre del remitente es como mi identificación: iietj8qy@hostname5.netly.net, no tienes problema.

Mi administrador cambió el servidor e instaló el host de nuevo, creo que y el problema se resolvió, dígale a la administración de su host lo que le dije y tal vez encuentre la respuesta.

espero que te ayude!


¡¡Estoy completamente perdido !! ¿Qué estás tratando de decir? Si está diciendo que el usuario de apache no pudo obtener el nombre de host en el servidor (compartido o lo que sea), entonces es hora de que reconsidere su elección de un servicio de alojamiento.
Viernes

3

Sé que es una pregunta muy antigua, pero quería agregar la buena solución con una explicación en profundidad. Tendrá que ejecutar dos sentencias en sistemas tipo Ubuntu y luego funcionará como un encanto.

Los permisos en Linux se pueden representar con tres dígitos. El primer dígito define el permiso del propietario de los archivos. El segundo dígito son los permisos de un grupo específico de usuarios. El tercer dígito define los permisos para todos los usuarios que no son propietarios ni miembros del grupo.

Se supone que el servidor web se ejecuta con una identificación que es miembro del grupo. El servidor web nunca debe ejecutarse con la misma identificación que el propietario de los archivos y directorios. En Ubuntu se ejecuta apache con el id www-data. Esa identificación debe ser un miembro del grupo para el que se especifican los permisos.

Para otorgarle al directorio en el que desea cambiar el contenido de los archivos los derechos adecuados, ejecute la instrucción:

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

. Eso implicaría en la cuestión del OP que los permisos para el directorio% ROOT% / database deberían cambiarse en consecuencia. Por lo tanto, es importante no tener archivos dentro de ese directorio que nunca deberían modificarse o eliminarse. Por lo tanto, es una buena práctica crear un directorio separado para los archivos cuyo contenido debe cambiarse.

Leer permisos (4) para un directorio significa poder recopilar todos los archivos y directorios con sus metadatos dentro de un directorio. Los permisos de escritura (2) dan permiso para cambiar el contenido del directorio. Lo que implica agregar y eliminar archivos, cambiar permisos, etc. El permiso de ejecución (1) significa que tiene derecho a ingresar a ese directorio. Sin este último es imposible profundizar en el directorio. El servidor web necesita permisos de lectura, escritura y ejecución cuando se debe cambiar el contenido de un archivo. Por lo tanto, el grupo necesita el dígito 7.

La segunda declaración está en la cuestión del PO:

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

Se requiere poder leer y escribir un documento, pero no es necesario para ejecutar el archivo. El 7 se le da al propietario de los archivos, el 6 al grupo. El servidor web no necesita tener permiso para ejecutar el archivo a fin de cambiar su contenido. Esos permisos de escritura solo deben otorgarse a archivos en ese directorio.

Todos los demás usuarios no deben tener ningún permiso.

Para directorios que no requieren cambiar sus archivos, son suficientes los permisos de grupo de 5. Documentación sobre permisos y algunos ejemplos:

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/


3

La recopilación de información de este enlace stackoverflow-image save no funciona con chmod 777 y del usuario azerafati y Loek Bergman

si buscara en el archivo / etc / apache / envvars, verá algo como:

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

Apache se ejecuta con el nombre de usuario 'www-data'

'0755' significa que el propietario del archivo puede leer / escribir / ejecutar, pero el grupo y otros usuarios no pueden escribir. así que en tu terminal, cd a la carpeta que contiene tu carpeta de 'imágenes'. luego escriba:

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

primero debe cambiar las permisos antes de cambiar de propietario. Introduzca su contraseña cuando se le solicite. esto hará que 'www-data' sea el propietario de la carpeta de imágenes.

su carga ahora debería funcionar.


1

Para cualquiera que use Ubuntu y reciba este error al cargar la página localmente, pero no en un servicio de alojamiento web,

Acabo de arreglar esto abriendo nautilus ( sudo nautilus) y haga clic derecho en el archivo que está tratando de abrir, haga clic en propiedades> Configuración> y dé lectura y escritura a 'todos los demás'


0

tenía el mismo problema; mi problema fue que Selinux estaba configurado para hacer cumplir.

Seguí recibiendo el error "No se pudo abrir la secuencia: Permiso denegado" incluso después de cambiar a 777 y asegurarme de que todas las carpetas principales tuvieran permisos de ejecución para el usuario de Apache. Resulta que mi problema era que selinux estaba configurado para hacer cumplir (estoy en centos7), esto es un devbox, así que lo apagué.


0

Esto se puede resolver con los siguientes pasos:

1. $ php artisan cache:clear

2. $ sudo chmod -R 777 storage

3. $ composer dump-autoload

Espero eso ayude


0

Si está extrayendo de git de local al servidor, necesitará borrar el caché a veces debido a los archivos de vista que se cargan con él / u otros archivos en caché.

php artisan cache:clear

A veces, podría ser un truco si su aplicación estaba funcionando antes del git pull


0

esto podría ayudar. Funcionó para mí. pruébalo en la terminal

setenforce 0


-2

Hay 2 formas de resolver estos problemas
1. Utilice chmod 777 path-to-your-directory.
si no funciona,
simplemente proporcione la ruta completa de su archivo query.txt.


2
Esta es una práctica horriblemente insegura y extremadamente mala. También es difícil de detectar y corregir al desarrollar aplicaciones personalizadas y puede pasarse por alto fácilmente. Por favor, averigüe cuáles son los permisos correctos.
ftrotter

-3

Aquí la solución. Para copiar una imagen de una URL. esta URL:http://url/img.jpg

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

crear la ruta deseada terminar el nombre con .jpg

$file_destino_path="imagenes/my_image.jpg";

file_put_contents($file_destino_path, $image_Url)

-11

Además, como se dice en file_put_contents man pageen php.net, tenga cuidado con los problemas de nombres.

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

puede que no funcione (aunque sea correcto en la sintaxis), pero

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

trabajos. Experimenté esto en diferentes servidores php instalados.


17
Esto no es correcto. $dir."/file.txt"es funcionalmente equivalente a "$dir/file.txt"en todos los casos, asumiendo que $dires una cadena. Además, este comportamiento no está documentado en php.net, como afirma Kivanc.
mattbasta
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.