PHP - 无法打开流:没有这样的文件或目录
P粉145543872
2023-08-23 16:30:33
<p>在 PHP 脚本中,无论是调用 <code>include()</code>、<code>require()</code>、<code>fopen()</code> 或其派生类,例如 <code> include_once</code>、<code>require_once</code>,甚至 <code>move_uploaded_file()</code>,经常会遇到错误或警告:</p>
<blockquote>
<p>无法打开流:没有这样的文件或目录。</p>
</blockquote>
<p>快速找到问题根本原因的好流程是什么?</p>
添加到(非常好的)现有答案
共享托管软件
open_basedir
可能会难倒您,因为它可以在 Web 服务器配置中指定。虽然如果您运行自己的专用服务器,这很容易解决,但有一些共享托管软件包(如 Plesk、cPanel 等)可以在每个域的基础上配置配置指令。由于该软件会构建配置文件(即httpd.conf
),因此您无法直接更改该文件,因为托管软件在重新启动时只会覆盖它。通过 Plesk,他们提供了一个位置来覆盖所提供的
httpd.conf
(称为vhost.conf
)。只有服务器管理员可以写入此文件。 Apache 的配置看起来像这样让您的服务器管理员查阅他们使用的托管和 Web 服务器软件的手册。
文件权限
需要注意的是,通过 Web 服务器执行文件与命令行或 cron 作业执行有很大不同。最大的区别是您的网络服务器有自己的用户和权限。出于安全原因,该用户受到很大限制。例如,Apache 通常是
apache
、www-data
或httpd
(取决于您的服务器)。 cron 作业或 CLI 执行具有运行它的用户所拥有的任何权限(即以 root 身份运行 PHP 脚本将以 root 权限执行)。很多时候人们会通过执行以下操作来解决权限问题(Linux 示例)
这不是一个聪明的主意,因为文件或目录现在是全局可写的。如果您拥有该服务器并且是唯一的用户,那么这并不是什么大问题,但如果您位于共享托管环境中,您就授予了服务器上的每个人访问权限。
您需要做的是确定需要访问权限的用户并只授予他们访问权限。一旦您知道哪些用户需要访问权限,您就需要确保
该用户拥有该文件并且可能拥有父目录(尤其是如果您要写入文件则为父目录)。在大多数共享托管环境中,这不会成为问题,因为您的用户应该拥有根目录下的所有文件。下面显示了一个 Linux 示例
该用户(且只有该用户)具有访问权限。在 Linux 中,一个好的做法是
chmod 600
(只有所有者可以读写)或chmod 644
(所有者可以写入,但每个人都可以读取)您可以阅读有关 Linux 的更广泛的讨论/此处的 Unix 权限和用户
可能会遇到此错误的原因有很多,因此首先检查哪些内容的良好清单会很有帮助。
假设我们正在对以下行进行故障排除:
清单
1。检查文件路径是否有拼写错误
或者将
require*
或include*
调用的任何内容移动到其自己的变量中,回显它,复制它,然后尝试从终端访问它:然后,在终端中:
2。检查相对与绝对路径注意事项的文件路径是否正确
/users/tony/htdocs
最佳实践:
为了使您的脚本在移动内容时保持健壮,同时仍然在运行时生成绝对路径,您有 2 个选项:
require __DIR__ 。 “/相对/路径/来自/当前/文件”
。__DIR__
魔术常量 返回当前文件的目录。自己定义一个
SITE_ROOT
常量:config.php
在
config.php
中写入在要引用站点根文件夹的每个文件中,包含
config.php
,然后在任意位置使用SITE_ROOT
常量: p>这 2 种做法还使您的应用程序更具可移植性,因为它不依赖于包含路径等 ini 设置。
3。检查您的包含路径
另一种包含文件的方法,既不是相对也不是纯粹绝对,是依赖 包含路径。对于诸如 Zend 框架之类的库或框架来说,通常就是这种情况。
这样的包含将如下所示:
在这种情况下,您需要确保“Zend”所在的文件夹是包含路径的一部分。
您可以使用以下命令检查包含路径:
您可以使用以下命令向其中添加文件夹:
4。检查您的服务器是否有权访问该文件
总而言之,运行服务器进程(Apache 或 PHP)的用户可能根本没有读取或写入该文件的权限。
要检查服务器正在哪个用户下运行,您可以使用 posix_getpwuid:
要查找文件的权限,请在终端中键入以下命令:
并查看权限符号表示法
5。检查 PHP 设置
如果以上方法均不起作用,则问题可能是某些 PHP 设置禁止它访问该文件。
三个设置可能相关:
phpinfo()
进行检查> 或使用ini_get("open_basedir")
ini_get("allow_url_include")
检查并使用ini_set("allow_url_include", "1")
设置极端情况
如果上述方法均无法诊断问题,则可能会发生以下一些特殊情况:
1。依赖包含路径的库的包含
您可能会使用相对或绝对路径包含一个库,例如 Zend 框架。例如:
但是你仍然会遇到同样类型的错误。
发生这种情况的原因是您(成功)包含的文件本身具有另一个文件的包含语句,而第二个包含语句假定您已将该库的路径添加到包含路径中。
例如,前面提到的 Zend 框架文件可能包含以下内容:
既不是通过相对路径包含,也不是通过绝对路径包含。假设Zend框架目录已添加到包含路径中。
在这种情况下,唯一实用的解决方案是将目录添加到包含路径中。
2。 SELinux
如果您运行的是安全增强型 Linux,那么这可能是问题的原因,因为拒绝从服务器访问该文件。
要检查系统上是否启用了 SELinux,请在终端中运行
sestatus
命令。如果该命令不存在,则说明您的系统上不存在 SELinux。如果它确实存在,那么它应该告诉您它是否被强制执行。要检查 SELinux 策略是否是问题的原因,您可以尝试暂时将其关闭。但要小心,因为这将完全禁用保护。不要在生产服务器上执行此操作。
如果您在关闭 SELinux 后不再遇到问题,那么这就是根本原因。
要解决这个问题,您必须相应地配置 SELinux。
以下上下文类型是必需的:
httpd_sys_content_t
用于您希望服务器能够读取的文件httpd_sys_rw_content_t
用于您想要读写访问权限的文件httpd_log_t
用于日志文件httpd_cache_t
用于缓存目录例如,要将
httpd_sys_content_t
上下文类型分配给您的网站根目录,请运行:如果您的文件位于主目录中,您还需要打开
httpd_enable_homedirs
布尔值:无论如何,SELinux 拒绝访问文件的原因可能有多种,具体取决于您的策略。所以你需要对此进行调查。 此处 是专门为 Web 服务器配置 SELinux 的教程。
3。交响乐
如果您使用 Symfony,并且在上传到服务器时遇到此错误,则可能是应用的缓存尚未重置,因为
app/cache
已上传,或者该缓存尚未清除。您可以通过运行以下控制台命令来测试并修复此问题:
4。 Zip 文件中的非 ACSII 字符
显然,当 zip 中的某些文件的文件名中包含非 ASCII 字符(例如“é”)时,调用
zip->close()
时也会发生此错误。一个可能的解决方案是在创建目标文件之前将文件名包装在
utf8_decode()
中。感谢 Fran Cano 确定了此问题并提出了解决方案