本番サイトで、寄稿者権限のコンテンツライターさんに記事を直接下書き納品してもらう事があります。
その時、メディアのアップロードが出来ないと連絡をいただきました。
運営者として自分でコンテンツを追加する時は、ローカル開発環境のVCCWで問題が無かった為に気付いていませんでした。
本番サイトの環境はKUSANAGIです。開発環境と本番環境でステージング環境を整える必要が有りますが、Vitualbox/Vagrantの場合、残念ながらパーミッションの再現性を開発環境と本番環境で等しく出来ないです。
この記事は、VPSのconoha KUSANAGI Nginx php-fpmの本番環境にwindowsパソコンでFileZillaやTeraTermを使ってssh接続した例で説明しています。
※サーバーによってディレクトリ構造が異なる場合がありますが、Linuxを採用しているレンタル共有サーバー等であれば参考にしていただくことが出来ます。
※Windowsのフォルダは、概ねLinuxでディレクトリと言われます。
本番サイトでワードプレスのメディアに画像ファイルをアップロードしようとしたら出来ない!
という時、下記の様なメッセージがダッシュボード画面の下部に出てくることがある思います。
ディレクトリ wp-content/uploads/2016/10 を作成できませんでした。この親ディレクトリのアクセス権はサーバーによる書き込みを許可していますか ?
英語の場合
Unable to create directory wp-content/uploads/2016/10. Is its parent directory writable by the server?
ワードプレスでは比較的に起こりやすい問題ではないでしょうか。
パーミッションとは?
UNIX 系の OS で、ディレクトリやファイルに対する アカウント ごとのアクセス権のことをいいます。他の系列のOSにも同様のアクセス権が設定できるものもありますが、パーミッションと呼ぶ場合は一般にUNIX系のOSに限られます。
⇒お便利サーバー.comより引用。やや強引ですがLinux≒UNIXと考えてください。
手元のパソコンがwindowsの方は、FileZilla等でパーミッション操作が可能なLinuxユーザーでLinuxのサーバーに接続を行ってください。
そして、
/home/kusanagi/任意のプロファイル・ディレクトリ名/DocumentRoot/wp-content/uploads
のuploadsの上で右クリック⇒「ファイルの属性」をクリックします。
上記の様な「ファイルの属性を変更」の小さなウィンドウが出てきたら、①の様にパーミッション数値を755に変えます。
②「サブディレクトリの中の再帰」にチェックを付けて、「すべてのファイルとディレクトリに適用」にもチェックを入れます。
最後に「OK」をクリックしてください。
ポイントは「再帰的(さいきてき)」です。upoloadsディレクトリの中にある全てのファイルとディレクトリの権限を755に変えるという事になります。
再帰的を指定しないとuploadsディレクトリだけ755になり、ディレクトリ内のものがすべてパーミッション変更されません。
uploads/2016/10など、ディレクトリが深層まであるので、再帰的にパーミッションを設定してください。
メディアのアップロードだけの問題なのに、wp-contentでパーミッション変更をする事はやめましょう。
セキュリティリスクが無駄に増えます。
パーミッション制限範囲の緩和は最小限に抑える事がセキュリティの基本です。
FileZillaを使わない場合、TeraTermやCygwin等で本番環境に接続して、nginxの動作ユーザーでコマンド操作していることを確認して以下のコマンドを使います。
//wp-contentまで移動 cd /home/kusanagi/任意のプロファイル・ディレクトリ名/DocumentRoot/wp-content/ //wp-contentデイレクトリ内にuploadsディレクトリが存在しているか&パーミッション状態確認 ls -al //再帰的にuploadsデイレクトリ内全部を0755に変える chmod -R 755 uploads
windows serverのIISやLinuxのubuntuでもユーザーやパーミッションの設定状態により同じ問題が起こる様です。
ubuntuは詳しくわかりませんが、IISの場合、windowsのGUI操作でコマンド無しで簡単にパーミッション設定を出来た記憶があります。
画像の容量を増減しながらアップロードを試してみてください。
1KB(キロバイト)=1024バイト
1MB(メガバイト)=1024KB
1GB(ギガバイト)=1024MB
1TB(テラバイト)=1024GB
//php.iniファイルのあるディレクトリに移動 cd /etc //php.iniを見る(確認コマンドです。書き換えてしまう事は無いので、思い切ってコマンドしてください) cat php.ini //php.iniファイルでファイル容量制限の数値を修正 vim立ち上げ vi php.ini //vimを開いたらノーマルモードから編集用のインサートモードに切り替える i //該当箇所を次のように修正、修正が終わったらESCを押してノーマルモードに戻る memory_limit = 256M//メモリ使用量上限 post_max_size = 256M//POSTデータの最大アップロードサイズ upload_max_filesize = 256M//1ファイルあたりの最大アップロードサイズ //ノーマルモードにしたらvimをセーブして終了 :wq //php-fpm KUSANAGI再起動 kusanagi restart //php-fpm再起動(KUSANAGIではない場合、必要に応じて) sudo service php-fpm restart//php5-fpmとphp7.0-fpmなどを使い分けてください。 //nginx再起動(KUSANAGIではない場合、必要に応じて) sudo service nginx restart
レンタル共有サーバーの場合、php.iniファイルの設定はサーバーコントロールパネルなどの中から行う為、vimやコマンド操作の必要が無い場合もあります。
//conf.dのディレクトリに移動 cd /etc/nginx/conf.d //再帰的に該当ソースコードの有無と行数を拡張子.confのファイルだけ確認 grep -rn client_max_body_size *.conf
ご参考としてKUSANAGIのデフォルトは16メガバイトです。
//vimを立ち上げファイルを編集する vi default.conf //書き方 example.conf: client_max_body_size 16M; //vimで修正したらセーブして終了 :wq
上記の設定ファイルで数値の書き換えで対応します。
プログラムファイルの所有者が、プログラム内の関数によって処理されているファイル及びディレクトリの所有者と同一かの確認を行う設定をします。
⇒Xサーバーより引用
//php.iniファイルのあるディレクトリに移動 cd /etc //php.iniを見る(確認コマンドです。書き換えてしまう事は無いので、思い切ってコマンドしてください) cat php.ini //php.iniファイルでファイル容量制限の数値を修正 vim立ち上げ vi php.ini //vimを開いたらノーマルモードから編集用のインサートモードに切り替える i //該当箇所を次のように修正、修正が終わったらESCを押してノーマルモードに戻る safe_mode = Off //ノーマルモードにしたらvimをセーブして終了 :wq //php-fpm KUSANAGI再起動 kusanagi restart //php-fpm再起動(KUSANAGIではない場合、必要に応じて) sudo service php-fpm restart//php5-fpmとphp7.0-fpmなどを使い分けてください。 //nginx再起動(KUSANAGIではない場合、必要に応じて) sudo service nginx restart
ワードプレスでメディアのアップロードが出来ない場合、多くの原因が考えられます。
ワードプレス本体/テーマ/プラグイン/サーバー(apacheやnginx)/phpなど、多種多様です。
メディアのエラーメッセージは、ダッシュボードで「設定」⇒「一般」⇒「サイトの言語」で日本語と英語に変更できます。
「表示される英語のエラーメッセージ」と「どこまで自分で検証したのか」を正しく専門業者に伝える事で解決までの時間が速くなります。
別種類ブラウザのシークレットウィンドウを使ってメディアにアップロードしてみてください。