Xserver で Nextcloud アップデートのエラーと警告に対処2

Xserverで運用しているNextcloudをアップデートする際のエラー防止と警告の対処を行います。v29.0.1版。

nextcloud の管理ページにたまに訪れると、更新のお知らせが載っていて、目に入ると気分が沈みます。

気が沈む理由は、更新の度に面倒でややこしいエラーや警告の対処が必要だからです。nextcloud は設定を記憶してくれないので毎回全てやり直す羽目になり、うんざりします。もちろん筆者自身も何をどうするのかいちいち記憶していませんから、その都度検索とテストにめっちゃ時間かかって身も心もボロボロになります。

以前、自分用にエラー対処のページを作っていましたが改めて最新版として、実際にアップデートをしながら書き綴ります。将来、この投稿を見ながらアップデートできるようやはり自分のためにそうするのです。でも自分のためはひとのため、似た境遇の人の役に立つかもしれません。わからんけど。境遇は以下です。

レンタルサーバーの Xserver で nextcloud を運用しています
ここの筆者はデータベースを触る器量がまったくない素人の雑魚です

Nextcloud の更新

Webの管理画面から更新していきましょう。その前に、FTPソフトを起動させておきます。ぱぱっとファイルにアクセスして編集できるように準備しておくんです。

ではアップデートしていきます。

アップデーターを開くをクリックすると、更新のタイムテーブルみたいな画面が出てきて、これから行われることを知らせてくれます。

Check for expected files のエラー

Start update をクリックするだけでいきなりエラー。エラー出んの早すぎやろ。

予期されるファイルを確認する次の追加ファイルが見つかりました — 「予期されるファイルを確認する. 次の追加ファイルが見つかりました」

予期されるファイルを確認したんですね。見つかって良かったですね。で？

ファイルを捨てます

結論を言うと、これらはnextcloudフォルダの最初の階層にあるファイルです。リストされたファイルを選んで捨てます。捨てるんかいっ。

予期されたファイルがリストされましたと言われて、それを捨てるなんて超人でない限り思いつきもしません。でも捨ててから同ページを再読み込みすると更新が再開されます。

治りました。

するすると順調に進み、残すところあと1個。そのあとは Done が控えているだけで、完了間近です。

Continue with web based updater

「Disable maintenance mode and continue in the web based update」をクリックしたらエラー出ます。

Maintenance mode will get disabled.
Parsing response failed.

メンテナンスモードが無効になります。
応答の解析に失敗しました。

config.php を編集

メンテモードがどうのこうのと言ってるので、nextcloudフォルダ以下 /config/config.php を開いて編集しましょう。’maintenance’ を見つけます。

'maintenance' => true,

true になっていれば、メンテモードなので false に変えます。

'maintenance' => false,

これでOK。の筈です。だめですか。

Xserver では盛大に500エラーが出るかもしれません。

Xserver の 500エラー

nextcloud 階層の .htaccess を編集

nextcloud のフォルダを開いた階層にある .htaccess を確認します。

<IfModule pagespeed_module>
 ModPagespeed Off
</IfModule>

“ModPagespeed Off” の頭に # が付いていなければ付けてコメントアウトします。

<IfModule pagespeed_module>
# ModPagespeed Off
</IfModule>

もしこの記述自体がなければ追加します。

先ほどエラーになっていたWebページをリロードすればアップデーターが再度動き出すと思います。もしまだ何らかのエラーが出るなら、次を試すのはどうでしょう。

その他

nextcloud ディレクトリのアクセス権

750 に変えてみるとか … どうなんでしょ。ただのおまじない？

設定ファイルの memory_limit を確認

ルートにある user.ini を確認し、”memory_limit”をチェック。この数値が小さいままだと上手く動かないようです。

memory_limit = 1G

user.ini じゃなく、サーバー管理ページから設定もできます。

updataフォルダを捨ててやり直す

nextcloud ディレクトリ/data に「updater- 」で始まるフォルダがあると思います。これをフォルダごと捨てます。そしてアップデータのページをリロードして再開します。この方法、結構効きます。

