PHP - ストリームを開けません: そのようなファイルまたはディレクトリはありません

Question

PHP スクリプトでは、include()、require()、fopen()、または include_once、require_once、move_uploaded_file() などの派生クラスを呼び出すかどうかにかかわらず、次のようなエラーまたは警告が頻繁に発生します: ストリームを開けません: そのようなファイルはありませんまたはディレクトリ。問題の根本原因を迅速に見つけるための適切なプロセスは何ですか?

P粉362071992 · Answer

(非常に良い)既存の回答に追加

共有ホスティングソフトウェア

open_basedir は Web サーバー構成で指定できるため、戸惑うかもしれません。これは独自の専用サーバーを実行すれば簡単に解決できますが、ドメインごとに設定ディレクティブを許可する共有ホスティングパッケージ (Plesk、cPanel など) があります。ソフトウェアは構成ファイル (httpd.conf) を構築するため、ホスティングソフトウェアは再起動時にこのファイルを上書きするだけなので、このファイルを直接変更することはできません。

Plesk では、提供された httpd.conf (vhost.conf と呼ばれる) をオーバーライドする場所が提供されます。サーバー管理者のみがこのファイルに書き込むことができます。 Apacheの設定はこんな感じです

リーリー

サーバー管理者に依頼して、使用しているホスティングソフトウェアおよび Web サーバーソフトウェアのマニュアルを参照してください。

ファイル権限

Web サーバー経由でのファイルの実行は、コマンドラインや cron ジョブの実行とは大きく異なることに注意することが重要です。最大の違いは、Web サーバーに独自のユーザーと権限があることです。このユーザーはセキュリティ上の理由から厳しく制限されています。たとえば、Apache は通常、apache、www-data、または httpd (サーバーによって異なります) です。 cron ジョブまたは CLI の実行には、それを実行しているユーザーが持つあらゆる権限が与えられます (つまり、root として実行される PHP スクリプトは root 権限で実行されます)。

多くの場合、次の方法で権限の問題を解決します (Linux の例)

リーリー

ファイルまたはディレクトリは誰でも書き込み可能になったため、これは賢明なアイデアではありません。あなたがサーバーを所有しており、唯一のユーザーである場合、これは大した問題ではありませんが、共有ホスティング環境にいる場合は、サーバー上の全員にアクセスを許可することになります。

アクセスが必要なユーザーを特定し、そのユーザーにのみアクセスを許可する必要があります。どのユーザーがアクセスを必要としているのかがわかったら、次のことを確認する必要があります。

このユーザーはファイル
を所有しており、親ディレクトリ (特にファイルに書き込む場合は親ディレクトリ) を所有している可能性があります。ほとんどの共有ホスティング環境では、ユーザーがルートディレクトリ内のすべてのファイルを所有する必要があるため、これは問題になりません。 Linux の例を以下に示しますリーリー
このユーザー (およびこのユーザーのみ) にはアクセス権があります。 Linux では、
chmod 600 (所有者のみが読み書きできる) または chmod 644 (所有者は書き込みできるが、全員が読み取れる) が推奨されます。

Linux/Unix の権限とユーザーに関する広範な説明は、

ここで読むことができます

P粉268654873 · Answer

このエラーが発生する理由は多数考えられるため、最初に何を確認するかについての適切なチェックリストが役に立ちます。

次の行のトラブルシューティングを行っていると仮定します:

リーリー

＃＃＃リスト＃＃＃

＃＃＃１。ファイルパスにタイプミスがないか確認してください

手動検査 (経路を目視検査する)

または、
または
include* の呼び出しを独自の変数に移動し、エコーし、コピーして、次の方法でアクセスしてみます。 リーリー 次に、ターミナルで次のようにします: ああああ

＃＃＃２。相対パスと絶対パスを考慮したファイルパスが正しいか確認してください

スラッシュ「/」で始まる場合は、Web サイトフォルダーのルート (ドキュメントルート) ではなく、サーバーのルートを指します。

たとえば、Web サイトのディレクトリは

- スラッシュで始まらない場合は、インクルードパス (以下を参照) に依存しているか、パスが相対パスであるかのいずれかです。相対パスの場合、PHP は
を計算します。
つまり、Web サイトのルートへのパスや入力しているファイルへのパスとは何の関係もありません。
したがって、常に絶対ファイルパスを使用してください
- 実行時に絶対パスを生成しながら、コンテンツを移動するときにスクリプトを堅牢にするために、2 つのオプションがあります:

。

#__DIR__

マジック定数

現在のファイルのディレクトリを返します。

SITE_ROOT定数を定義します: Web サイトディレクトリのルートディレクトリに config.php
などのファイルを作成します。
config.php
に
- サイトのルートフォルダーを参照するすべてのファイルに、
- を含め、任意の場所で
  SITE_ROOT定数を使用します。ああああ
- これら 2 つの実践により、インクルードパスなどの ini 設定に依存しないため、アプリケーションの移植性も高まります。＃＃＃３。インクルードパスを確認してください p>
include パス

このようなインクルードは次のようになります:

