Nextcloud を Xserver にインストールして使っていますがセキュリティ＆セットアップ警告というものが消えません。いくつか消しました。
Nextcloud をレンタルサーバーの Xserver にインストールして使っています。たまに不調もありつつ、まあまあ快適に使えています。
ただ、そこいらのクラウドサービスと違って自分でインストールした責任上、自分で面倒を見ないといけません。クライアントアプリを更新したり、たまにはサイトに接続してNextcloud をアップデートする必要があります。
忘れたころにWebに接続すると、アップデートがてんこ盛りにありまして、自動更新にも対応できないほどになっていました💦
仕方なく繰り返しアップデート作業を行い、やっとのことで最新版に更新できました。
レンタルサーバーで Nextcloud
Nextcloud について検索を行うと、ほぼすべて自分でサーバー管理を行っている人の情報しかヒットしません。警告やエラーの対処も、いきなり意味不明のコードが書かれていたりします。
そんで、そのコードをどこに書くのさ。と、謎ながらも、そもそも命令文の最初に大抵「sudo」が付いています。sudo というのは管理者権限で行う命令ですから、コードをどこにどう書くか以前に、レンタルサーバーで使用できるわけがありません。
ということで、大抵の謎は解けぬままですから、Nextcloud が吐いてくる警告に対処することを放棄しておりました。
でも極めて希にレンタルサーバーにインストールした人の情報もあります。そうした人を師と仰ぎ、参考にすることでいくつかには対処できました。
メンテナンスが終わらない
さて、Nextcloud 本体の更新作業中に注意することは、途中で出てくる選択肢です。メンテナンスモードにするかしないかを訊かれます。
うっかりメンテナンスモードを選んでしまうと、更新が終わっても解除されず、NexCloudにアクセスできなくなり大層焦ることになります。
まじどうにもならないので、FTPで Nextcloud フォルダにアクセスして、config フォルダ内の config.php を開き、メンテナンスモードを即刻辞めるよう指示を行います。
'maintenance' => true,
多分こうなったままなので
'maintenance' => false,
false に書き換えて保存します。
更新作業中にメンテナンスモードにして、更新が終わっても絶対に解除しないという強気の Nextcloud には、このように立ち向かいましょう。
セキュリティ＆セットアップ警告
NextCoud のWeb版にログインして訳のわからない画面から多彩な選択を駆使して管理の概要を見つけてクリックすると、何やらくるくるとテストを行い、
その後、警告をだーっと出します。
あまりにも多くの警告が出ますが、何のことか判らないので無視していました。でも気持ち悪いのでいくつかは手動で対処しました。対処できたものの記録を取ってないのでここに書けず、その続きですが、それでもまだ警告が山盛りあります。どんだけ警告好きやねん。
big intへの変換
「データベース内のいくつかの列で、big intへの変換が行われていません」というこの警告はデータベース絡みです。MySQLデータベースの phpMyAdmin にログインして対処します。phpMyAdminをブックマークしておらずURLもわからない場合はレンタルサーバーの管理パネルから行けます。
Xserver では MySQLが現時点で5.7です。Nextcloudのページによりますと、
Nextcloud 21 はMySQL バージョン “5.7.29”をサポートしなくなりました。MySQL 8 もしくはそれ以上のバージョンのものを使用してください。
とのことで、Xserver が今後5.7以上にアップしてくれるのかどうか気になりますが Nextcloud 20.0.8 ではまだ使えます。
「big int への変換」の警告以外に、以前はテーブルかテーブル内の何かがないという警告が沢山ありました。その警告は意味がわかりやすかったので phpMyAdmin から指定通り一個ずつ作成することで対処することが出来ました。
そのとき「big int への変換」警告は意味不明なので放置していましたが、よくよく落ち着いて見るとなんとなく何を言っているのかわかってきました。
上図の例で最初の行に書かれた「federated_reshares.share_id」があります。これ何ですか？さあ何でしょう。多分テーブルではないでしょうか。
テーブルを選んでタブから「構造」を選んで表示させると、share_id が見つかります。きっとこれを指していると思います。
警告文では「データベース内のいくつかの列で、big intへの変換が行われていません」と書かれていました。big int へ変換したいけどしていないんですって。
share_id の列を見れば右のほうに「変更」ボタンがあります。変換したいんだから変更でしょうよ、ということで何も考えず変更ボタンをクリックすると
変更が選べました。警告文が「big int」と言うのは「BIGINT」のことに相違ない。INT だったものを BIGINT に変更しました。多分でっかくなったんですね。
こんな調子で、警告からテーブルを見つけて該当の列をINTからBIGINTに変更していきます。ほんとにこれで合ってるんだろうか。
Nextcloudのページから再度「概要」を選び直すとまたくるくるとテストを行い、「big int への変換」警告が消えました。合ってました。
リバースプロキシヘッダーの設定
リバースプロキシヘッダーとやらの設定が正しくないか、あるいは信頼できるアクセスのようです。信頼できるならええやんかと思いますが、国語的に正しくないこの警告を消すにはリバースプロキシヘッダーの設定を正しく行えばいいのだそうです。でもそれどうやんの。
検索して見つけた先生によりますと、config を書けばいいそうです。これならできそうです。コマンドはわかりませんがFTPでフォルダにアクスすれば config フォルダ内に config.php がありますから書き換えます。と、思ったら書き換えるんじゃなくて、書き足します。
‘trusted_proxies’ という項目を作り、サーバーのIPアドレスを入力します。サーバーのIPアドレスを調べ、もしそれが「183.181.82.92」ならこう書きます。
'trusted_proxies' => '183.181.82.92',
これでリバースプロキシの警告は消えました。先生のおっしゃるとおりでした。
先生：https://yoshimemo.com/post-569/
この先生の記事がなければ、自分で解決することは天地がひっくり返っても不可能でした。
[追記]
時が流れ、この書き方ではエラーが消えないようになりました。新たな先生のおっしゃる通りに書き直しました。
'trusted_proxies' =>
array (
0 => '{サーバーのIPアドレス}',
),
新たな先生: https://twinturbo-power.com/2021/04/nextcloudの警告を解決してみた.html
nextcloudのマニュアルで「配列で書け」と書いてありましたのでこうなったのですね。
HTTPヘッダ15552000秒
オレンジ色の警告は「”Strict-Transport-Security”HTTPヘッダが最低でも”15552000″秒に設定されていません」と告げています。またもや気持ち悪い日本語にイラつきながらも、これも何とか対処できそうなので調べます。だいたいこの手のは php.ini とか .htaccsess とかの絡みであると想像できます。
しかし想像だけでは結局どうにもならず、検索してまわると役に立たない情報砂漠の中にひとつのありがたい解答を発見。あっ。また同じ先生やないか。
先生：https://yoshimemo.com/post-648/
この先生は Xserver に Nextcloud をインストールされている貴重な存在です。
ということで先生の言うとおり .htaccess に以下を追加します。この先生の記事がなければ寿命が1000歳まで延びても自分で解決することなどできっこありませんでした。
Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
バックグラウンドジョブ
警告ではなくて赤いバッテンのエラーです。バックグラウンドジョブが1時間前で何かが間違っていると。この図はわざと作ったもので1時間で済んでいますが最初に見たときは100時間越えていたように思います。
このエラーの対処として「バックグラウンドジョブの設定を確認する」がありますので確認してみます。
「大規模なインスタンスでは、’Cron’がお薦めの設定です」と書かれているので、「大規模なインスタンス」を見逃した粗忽者が、そうか Cron がオススメなのか。と、Cron を選んでいたようです。エラーが出てるのでこれを AJAXに変更してみましょう。
エラーはなくなりました。
いくつかのプライマリーキーがありません
まだ警告は残っていて、例えば「Primary Keyがないよ」警告です。
Nextcloudのバージョンが上がって、この警告が日本語で表示されるようになりました。
テーブルも判るしキーがないのも判るんですが、かといってプラマリキーって何なのか判らないし、何を作っていいのかわからないので放置します。いつか判れば作ればいいですね。
— 時が流れて —
と、思っていたんですがプライマリーキーってのが何かというと、固有のレコードを判別するキーのことらしいです。IDとかそういうやつですよね。完全ユニークなやつです。それが判ればしめたもの。MySQLサーバを覗くと見当が付くかもしれません。
実は先日Nextcloudのアップデート途中で処理が止まってしまい、壊滅しました。それですべて新しく作り直したので「もう間違っても失敗してもどうなってもいいの」という気持ちで挑んだのです。
で、テーブルの名前は示されているので「構造」を見ます。プライマリーキーが何者なのか判った今は「id」とついたものが怪しいと見当を付けられるのです。
いくつか「id」があって、この中でどれかが、レコードを特定するための完全ユニークなidであるはずです。
適当に当たりを付けます。たとえば「user_id」でないことは確かでしょう。user_idがレコードごとのユニークなIDであるはずがありません。collection_id か resource_id のどちらかだと思われます。当てずっぽうに行きましょう。
で、プライマリーキーを設定するというメニューは見当たりませんが、よく見ると下方に「チェックしたものを：」に「主」というものがありました。
プライマリーキー、それは「主」であると想像できます。「主」にしちゃえ。ぷちっ。
正解なら名前の横に「主」アイコンが付きます。見事、プライマリーキーを設定できました。
不正解ならエラーが出ます。「複数同じのがあるから主にできないよ」みたいなエラーだと思います。ハズレなら主をセットできないという安心印の設計に胸をなで下ろしますね。
こうして、テーブルの構造を見て、完全ユニークであろうキーの当たりを付けて「主」にすることで、プライマリーキーの警告は消えました。
Webサーバーで “/.well-known/webfinger” が解決されるように正しく設定されていません
※ このエラーは未解決です
Webサーバーで “/.well-known/webfinger” が解決されるように正しく設定されていません。
Webサーバーで “/.well-known/nodeinfo” が解決されるように正しく設定されていません。
Webサーバーで “/.well-known/caldav” が解決されるように正しく設定されていません。
Webサーバーで “/.well-known/carddav” が解決されるように正しく設定されていません。
という、ドキュメントを読んでもさっぱり判らない謎エラーです。世の賢人たちに頼ろうとも、情報も少ないです。
まず、このエラーを修正するのは、nextcloudフォルダの中ではなく、その上というかトップというかルートにある .htaccess です。Xserver では /public_html/ のところですね。ここの .htaccess に以下を追記します。
以下はルートに「nextcloud」というディレクトリがある前提です。
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>
駄目でした。
もしかしたら、設定してしばらく時間の経過を待たねばならなのかな。わかりませんが、どの先生のコードも効果なかったので、このエラーはもう諦めます。
PHP OPcacheモジュールが正しく設定されていません。 OPcache バッファはほぼいっぱいです。
“PHP OPcacheモジュールが正しく設定されていません。 OPcache バッファはほぼいっぱいです。すべてのスクリプトをキャッシュに保持するために、PHP設定に “opcache.memory_consumption” を “3072” よりも高い値で適用することをおすすめします。 OPcache のインターン化文字列バッファがほぼいっぱいです。繰り返しの文字列を効果的にキャッシュするために、PHPの設定に “opcache.interned_strings_buffer” を “96” よりも高い値で設定することをおすすめします”
という長いエラーです。PHP を8.1.2にすれば直るという情報もありますが、8.1.2 ですけどエラー出ています。
opcache.memory_consumption = 3072 opcache.interned_strings_buffer = 96
とか
opcache.jit = 1255 opcache.jit_buffer_size = 128M
とか、user.ini に書いてみたわけですが、もちろん何の効果もありません。これもお手上げで放置しております。賢人様の知恵をお待ち申し上げます。
サーバーにはメンテナンスウィンドウの開始時間が設定されていません。
“サーバーにはメンテナンスウィンドウの開始時間が設定されていません。これは、リソースを多く使用する日常のバックグラウンドジョブが、メインの利用時間中にも実行されることを意味します。利用者がこれらの重いタスクによる負荷の影響を受けにくくするために、低い利用時間に設定することをおすすめします”
というエラーも放置中です。cron を何とかしろと言ってるみたいですがよくわかりません。
ログには 20yy年mm月dd日 以降、エラーが xxxxx 件あります。
エラーがあるそうで、日付を確認したら1週間で2万件近くありました。何だろうと思って見てみたら、ほとんど同じエラーで、これでした。
Unknown: Use of mbstring.internal_encoding is deprecated at Unknown#0
これはPHP8以降のあれでした。php.ini（.user.ini）の [mbstring] のところにある設定です。
mbstring.internal_encoding = UTF-8
こういう記述があれば、それは非推奨になったので ; を付けてコメントアウトします。
;mbstring.internal_encoding = UTF-8
他にもPHPで非推奨の設定があればコメントアウトしておくのを忘れずに。
;mbstring.http_input = pass ;mbstring.http_output = pass
Nextcloud のエラー対策は、バージョンアップの度に行う必要があります。その都度「あちゃー。なんだっけ。どうだっけ」とあたふたするので、こうしてブログにコピペしてまで記録を残しているわけですが、もちろんそれは自分のためであります。自分のためは人のため。人のためは自分のためでございます。
ルートの .htaccess、nextcloud直下の .htaccess、それとnextcloud/config/config.php は、修正して上手くいったらローカルにバックアップしとけばいいですよ。どうせ後日何度も同じ情報を探す羽目になります。
Nextcloud
追記: Xserver の500エラー問題
定かではありませんが2022年の一時期以降、Nextcloud のダッシュボードに入れない、更新しようとすると失敗する、500エラーなど、盛大にエラーに遭遇するようになりました。
nextcloud のトラブルはよくあるので、その都度別の場所に新規にインストールして仕切り直してきました。大抵これで乗り切ってきましたが、setup-nextcloud.php を使うと、やはり途中で止まってしまい500エラーで何もできなくなります。
仕方なしに ファイル群をFTPで放り込み手動インストール。ですがここでもセットアップ途中で同じエラーに遭遇して先に進めなくなります。
対処は、nextclud/.htaccess を一部書き換えます。
nextcloud フォルダ内の .htaccess で以下の記述を見つけ
<IfModule pagespeed_module>
ModPagespeed Off
</IfModule>次のようにコメントアウトしてしまいます。
<IfModule pagespeed_module>
# ModPagespeed Off
</IfModule>これで多分セットアップくらいは続けられるようになります。
この応急措置だけでは根本的には何も解決せず、他の問題は続きます。Nextcloud の更新も放棄したままです。
この問題は私の脳容量の範囲を超えているので世の賢人様たちの知恵に頼るわけですが、とても丁寧かつ判りやすい対処を書いてくれているページがあったので、自分のためにもリンクしておきます。
参考になったページ
エックスサーバーに入れたNextcloudをアップデートしたら500 Internal Server Error！さらに…！
https://hawaii-de-harley.com/nextcloud-500-error/
Nextcloud 500 Internal Server Error
https://www.surlofia.com/nextcloud-500-internal-server-error/
上記ページの nextcloud 関連index。問題、原因、解決方法、解決策ソースまで整然と網羅されていて、digitalbooのこの記事など不要になりました。
Nextcloud セキュリティ＆セットアップ警告を修正する方法
https://www.surlofia.com/nextcloud-how-to-fix-security-and-setup-warnings/
Xserver の仕様の問題らしいので、いつの日か Xserver が対処してくれれば収まるかもしれませんが、それまでは世の賢人たちのお世話になりましょう。
追記:24 にしばらく留まることにした話
今2023年の冬・・・もうじき春になるかという時期ですが。
Nextcloud を24から25にバージョンアップしてみたところ、とんでもない目に遭いまして。もうね、何をやっても同期しないし、ネットワークエラーでクライアントアプリが真っ赤に染まって動かなくなるしでストレス最高潮でした。
ネット側にログインして中途半端に同期しかけているフォルダやファイルを削除しようとしてもすべてエラーで削除もできないし、仕方ないのでFTPで消してから myAdmin で oc_file_locks を空にしてもその時だけですぐまた同じ状況に。何日経っても同期せず同じエラーが出続けCPU使用率100%で走り続けておりました。その間、同期フォルダのファイルはすべて失われたり中途半端に屍状態になってTimeMachineのお世話になること十回。クライアントアプリのバージョンを下げても上げても何の効果もなしでした。
ムカついてデータベースとnextcloudフォルダを全部消して再インストールすること6、7回。同じことを繰り返しても結果は真っ赤っか。
結局どうにもならず「もしかして25に更新したから？」と、最初に思いつかねばならぬことをやっと思いついて、またデータベースもファイルも全部消して 24.0.10 をダウンロードして再インストールしてようやく収まりました。
環境によるかもしれませんが自分は25は最悪だったということで、二度とバージョンアップしません。
と、イキっておりましたが、Nextcloud のバージョンもその後順当に上がって、問題はなくなりました。上記、特定バージョンの不具合だったのかもしれません。
聞くところによりますと、24 → 25 の更新時に、みんなえらい目に遭って阿鼻叫喚だったのだとか。
クライアントアプリのバージョン
それより、ここの筆者はデジタル部活に励みつつ、実はOSの更新を止めている化石でもあります。Nextcloud は対応OSの幅が広く信頼できるシステムですが、いよいよクライアントアプリの更新に付いていけなくなりました。
macOS 10.15 Catalina で使用できる最後のクライアントアプリはバージョン 3.10.0（2023-09-15）が最後です。
macOS 10.14 Mojave で使用できる最後のクライアントアプリはバージョン 3.9.4（2023-09-06）
nextcloud クライアント のダウンロードは以下から。
https://download.nextcloud.com/desktop/releases/
数年後 … Xserver で Nextcloud アップデートのエラーと警告に対処2 が投稿されましたが…