アップデータが再び動き出し、今度こそ完了することでしょう。完了したらnextcloudのトップページにリダイレクトされ、ダッシュボードページが開・・・

すいません。これは化石環境の Safari だからでした。Google Chrome で開き直しましょう。開いて、ログインできました。アップデートはこうして上手く完了しました。

でもまだあります。悪名高いセキュリティ＆セットアップ警告です。

セキュリティ＆セットアップ警告

以前の投稿でもこのエラーについていくつか書いてるけどまた書きます。内容被りますがご容赦願います。解決できないことだらけだったことを最初にご報告しておきます。

いくつかのファイルは整合性チェックに合格していません。

赤い文字で「整合性がない」と叱られておりますが、これはnextcloud直下の .htaccess を弄ったからです。ですのでこれは消せません。

放置

Your web server is not properly set up to resolve

Your web server is not properly set up to resolve

`.well-known` URLs, failed on: `/.well-known/webfinger`

「Web サーバーは `.well-known` URL を解決するように適切に設定されていません。次のエラーが発生しました: `/.well-known/webfinger`」

ルートの .htaccess を編集する（未解決）

これは以前は次のように表示されていたやつですね。

Webサーバーで “/.well-known/webfinger” が解決されるように正しく設定されていません。
Webサーバーで “/.well-known/nodeinfo” が解決されるように正しく設定されていません。
Webサーバーで “/.well-known/caldav” が解決されるように正しく設定されていません。
Webサーバーで “/.well-known/carddav” が解決されるように正しく設定されていません。

ドキュメントによると、ルートの .htaccess （nextcloudフォルダではなく）に次を追加すれば良いとのことです。

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteRule ^\.well-known/carddav /nextcloud/remote.php/dav [R=301,L]
  RewriteRule ^\.well-known/caldav /nextcloud/remote.php/dav [R=301,L]
  RewriteRule ^\.well-known/webfinger /nextcloud/index.php/.well-known/webfinger [R=301,L]
  RewriteRule ^\.well-known/nodeinfo /nextcloud/index.php/.well-known/nodeinfo [R=301,L]
</IfModule>

さっそくこの通りに追加してみたところ、何の効果もありません。

ネットをうろつき、賢い先生たちの情報を漁りますと、先生方それぞれが似たコードを掲載しておられます。片っ端からコピペで試します。

では最初の先生が提案する記述です。

<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteRule ^\.well-known/host-meta /nextcloud/public.php?service=host-meta [QSA,L]
 RewriteRule ^\.well-known/host-meta\.json /nextcloud/public.php?service=host-meta-json [QSA,L]
 RewriteRule ^\.well-known/webfinger /nextcloud/index.php%{REQUEST_URI} [R=301,L]
 RewriteRule ^\.well-known/nodeinfo /nextcloud/index.php%{REQUEST_URI} [R=301,L]
 RewriteRule ^\.well-known/carddav /nextcloud/remote.php/dav/ [R=301,L]
 RewriteRule ^\.well-known/caldav /nextcloud/remote.php/dav/ [R=301,L]
</IfModule>

Nextcloudの警告を解決してみた – ツインターボのブログ

一時期はこれで解決していましたが、いつの頃からか効き目がなくなりました。

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule ^/\.well-known/host-meta /nextcloud/public.php?service=host-meta [QSA,L]
RewriteRule ^/\.well-known/host-meta\.json /nextcloud/public.php?service=host-meta-json [QSA,L]
RewriteRule ^/\.well-known/webfinger /nextcloud/index.php%{REQUEST_URI} [R=301,L]
RewriteRule ^/\.well-known/nodeinfo /nextcloud/index.php%{REQUEST_URI} [R=301,L]
RewriteRule ^/\.well-known/carddav /nextcloud/remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/caldav /nextcloud/remote.php/dav/ [R=301,L]
</IfModule>

次に、https://www.surlofia.com/nextcloud-web-server-is-not-properly-set-up-to-resolve/ の先生に従いました。