リーリー

この場合、「Zend」が存在するフォルダーがインクルードパスの一部であることを確認する必要があります。

次のコマンドを使用してインクルードパスを確認できます:

リーリー

次のコマンドを使用してフォルダーを追加できます:

リーリー

＃＃＃４。サーバーがファイルにアクセスできるかどうかを確認してください

要約すると、サーバープロセス (Apache または PHP) を実行しているユーザーには、ファイルの読み取りまたは書き込みの権限がまったくない可能性があります。

サーバーがどのユーザーで実行されているかを確認するには、

posix_getpwuid

を使用できます:

リーリー

ファイルの権限を確認するには、ターミナルに次のコマンドを入力します。

リーリー

and view権限表記

＃＃＃５。 PHP設定を確認してください

上記の方法がいずれも機能しない場合は、一部の PHP 設定によりファイルにアクセスできないことが問題である可能性があります。

3 つの設定が関連する可能性があります:

open_basedir
- phpinfo() を呼び出すか、进行检查>ini_get("open_basedir")を使用できます。php.ini ファイルまたは httpd.conf ファイルを編集して設定を変更できます。
- ＃＃＃＃＃＃セーフモード＃＃＃
この機能が有効になっている場合、制限がある可能性があります。ただし、これは PHP 5.4 では削除されました。セーフモードをサポートするバージョンをまだ使用している場合は、
バージョンの PHP にアップグレードしてください。
- allow_url_fopen およびallow_url_include
これは、ネットワークプロセス (例: http://) 経由でファイルをインクルードするか開く場合にのみ機能し、ローカルファイルシステムにファイルをインクルードしようとする場合には機能しません
ini_get("allow_url_include") を使用できます。ini_set("allow_url_include", "1")
- 設定します。

＃＃＃１。インクルードパスに依存するライブラリのインクルード

相対パスまたは絶対パスを使用して、Zend Framework などのライブラリを含めることができます。例えば：＃＃＃リーリー

しかし、依然として同じ種類のエラーが発生する可能性があります。

これは、(正常に) インクルードしたファイル自体に別のファイルからの include ステートメントが含まれており、2 番目の include ステートメントでは、ライブラリへのパスがインクルードパスに追加されていると想定されているために発生します。

たとえば、前述の Zend フレームワークファイルには次のものが含まれる可能性があります:

リーリー

相対パス経由でも絶対パス経由でも含まれません。 Zend フレームワークディレクトリがインクルードパスに追加されていることが前提となっています。

この場合、唯一の現実的な解決策は、ディレクトリをインクルードパスに追加することです。

＃＃＃２。 SELinux

セキュリティが強化された Linux を実行している場合は、サーバーからのファイルへのアクセスが拒否されるため、これが問題の原因である可能性があります。

SELinux

がシステムで有効になっているかどうかを確認するには、ターミナルで

sestatus
コマンドを実行します。このコマンドが存在しない場合、SELinux はシステムに存在しません。存在する場合は、それが強制されているかどうかが示されるはずです。

SELinux ポリシーが問題の原因であるかどうかを確認するには、

SELinux ポリシーを一時的にオフにしてみてください。ただし、これを行うと保護が完全に無効になるので注意してください。運用サーバーではこれを行わないでください。

リーリー

SELinux をオフにした後で問題が発生しなくなった場合、これが根本原因です。 この問題を解決するには、それに応じて SELinux を構成する必要があります。

次のコンテキストタイプが必要です:

httpd_sys_content_t サーバーに読み取れるようにするファイルの場合

httpd_sys_rw_content_t 読み取りおよび書き込みアクセスが必要なファイルの場合

httpd_log_t ログファイルの場合

httpd_cache_t キャッシュディレクトリに使用されます

たとえば、httpd_sys_content_t コンテキストタイプを Web サイトのルートに割り当てるには、次のコマンドを実行します。リーリー
ファイルがホームディレクトリにある場合は、
httpd_enable_homedirs ブール値: もオンにする必要があります。リーリー
いずれにしても、ポリシーによっては、SELinux がファイルへのアクセスを拒否する理由がいくつか考えられます。したがって、これを調査する必要があります。
こちらは、Webサーバー用のSELinuxの構成に特化したチュートリアルです。

＃＃＃３。交響曲＃＃＃
Symfony を使用していて、サーバーにアップロードするときにこのエラーが発生した場合は、
app/cache
がアップロードされたためにアプリのキャッシュがリセットされていないか、キャッシュがリセットされていない可能性があります。クリアされました。
次のコンソールコマンドを実行すると、この問題をテストして修正できます: リーリー

＃＃＃４。 Zip ファイル内の非 ACSII 文字

どうやら、このエラーは、zip 内の一部のファイルのファイル名に非 ASCII 文字 (例: "é") が含まれている場合に
zip->close()
を呼び出したときにも発生する可能性があります。

考えられる解決策は、ターゲットファイルを作成する前にファイル名を utf8_decode() でラップすることです。

この問題を特定し、解決策を提案してくれた Fran Cano
に感謝します