Ver.6.3でもダメ
最近，Version 6.3が出たので，WordPress 6.1.3から6.3に更新してみました．でも，同じように，同様の項目と数のWarnning を吐いて，そのまま沈黙して終了となりました．そこで少しググって，親のフォルダの権限に，「http」のRead権限を設定して，もう一度，Version 6.3で更新してみました．
その結果，以下のWarnningを吐き沈黙しましたが，今回のWarnningの数は著しく少なくなりました．173行目のfilesystem関連のWarnningは出なくなりました．(実は，もう少し追加の設定が必要なのですが，それは，以下に完結しているので，もう少し読んでみてください)
試行錯誤でのその他エラー
試行錯誤してからWordPressの更新をする場合，以下のように表示が出て先に進まない時があります．その場合，データベースにインストールのイベント情報が入力されているため，WordPressのシステムファイルの復元では改善できません．15分間待つしかないようです*2．
WordPress を更新 別の更新が現在進行中です。
*2, WordPress「別の更新が現在進行中です」エラーの解決方法
https://kinsta.com/jp/knowledgebase/wordpress-another-update-is-currently-in-progress/
結局
wordperssのupdateを可能にするには，結局，親フォルダでる”Web”へのアクセス権限として，”http”をオーナーを”Full Control: フルコントロール”に設定することで，無事にWordPress 6.3-jpで更新することが出来ました．
- 設定対象 : 親フォルダ”Web”
- “オーナ” また “http”による”フルコントロール: 管理・読取・書込”権限を設定した (一般的なLinuxのフルコントロールとは，rwxのうちx(実行)が無いため異なると考えられる)
- 設定は，FileStationからフォルダのプロパティを開いて行う
やっぱり，”ホームNW研究所”の観音寺さん*3には，いつも助けられてばかりです．この場を借りて感謝します^^)．
*3,WordPressの更新に失敗した時の対策
– ホームNW研究所 –webを”フルコントロール: 管理・読取・書込”に設定する．
https://nw.myds.me/synology/wordpress5-5-update/
その後
WordPressのUpdateはできたものの，その後，WordPressにログイン(SiteGuardプラグインから)しようとしたら，その機能てである「ひらがな」のCAPTCHAが表示されなくなっており，ログインができなくなっていたことに気づいた．
調べてみると，以下のリンクに解決方法があったので，それをヒントに以下を適用した．
気になる点は，httpのパーミッションがReadのみになっていたフォルダがあったこと．もしかすると，wordpressのUpdateの後処理として処理されている可能性も否定できない．
- FileStationから
- webフォルダのパーミッションについて
- httpを「read, write」をチェックした．
(この設定は，おそらく，(所有者 – http – その他)において所有者はhttpと考えられるため (6-0-0)と考えることができる．「そもそもパーミッション設定値は」の項で述べた，600に設定されているものと思われる．要は，所有者以外がアクセスできないと理解すれば納得がゆく． - ついでに，httpsにも「read, write」をチェックした．
ワードプレス SiteGuard 画像表示されない
wpcontent -> plunins -> siteguard -> really-simple-captcha」のパーミッションを「777」にする
https://server-recipe.com/1880/
結局の設定値
色々作業して混乱してしまったため，どれをどの順序で実施したのかはもう夢のかなたに行ってしましたが，現状では，以下のことが可能となっている．
- 試行錯誤の結果，wordpressのupdateが可能なままなのかは不明となってしまった．今後，wordpressのupdateの際に確認したい．
- SiteGuardによるログインは可能
- Plaginのupdateは可能
まとめ
自前のサーバーにWordPressを置いている場合，特にSynology NASを使用している場合での，WordPressの復元について，実際に生じた問題解決に迫られて実施した内容を解説しました．
WordPressのバックアップにはデータベース(MariaDB 10)とシステムファイル群(PHP)の二種類が必要ですが，今回は，システムファイル群の復元について取り上げました．
2018年からSynology NASにWordPressを設置してblogを行ってきましたが，システムファイル(PHP)絡みによるWordPressのダウンを何度か経験しました．
PHPの復元については，Synology NASの場合，SnapShot Replicatonを使えば簡単に復元が可能です．ここでは，取り上げなかったデータベース(MariaDB 10)の復元についても，Hyper Backupを用いれば可能です．このことは，WordPressのバックアップには，プラグインを使用する必要はなく，NASの機能を使ってシンプルにWordPressを管理することが可能であることを意味します．
WordPressに負担を掛けずに管理する，すなわち，NASに備わった機能を用いて管理するのは，エコだと思います．
不具合のあったWordPressの更新バージョンはそっとしておいて，6.2.x (x.xx)がでるまでおとなしく待ち，6.3で更新をしてみましたが，結果は，同様にWarnningを吐いて完全停止になりました．
バックアップの必要性は，結局問題が生じたときの備えです．今回は，関連フォルダのパーミッション不正によりwordpressのupdateが実行不可となったことで，その必要性を再認識しました．
話題は転じて，WordPressの親フォルダのぱーミッションの設定に関しては，以下の経緯をたどりました．
試行錯誤として，最初に「http」にRead(読取)権限を付与しました．その結果，数百に上る多数の173行のエラーはなくなりました．でも，その先の309行目のエラーが1つ現れました．
更に，ググっていいくと「ホームNW研究所」に直接的な記事がありました．Webフォルダのパーミッションを ”フルコントロール: 管理・読取・書込”に設定するとwordpressのupdateはすんなり実行できました．
そのご，しばらくしてwordpressにログインしようとした時，セキュリティの向上としてSiteGuardというプラグインを使用してCAPTCHAを表示させるようにしていましたが，そのCAPTCHAが表示されなくなっていました．
結局は，httdのパーミッションがreadのみになっていたことが原因と結論しました．httdをreadとwriteにチェックを入れると，SiteGuardは正常に機能するようになりました．
この設定により，最初にwordpressのupdateを可能にできたhttdの設定であるフル設定”フルコントロール: 管理・読取・書込”になっていません．今後，wordpressのバージョンアップがありupdateが必要な時には，この設定のままでupdateをしてみようと思います．
試行錯誤はまだまだ続く–)