<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteRule ^/\.well-known/carddav /nextcloud/remote.php/dav [R=301,L]
 RewriteRule ^/\.well-known/caldav /nextcloud/remote.php/dav [R=301,L]
 RewriteRule ^/\.well-known/webfinger /nextcloud/index.php/.well-known/webfinger [R=301,L]
 RewriteRule ^/\.well-known/nodeinfo /nextcloud/index.php/.well-known/nodeinfo [R=301,L]
</IfModule>

やはりエラーは消えませんでした。同じ先生のもう一つの提案がありました。

<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteRule ^/\.well-known/carddav /nextcloud/remote.php/dav [R=301,L]
 RewriteRule ^/\.well-known/caldav /nextcloud/remote.php/dav [R=301,L]
 RewriteRule ^/\.well-known/webfinger /nextcloud/index.php%{REQUEST_URI} [R=301,L]
 RewriteRule ^/\.well-known/nodeinfo /nextcloud/index.php%{REQUEST_URI} [R=301,L]
</IfModule>

すべて撃沈。解決できませんでした。

以前は正解があってエラーが消えたのですが、今は駄目みたいです。

未解決

ログには 20XX年XX月XX日 XX:XX:XX 以降、エラーが 1 件あります。

ログにエラーが1件あるそうです。はい。そうですか。わかりました。何とかします。

このエラーが数千件に及ぶこともあります。以前ありました。ログを見ると、”mbstring” 絡みであることが多かったんです。PHP8で非推奨だったものが禁止になったせいですね。これは、user.ini を編集して対処します。該当箇所の先頭に ; を付けてコメントアウトします。

;mbstring.internal_encoding = 
;mbstring.http_input =
;mbstring.http_output =

対処していたはずなのですが、サーバー管理のPHP設定から ini を編集すると、この古い項目が勝手に復活するんです。

サーバーにはメンテナンスウィンドウの開始時間が設定されていません。

サーバーにはメンテナンスウィンドウの開始時間が設定されていません。

これは、リソースを多く使用する日常のバックグラウンドジョブが、メインの利用時間中にも実行されることを意味します。利用者がこれらの重いタスクによる負荷の影響を受けにくくするために、低い利用時間に設定することをおすすめします。

ドキュメントによると、cronジョブという処理の指定をしておけということらしいです。

config/config.ini を編集

nextcloud の /config/config.ini を開いて、maintenance_window_start を探します。ドキュメントのお手本通り記載してみましょう。

'maintenance_window_start' => 1,

治りました。

Strict-Transport-Security “HTTP ヘッダーの秒数が少なくとも 15552000” に設定されていません。

毎度お馴染み15552000です。

nextcloud直下の .htaccsess を編集

nextcloudフォルダ直下の .htaccess を開いて以下を追加します。

<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
<IfModule mod_setenvif.c>

治りました。

データベースにいくつかのインデックスがありません。

データベースにいくつかのインデックスがありません。

大きなテーブルにインデックスを追加すると、自動的に追加されないまでに時間がかかる可能性があるためです。 “occ db:add-missing-indices”を実行することによって、インスタンスが実行し続けている間にそれらの欠けているインデックスを手動で追加することができます。
オプションのインデックス “oc_npushhash_di” がテーブル “notifications_pushhash”にありません

phpMyAdmin で編集する

インデックスがないと指摘されたので作っていきたいと思います。phpMyAdminにアクセスしましょう。

notifications_pushhash というテーブルに、フィールド oc_npushhash_di がないとの指摘なので、notifications_pushhash を探しますが見当たらない。それもそのはず、oc_notifications_pushhash と、プレフィックスが要ります。変な省略すんなよ。

見つかったので展開してみましょう。

しかし酷い配色やな。それはともかく、oc_npushhash_di を インデックス で 新規作成 すれば良さそうです。

新規作成をクリックしてみたら賢い人用の画面に遷移しました。

インデックス名のところだけ oc_npushhash_di と入力して後は触らず【実行】してみました。

よし。確かにoc_npushhash_di が出来とる。

早速セキュリティ＆セットアップ警告ページをリロードしてみます。

治りました。

