fputs error ejemplo php require fopen include-path

error - fread php



PHP-Error al abrir la secuencia: no existe tal archivo o directorio (5)

Agregar script con parámetros de consulta

Ese fue mi caso. En realidad, enlaza con la pregunta # 4485874 , pero voy a explicarlo aquí en breve.
Cuando intenta solicitar path/to/script.php?parameter=value , PHP busca el archivo llamado script.php?parameter=value , porque UNIX le permite tener rutas como esta.
Si realmente necesita pasar algunos datos al script incluido, simplemente declare como $variable=... o $GLOBALS[]=... u otra forma que desee.

En los scripts PHP, si se llama a include() , require() , fopen() o sus derivados, como include_once , require_once o incluso, move_uploaded_file() , a menudo se encuentra un error o advertencia:

Error al abrir la secuencia: no existe tal archivo o directorio.

¿Cuál es un buen proceso para encontrar rápidamente la causa del problema?

  1. Mira el error exacto

Mi código funcionó bien en todas las máquinas, pero solo en este comenzó a dar problemas (supongo que solía funcionar). Se usó la ruta echo "document_root" para depurar y también se examinó de cerca el error, se encontró esto

Advertencia: include ( D: /MyProjects/testproject//functions/connections.php ): no se pudo abrir la transmisión:

Puedes ver fácilmente dónde están los problemas. Los problemas son // antes de las funciones

$document_root = $_SERVER[''DOCUMENT_ROOT'']; echo "root: $document_root"; include($document_root.''/functions/connections.php'');

Entonces, simplemente elimine el cargamento / incluir y debería funcionar bien. Lo interesante es que este comportamiento es diferente en diferentes versiones. Ejecuté el mismo código en la computadora portátil, Macbook Pro y esta PC, todo funcionó bien hasta ahora. Espero que esto ayude a alguien.

  1. Copie más allá de la ubicación del archivo en el navegador para asegurarse de que el archivo existe. A veces los archivos se eliminan inesperadamente (sucedió conmigo) y también fue el problema en mi caso.

Hay muchas razones por las cuales uno podría encontrarse con este error y, por lo tanto, una buena lista de verificación de qué verificar primero ayuda considerablemente.

Consideremos que estamos solucionando problemas en la siguiente línea:

require "/path/to/file"


Lista de verificación


1. Verifique la ruta del archivo en busca de errores tipográficos

  • ya sea comprobar manualmente (comprobando visualmente la ruta)

  • o mueva lo que sea llamado por require* o include* a su propia variable, repítalo, cópielo e intente acceder a él desde un terminal:

    $path = "/path/to/file"; echo "Path : $path"; require "$path";

    Luego, en una terminal:

    cat <file path pasted>


2. Verifique que la ruta del archivo sea correcta con respecto a las consideraciones relativas frente a la ruta absoluta

  • si comienza con una barra diagonal "/", no se refiere a la raíz de la carpeta de su sitio web (la raíz del documento), sino a la raíz de su servidor.
    • por ejemplo, el directorio de su sitio web podría ser /users/tony/htdocs
  • si no comienza con una barra diagonal, entonces depende de la ruta de inclusión (ver más abajo) o la ruta es relativa. Si es relativo, entonces PHP calculará relativamente la ruta del directorio de trabajo actual .
    • por lo tanto, no es relativo a la ruta de la raíz de su sitio web, o al archivo donde está escribiendo
    • por esa razón, siempre use rutas de archivo absolutas

Mejores prácticas :

Para hacer que su script sea robusto en caso de que mueva cosas, mientras genera una ruta absoluta en tiempo de ejecución, tiene 2 opciones:

  1. uso require __DIR__ . "/relative/path/from/current/file" require __DIR__ . "/relative/path/from/current/file" . La constante mágica __DIR__ devuelve el directorio del archivo actual.

  2. define una constante SITE_ROOT tú mismo:

    • en la raíz del directorio de su sitio web, cree un archivo, por ejemplo config.php

    • en config.php , escribe

      define(''SITE_ROOT'', __DIR__);

    • en cada archivo donde desee hacer referencia a la carpeta raíz del sitio, incluya config.php , y luego use la constante SITE_ROOT donde desee:

      require_once __DIR__."/../config.php"; ... require_once SITE_ROOT."/other/file.php";

Estas 2 prácticas también hacen que su aplicación sea más portátil porque no se basa en configuraciones ini como la ruta de inclusión.


3. Verifique su ruta de inclusión

Otra forma de incluir archivos, ni relativa ni puramente absoluta, es confiar en la ruta de inclusión . Este suele ser el caso de bibliotecas o marcos como el marco Zend.

Tal inclusión se verá así:

include "Zend/Mail/Protocol/Imap.php"

En ese caso, querrá asegurarse de que la carpeta donde está "Zend" sea parte de la ruta de inclusión.

Puede verificar la ruta de inclusión con:

echo get_include_path();

Puede agregarle una carpeta con:

set_include_path(get_include_path().":"."/path/to/new/folder");


4. Verifique que su servidor tenga acceso a ese archivo

Es posible que, en conjunto, el usuario que ejecuta el proceso del servidor (Apache o PHP) simplemente no tenga permiso para leer o escribir en ese archivo.

Para verificar con qué usuario está ejecutando el servidor, puede usar posix_getpwuid :

$user = posix_getpwuid(posix_geteuid()); var_dump($user);

Para conocer los permisos en el archivo, escriba el siguiente comando en la terminal:

ls -l <path/to/file>

y mira el permiso de notación simbólica


5. Compruebe la configuración de PHP

Si nada de lo anterior funcionó, entonces el problema es probablemente que algunas configuraciones de PHP le prohiben acceder a ese archivo.

Tres configuraciones podrían ser relevantes:

  1. open_basedir
    • Si esto está configurado, PHP no podrá acceder a ningún archivo fuera del directorio especificado (ni siquiera a través de un enlace simbólico).
    • Sin embargo, el comportamiento predeterminado es que no se establezca, en cuyo caso no hay restricción
    • Esto puede verificarse llamando a phpinfo() o usando ini_get("open_basedir")
    • Puede cambiar la configuración editando su archivo php.ini o su archivo httpd.conf
  2. modo seguro
    • si esto está activado, podrían aplicarse restricciones. Sin embargo, esto se ha eliminado en PHP 5.4. Si todavía está en una versión que admite la actualización en modo seguro a una versión de PHP que todavía es compatible .
  3. allow_url_fopen y allow_url_include
    • esto se aplica solo a la inclusión o apertura de archivos a través de un proceso de red como http: // no cuando se trata de incluir archivos en el sistema de archivos local
    • esto puede verificarse con ini_get("allow_url_include") y establecerse con ini_set("allow_url_include", "1")


Casos de esquina

Si nada de lo anterior habilitado para diagnosticar el problema, aquí hay algunas situaciones especiales que podrían suceder:


1. La inclusión de la biblioteca basándose en la ruta de inclusión

Puede suceder que incluya una biblioteca, por ejemplo, el marco Zend, utilizando una ruta relativa o absoluta. Por ejemplo :

require "/usr/share/php/libzend-framework-php/Zend/Mail/Protocol/Imap.php"

Pero aún así obtienes el mismo tipo de error.

Esto puede suceder porque el archivo que ha incluido (con éxito) tiene una declaración de inclusión para otro archivo, y esa segunda declaración de inclusión supone que ha agregado la ruta de esa biblioteca a la ruta de inclusión.

Por ejemplo, el archivo de marco Zend mencionado anteriormente podría incluir lo siguiente:

include "Zend/Mail/Protocol/Exception.php"

que no es una inclusión por ruta relativa, ni por ruta absoluta. Se supone que el directorio del marco Zend se ha agregado a la ruta de inclusión.

En tal caso, la única solución práctica es agregar el directorio a su ruta de inclusión.


2. SELinux

Si está ejecutando Security-Enhanced Linux, entonces podría ser la razón del problema, al negar el acceso al archivo desde el servidor.

Para verificar si SELinux está habilitado en su sistema, ejecute el comando sestatus en una terminal. Si el comando no existe, entonces SELinux no está en su sistema. Si existe, entonces debería decirle si se aplica o no.

Para verificar si las políticas de SELinux son la razón del problema, puede intentar desactivarlo temporalmente. Sin embargo, tenga cuidado, ya que esto deshabilitará la protección por completo. No haga esto en su servidor de producción.

setenforce 0

Si ya no tiene el problema con SELinux apagado, esta es la causa raíz.

Para resolverlo , deberá configurar SELinux en consecuencia.

Los siguientes tipos de contexto serán necesarios:

  • httpd_sys_content_t para archivos que desea que su servidor pueda leer
  • httpd_sys_rw_content_t para archivos en los que desea acceso de lectura y escritura
  • httpd_log_t para archivos de registro
  • httpd_cache_t para el directorio de caché

Por ejemplo, para asignar el tipo de contexto httpd_sys_content_t al directorio raíz de su sitio web, ejecute:

semanage fcontext -a -t httpd_sys_content_t "/path/to/root(/.*)?" restorecon -Rv /path/to/root

Si su archivo está en un directorio de inicio, también deberá activar el booleano httpd_enable_homedirs :

setsebool -P httpd_enable_homedirs 1

En cualquier caso, podría haber una variedad de razones por las cuales SELinux negaría el acceso a un archivo, dependiendo de sus políticas. Entonces tendrá que investigar sobre eso. Here hay un tutorial específicamente sobre la configuración de SELinux para un servidor web.


3. Symfony

Si está utilizando Symfony y experimenta este error al cargar en un servidor, puede ser que la memoria caché de la aplicación no se haya restablecido, ya sea porque la app/cache se ha cargado o porque la memoria caché no se ha borrado.

Puede probar y solucionar esto ejecutando el siguiente comando de consola:

cache:clear


4. Caracteres no ACSII dentro del archivo Zip

Aparentemente, este error puede ocurrir también al llamar a zip->close() cuando algunos archivos dentro del zip tienen caracteres no ASCII en su nombre de archivo, como "é".

Una posible solución es ajustar el nombre del archivo en utf8_decode() antes de crear el archivo de destino.

Créditos a Fran Cano por identificar y sugerir una solución a este problema

Otra posible causa: cambiar el nombre y / o mover archivos mientras está en un editor de texto. Pasé por todos los pasos anteriores sin éxito hasta que eliminé el archivo que seguía arrojando este error y creé uno nuevo, que solucionó el problema.

Para agregar a la (realmente buena) respuesta existente

Software de alojamiento compartido

open_basedir es uno que puede open_basedir porque se puede especificar en la configuración de un servidor web. Si bien esto se soluciona fácilmente si ejecuta su propio servidor dedicado, existen algunos paquetes de software de alojamiento compartido (como Plesk, cPanel, etc.) que configurarán una directiva de configuración por dominio. Debido a que el software crea el archivo de configuración (es decir, httpd.conf ), no puede cambiar ese archivo directamente porque el software de alojamiento simplemente lo sobrescribirá cuando se reinicie.

Con Plesk, proporcionan un lugar para anular el httpd.conf proporcionado vhost.conf . Solo el administrador del servidor puede escribir este archivo. La configuración de Apache se parece a esto

<Directory /var/www/vhosts/domain.com> <IfModule mod_php5.c> php_admin_flag engine on php_admin_flag safe_mode off php_admin_value open_basedir "/var/www/vhosts/domain.com:/tmp:/usr/share/pear:/local/PEAR" </IfModule> </Directory>

Haga que el administrador de su servidor consulte el manual del software de alojamiento y servidor web que utilizan.

Permisos de archivo

Es importante tener en cuenta que la ejecución de un archivo a través de su servidor web es muy diferente de la ejecución de una línea de comandos o trabajo cron. La gran diferencia es que su servidor web tiene su propio usuario y permisos. Por razones de seguridad, ese usuario está bastante restringido. Apache, por ejemplo, a menudo es apache , www-data o httpd (dependiendo de su servidor). Un trabajo cron o ejecución de CLI tiene los permisos que tiene el usuario que lo ejecuta (es decir, ejecutar un script PHP como root se ejecutará con permisos de root).

Muchas veces las personas resolverán un problema de permisos haciendo lo siguiente (ejemplo de Linux)

chmod 777 /path/to/file

Esta no es una idea inteligente, porque el archivo o directorio ahora se puede escribir en todo el mundo. Si posee el servidor y es el único usuario, entonces esto no es un gran problema, pero si está en un entorno de alojamiento compartido, acaba de dar acceso a todos los que están en su servidor.

Lo que debe hacer es determinar los usuarios que necesitan acceso y darles acceso solo a ellos. Una vez que sepa qué usuarios necesitan acceso, querrá asegurarse de que

  1. Ese usuario posee el archivo y posiblemente el directorio principal (especialmente el directorio principal si desea escribir archivos). En la mayoría de los entornos de alojamiento compartido, esto no será un problema, ya que su usuario debe poseer todos los archivos debajo de su raíz. A continuación se muestra un ejemplo de Linux

    chown apache:apache /path/to/file

  2. El usuario, y solo ese usuario, tiene acceso. En Linux, una buena práctica sería chmod 600 (solo el propietario puede leer y escribir) o chmod 644 (el propietario puede escribir pero todos pueden leer)

Puede leer una discusión más extensa sobre los permisos y usuarios de Linux / Unix aquí