データベースがトランザクションファイルロックに使われています。

データベースがトランザクションファイルロックに使われています。
パフォーマンスをあげるには、可能であればメモリーのキャッシュを設定してください。

config.php を編集（効果なし）

ドキュメントによると、memcache とやらのインストールが必要とのことですが、レンタルサーバーではもちろんインストールなんてことは出来ませんので対処不能です。

でもどうやら memcache とはオブジェクトキャッシュのことのようです。Xserver なら APC と OPcache に対応しているのでインストール済みと理解していいんでしょうか。わかりませんが、もしそうなら、nextcloud の config.php に、以下の記述を追加しなさいとのことなので追加してみます。

  'memcache.locking' => '\OC\Memcache\Redis',
  'redis' => array(
     'host' => 'localhost',
     'port' => 6379,
     'timeout' => 0.0,
     'password' => '', // Optional, if not defined no password will be used.
      ),

何の効果もありません。

APC と OPcache は対応済みですが Redis というものは Xserver インストールされていないようです。ですので上記記述に意味ありません。

ちょっと聞きかじったことによると次の対処があります。

まず、user.ini に次を追記して APC を有効にします。

apc.enabled=1
apc.shm_size=32M

次に、nextcloud の /config/config.php に次を追記します。

'memcache.local' => '\\OC\\Memcache\\APCu',
'redis' => [
  'host' => 'localhost',
  'port' => 6379,
  'timeout' => 0.0, // Optional
  // 'password' => '', // If Redis server requires password
  // 'dbindex' => 0, // Optional
],

これで良いとのことで、わくわくしていましたが、警告は消えず、効果はなかったようです。

PHP OPcacheモジュールが正しく設定されていません。

PHP OPcacheモジュールが正しく設定されていません。OPcache のインターン化文字列バッファがほぼいっぱいです。繰り返しの文字列を効果的にキャッシュするために、PHPの設定に “opcache.interned_strings_buffer” を “96” よりも高い値で設定することをおすすめします。

ドキュメントによりますと、config.phpで設定をせよということのようです。が、これは nextcloud の config.php ではないようで、何のことだかわかりません。多分、レンタルサーバーのユーザーにはそのディレクトリを見ることすらできません。まぼろしですので対処できません。

一部情報ではPHPのバージョンが 8.1.2 なら自然に治るという話もあります。でも治りません。治ったらラッキーってことで、賢人様の知恵を待つ以外に現時点で為す術はありません。

また別の情報によりますと、user.ini の編集で良いとのことで、それやってみましょう。

user.ini に次を追記します。

; OPCacheのメモリ消費量の設定
opcache.memory_consumption=3072

; インターン化された文字列バッファの設定
opcache.interned_strings_buffer=96

「3072より大きい」「96より大きい」と言われたので、この数字では駄目かもしれません。何なら、より大きい数字を書きます。

結果は、ぜんぜん効果ありませんでした。警告は消えません。

対処不能

このインスタンスには、いくつかの推奨 PHP モジュールがありません。

このインスタンスには、いくつかの推奨 PHP モジュールがありません。
パフォーマンスと互換性を向上させるために、これらをインストールすることを強くお勧めします: – sodium パスワードハッシュ用の Argon2 詳細については、ドキュメントを参照してください。

以前のバージョンでは次のような文面でした。

“このインスタンスには、いくつかの推奨 PHP モジュールがありません。パフォーマンスと互換性を向上させるために、これらをインストールすることを強くお勧めします”

ドキュメントによりますと、PHPモジュールの話のようですが、レンタルサーバーのユーザーにはまったく関係のない話と了解していいんじゃないでしょうか。

対処不能

ということで、いくつかの警告に対処しようと試みましたが、多く撃沈しました。本日この投稿、張り切って実際にアップデートをやりながら書いてきましたが、惨憺たる結果になった模様です。

現状、これ以上検索しても無駄でした。気長に賢人様の登場を待ちます。

もしこの件に知見をお持ちで、私に教えを施しても良いと思われる方がおられましたらコメントなり電話なりして教えてください。よろしくお願いします。