カテゴリー: nextcloud Page 3 of 4

Nextcloudサーバでcronが止まったときの対処。(自動アップデートされたPHPの復旧)

環境

Ubuntu20.04/Apache 2.4でNextcloudを27にアップデート後、以下のメッセージがありました。

・最後のバックグラウンドジョブの実行は17時間前を実行しました。何かがおかしいようです。バックグラウンドジョブの設定を確認してください。

この問題を解決していきます。

状況確認

  • cronジョブを確認
sudo -u www-data php /var/www/html/nextcloud/cron.php 
# Nextcloudがインストールされているディレクトリ配下にあります
  • 実行結果
Doctrine\DBAL\Exception: Failed to connect to the database: An exception occurred in the driver: could not find driver in /var/www/html/nextcloud/lib/private/DB/Connection.php:140
Stack trace:
#0 /var/www/html/nextcloud/3rdparty/doctrine/dbal/src/Connection.php(1531): OC\DB\Connection->connect()
#1 /var/www/html/nextcloud/3rdparty/doctrine/dbal/src/Connection.php(1029): Doctrine\DBAL\Connection->getWrappedConnection()
#2 /var/www/html/nextcloud/lib/private/DB/Connection.php(262): Doctrine\DBAL\Connection->executeQuery()
#3 /var/www/html/nextcloud/3rdparty/doctrine/dbal/src/Query/QueryBuilder.php(345): OC\DB\Connection->executeQuery()
#4 /var/www/html/nextcloud/lib/private/DB/QueryBuilder/QueryBuilder.php(280): Doctrine\DBAL\Query\QueryBuilder->execute()
(後略)

この症状をWebで見てみたら、同じような症状を発見。

もしやと思ってphpinfoで調べたら、やっぱりlaravelをインストした時はphp8で、
アプデの時に8.1がインストされたようです。

php -v
PHP 8.2.8 (cli) (built: Jul  8 2023 07:09:59) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.8, Copyright (c) Zend Technologies

サーバの設定変更時にPHPのバージョンアップが走り、新たなPHPにPHPドライバーが走っていなかったようです。

まずはこの問題をただすため、上記URLを参考に以前使っていたバージョンに戻します。

PHPバージョンダウン

sudo update-alternatives --config php
alternative php (/usr/bin/php を提供) には 2 個の選択肢があります。

  選択肢    パス           優先度  状態
------------------------------------------------------------
* 0            /usr/bin/php8.2   82        自動モード
  1            /usr/bin/php8.1   81        手動モード
  2            /usr/bin/php8.2   82        手動モード


現在の選択 [*] を保持するには <Enter>、さもなければ選択肢の番号のキーを押してください: 1
update-alternatives: /usr/bin/php (php) を提供するためにマニュアルモードで /usr/bin/php8.1 を使います

sudo update-alternatives --config phpを実行して、選択肢「1」を実行。

  • Webサービス再起動
sudo systemctl restart apache2.service
  • バージョンダウン確認
php -v
PHP 8.1.21 (cli) (built: Jul  8 2023 07:09:57) (NTS)

これで元に戻っていることを確認。

  • cron再実行
sudo -u www-data php /var/www/html/nextcloud/cron.php 
# Nextcloudがインストールされているディレクトリ配下にあります

エラーなくcron.phpが実行されることを確認しました。

復旧確認

Nextcloudに管理者権限でログインし、管理>概要へと進みます。

エラーはなくなりました。もう一つの警告画面はまた改めて対処します。

Nextcloud、メンテナンスモードの解除方法。

はじめに

プライベートのオンラインストレージをWebベースで構築できるNextcloud。

ブラウザ上からもアップデートなどを行えるのは大きな利点ですが:メンテナンス中にWebブラウザが落ちてしまった場合に

このようなメンテナンスモードが出ます。(ブラウザ上で処理ができなかったことが原因です)

サーバ自体を

sudo reboot

と再起動を行ってもその状態であることが多いです。

「処理が終わるまでブラウザを落とさず待つ」が正常な手順ですが、それを怠った場合のリカバリについてです。

動作環境

  • Ubuntu 20.04
  • Nextcloud
  • Apache 2.4
  • PHP8.1

さっくりとした手順

  1. Nextcloudサーバにアクセスします。
  2. 設定ファイルを書き換えます。
  3. Apacheサービスを再起動します。
  4. メンテナンスモードの解除を確認します。

Nextcloudサーバへのアクセス

cd /home/www-data/nextcloud/config && pwd
# 自分のディレクトリを指定します

コンフィグファイルのバックアップ

sudo cp -pi config.php /path/to/backup/directory/config.php.$(date +%Y%m%d)

ファイルの内容書き換え

sudo -u www-data sed -i "s/'maintenance' => true/'maintenance' => false/" config.php
# メンテナンスモードを無効化します。

apache2サービス再起動

sudo systemctl restart apache2.service

再起動後の確認

メンテナンスモードが解除されました。「アップデートを開始」をクリックします。(今度はブラウザを閉じないようにしましょう)

その後、NextcloudのWeb画面が出てきたので問題なくアップデートされました。

Nextcloud管理画面での警告対応。(occ実行)

概要

Nextcloudをバージョンアップ後、以下のような警告が管理画面で出てきました。

セットアップに関して警告がいくつかあります。
データベースにいくつかのインデックスがありません。 大きなテーブルにインデックスを追加すると、自動的に追加されないまでに時間がかかる可能性があるためです。 "occ db:add-missing-indices"を実行することによって、インスタンスが実行し続けている間にそれらの欠けているインデックスを手動で追加することができます。 インデックスが追加されると、それらのテーブルへのクエリは通常はるかに速くなります。
テーブル "oc_filecache"のインデックス "fs_parent"が見つかりません。

環境

  • Ubuntu 20.04
  • PHP8.1
  • Nextcloud 26.0.1
  • Apache 2.4

での対応です。

実施内容

  • コマンド
cd /var/www/html/ && pwd
# Nextcloudのあるディレクトリに移動します
          
sudo -u www-data /bin/php occ db:add-missing-indices
# Webサービスの実行者(ここではwww-data)を指定します  
  • 処理例
Check indices of the share table.
Check indices of the filecache table.
Adding additional parent index to the filecache table, this can take some time...
Filecache table updated successfully.
Check indices of the twofactor_providers table.
Check indices of the login_flow_v2 table.
Check indices of the whats_new table.
Check indices of the cards table.
Check indices of the cards_properties table.
Check indices of the calendarobjects_props table.
Check indices of the schedulingobjects table.
Check indices of the oc_properties table.
Check indices of the oc_jobs table.
Check indices of the oc_direct_edit table.
Check indices of the oc_preferences table.
Check indices of the oc_mounts table.

実施後

Nextcloudの管理画面でリロードを行いました。

全てのチェックに合格しました。

と出たのでOKです。

プログラム自身がチェックを行ってくれるのがNextcloudの強み。

AWS LightsailからNextcloudをアンインストール。

AWS Lightsailで検証したNextcloudをアンインストールします。

導入していた環境

以下の環境で動かしていたNextcloudをアンインストールします。

  • Ubuntu 20.04
  • Apache 2.4
  • PHP 8.1
  • MySQL 8.0.3

そもそも:なぜアンインストールを行ったか?

スペック不足。

外部公開を目指しAWSのLightsailインスタンスで立ち上げましたが、

  • 表示速度
  • 処理能力

その他が納得いくものではありませんでした。

機能が被っている

  1. タスク管理/文書管理としてRedmine
  2. フォトアルバムとしてPiwigo

をインストールしているため、これらと機能が被るものを同一サーバにインストールするには望ましくありません。

ローカル環境との混同

これが一番の問題でした。ローカル(自宅環境)で既に運用しているNextcloudにはかなりのセンシティブ情報が含まれています。これが外部環境に誤ってアップロードされてしまうのはセキュリティポリシー上問題があると判断。

実施した手順

さっくりとした手順

  1. 本当にアンインストールしていいかいったん深呼吸します。
  2. クライアントからアカウントを削除します。(PCを利用している場合)
  3. バーチャルファイルを無効にします。
  4. DBを削除します。
  5. バーチャルファイルを削除します。
  6. ファイルを削除します。

アンインストールでも残すもの

  • PHPは既に他のサービスで動かしているので残します。
  • MySQL/Apacheについても同様です。

削除対象の確認

  1. 深呼吸する
  2. お茶を入れて飲みながらじっくり考え

削除を決意。

重要なファイルがあるかを確認

もう一度確認します。

PCクライアントから設定削除

WindowsなどでNextcloudのアカウントを設定していたので、こちらを削除します。

バーチャルファイル無効化

  • バーチャルファイル無効化
cd /etc/apache2/sites-available && pwd

sudo a2dissite nextcloud.conf
# 自分が設定した環境に合わせます。
  • 無効化反映
sudo systemctl restart apache2.service

この時点でアクセスできないことを確認です。

DB削除

mysql -u root -p
# mysqlのrootパスワードでログイン
SHOW DATABASES;
/* 削除対象を確認します */

DROP DATABASE nextcloud;
/* DB名を再度確認します */
/* 容赦なく削除されるので慎重に行ってください */

SHOW DATABASES;
/* DBがないことを確認します */

EXIT

プログラム一式を削除

  • nextcloud配置ディレクトリ削除
cd /var/www/html && pwd
# nextcloudが格納しているディレクトリ

ls -ld nextcloud
# ディレクトリがあることを確認します

sudo rm -rf nextcloud

ls -ld nextcloud
# ディレクトリがないことを確認します
  • nextcloudバーチャルファイル削除
cd /etc/apache2/sites-available && pwd
# 対象ディレクトリにいることを確認します

sudo rm nextcloud.conf 

後始末

  • 独自ドメインで運用していたのであれば、Nextcloudのために設定していたDNS情報を削除します。
  • 削除されたことを確認します。

最後に

スペックや機能の面でほぼほぼ「こうなるだろうな」という予感はありました。
ですが、一応、やってみるだけの価値はありました。(ローカル環境と比べ著しく遅いと体感でき、後の未練を断つことができました)

続・MySQLの自動バックアップ。(パスワードによる暗号化付与)

こちらの記事で挙げたRedmineなどのMySQLを実行するスクリプト。

この問題点を修正します。

問題点

  • むきだしのSQLファイルが平文で格納されてしまうのはセキュリティ的によろしくありません。
  • MySQLのバックアップ時に使うアカウントファイルが誰でも読み取れるのも問題です。

そこで、バックアップされたファイルにパスワードをかけることで簡単な防波堤を作ることにします。

前提

上記URLに併せます。

  1. MySQL dumpを行うDBにRELOAD権限があること。
  2. 次の環境で動作を確認しています。
  • Ubuntu 20.04
  • MySQL 8.0.32

実施した手順

さっくりとした手順

  1. バックアップディレクトリを作成します。
  2. DBにアクセスするためのアカウント情報を記したファイルを作成します。
  3. 開封パスワードを格納するディレクトリを作成します。
  4. バックアップスクリプトを作成します。
  5. crontabに登録します。

バックアップディレクトリを作成します。

sudo mkdir -p /home/backup/mysql
# 運用に合わせて指定ください。ファイルサーバや別パーティションにマウントしている方がサーバ事態の障害発生でも冗長化を持たせられます。

sudo chown -R hoge:hoge /home/backup/mysql
# ディレクトリの所有者をログインユーザに修正します

cd /home/backup/mysql && pwd
# 指定したディレクトリに移動します

DBにアクセスするためのアカウントファイルを作成します。

Cronによる自動実行を前提としているため、スクリプト実行時にDBユーザとパスワードを記したファイルを読み込むことでセキュリティのリスクを抑えます。

sudo mkdir -p /home/hoge/db_password
# 運用に合わせて指定ください。

cd /home/hoge/db_password && pwd
# 指定したディレクトリに移動します

以下の内容を教義・信仰に沿ったエディタで作成します。(【】内は取り除き、自分の設定に合わせます)

  • アカウントファイル内容
    • ファイル名:account.txt
[client]
user = 【RedmineのDBユーザ】
password = "【RedmineのDBユーザ用パスワード】"

その後、このファイルの読み取り権限を変更します。

chmod 400 account.txt

ls -l account.txt
# パーミッションが400であることを確認します

アカウントファイルでアクセスできることを確認

mysql --defaults-extra-file=【アカウントファイルを格納したディレクトリ】/account.txt

#MySQLのプロンプトが出れば成功です。exitで抜けます。

スクリプト作成

以下の内容を教義・信仰に沿ったエディタで作成します。

  • スクリプト内容
    • スクリプト名:pw_mysql_daily_backup.sh
#!/bin/bash

## 変数ここから ##
# SQLをバックアップするディレクトリ(保管先)を指定します。運用に合わせて指定ください。
backup_dir="/home/backup/mysql"
# 保持するバックアップの世代を日数で指定します。
keep_days=7
# ファイルに付与する日付/作業ディレクトリ名/バックアップファイル名を指定します。
current_date=$(date +%Y%m%d)
backup_name="redmine_mysql_${current_date}"
zip_file="redmine_mysql.${current_date}.zip"
# アカウントファイルを指定します。運用に合わせて指定ください。
credentials_file="$HOME/redmine/account.txt"
# パスワードを記録するファイル名を指定します。運用に併せてして指定ください。
password_dir="$HOME/restore_redmine"
password_file="${password_dir}/mysql-restore.$current_date.txt"
# redmineのデータベース名を指定します。
database_name=redmine
# バックアップ時に指定するオプションを指定します。
options="--defaults-extra-file=$credentials_file --no-tablespaces --single-transaction"
## 変数ここまで ##

## 処理ここから ##

# 1.アカウントファイルのパーミッションが400かどうかチェックします。
# 400以外は処理そのものを終了します。
permissions=$(stat -c "%a" "$credentials_file")
if [ "$permissions" != "400" ]; then
    echo "アカウントファイルのパーミッションは400である必要があります。"
    exit 1
fi

# 2.一時的なバックアップディレクトリを作成します。
mkdir "${backup_dir}/${backup_name}"

# 3. mysqldumpを実行してデータベースのバックアップを取ります。
mysqldump $options -h localhost $database_name > "${backup_dir}/${backup_name}/${backup_name}.sql"

# 4. パスワードによる暗号化を実施します。
password=$(openssl rand -base64 12)
cd "${backup_dir}/${backup_name}"
zip -r "${backup_dir}/${zip_file}" -P "$password" .
cd -

# 5. 一時的なバックアップディレクトリを削除します。
rm -rf "${backup_dir}/${backup_name}"

# 6. 解凍パスワードを指定ディレクトリに保存します。
echo $password > $password_file

# 7.パスワードの読み取り権限を600に変更します。
chmod 600 $password_file

# 8. 保持期間より古いバックアップファイルを削除します。
find "$backup_dir" -name "redmine_mysql.*.zip"  ! -type f -newermt "${keep_days} days ago" -delete
find "$password_dir" -name "*restore*.txt" ! -type f -newermt "${keep_days} days ago" -delete

## 処理ここまで

前回との修正点

  1. 変数と処理のセクションを明確化しています。
  2. アカウントファイルのパーミッションチェックを行い、400以外は処理を中止します。
  3. opensslで生成したパスワードで暗号化します。(このパスワードはランダムで生成されるので運用者は覚える必要がありません)
  4. 圧縮と同時に暗号化を行うので、gz形式からzip形式に変更しています。
  5. このパスワードを任意のディレクトリに転送します。
  • 実行権限の付与
chmod +x pw_mysql_daily_backup.sh

動作確認

cd 【スクリプトを格納したディレクトリ】 && pwd
bash pw_mysql_daily_backup.sh

以下を確認します。

  1. エラーなく実行できること
  2. バックアップ格納ディレクトリにredmine.sql.実行日付.zip形式でファイルが作成されること
  3. パスワードファイル格納ディレクトリにファイル名.実行日付.txt形式でファイルが作成されること
  4. unzip redmine.sql.実行日付.zipでファイル解凍時にパスワードを確認されること
  5. パスワードファイルで暗号化されたファイルを解凍することができること

Crontab設定

Cron登録

crontab -e

登録内容例

0 0 * * * /home/backup/mysql/pw_mysql_daily_backup.sh
# 実行時刻、頻度などは自分の運用形態に合わせます。
# また、既に平文でのバックアップスクリプトを設定している場合はコメントアウトして処理を外します。

Cron登録確認

sudo tail -20 /var/log/cron.log

操作時刻に

  • BEGIN EDIT
  • REPLACE
  • END EDIT

が表示されれば設定は完了です。

動作確認日

2023/02/18

NextcloudサーバのPHPアップグレードとエラー解消、そして再設定。(PHP7.4→PHP8.1)

Nextcloudを動かしている自宅サーバでPHPをアップグレード。

ちょっとだけハマったのでメモを残します。

環境

以下の環境でNextcloudを動かしています。

  • Ubuntu 20.04
  • Apache
  • MySQL
  • PHP 7.4

さっくりとした手順

  1. PHP7.4をアンインストールします。
  2. PHP8.1をインストールします。
  3. 追加モジュールを有効化します。
  4. NextCloudの追加設定を行います。

手順

  • 今回は全て通常ユーザで作業をします。
  • また、viを使わずコマンドを用いて設定を置き換えています。
  • 設定をするのはPHPのみです。他は設定の変更をしていません。
  • パッケージ/モジュールのインストールにaptitudeを用いています。好みに合わせてaptをご利用ください。

PHPの削除を行います。

sudo apt-get --purge autoremove php*

PHP8.1をインストールします。

sudo aptitude install php8.1

sudo aptitude install php8.1-{opcache,pdo,bcmath,calendar,ctype,fileinfo,ftp,gd,intl,json,ldap,mbstring,mysql,posix,readline,sockets,bz2,tokenizer,zip,curl,iconv,phar,xml}

sudo aptitude install php8.1-apcu

sudo aptitude install php8.1-memcached

php -v
# PHP 8.1.14 (cli)を確認しました。(2023/01/19)

apache再起動を行います。

sudo systemctl restart apache2.service

アップグレード後にエラー。

PHPアップグレード後、Nextcloudにアクセスするとこうなりました。

前の設定が全て消えたので、エラーが発生しました。

こちらを解消していきます。

エラーチェック

cd /var/www/html/nextcloud/
# Nextcloudの格納ディレクトリに移動します。自分の環境に置き換えてください。

sudo -u www-data php ./occ
# NextcloudのCLIインタフェースです
エラー内容
An unhandled exception has been thrown:
OCP\HintException: [0]: Memcache \OC\Memcache\APCu not available for local cache (Is the matching PHP module installed and enabled?)

memcacheとAPCuが読み込まれていないと怒られましたので、有効化していきます。

memcacheとAPCuの有効化

cd /etc/php/8.1/cli/conf.d
cat <<- __EOF__ | sudo tee -a /etc/php/8.1/cli/conf.d/10-opcache.ini
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
__EOF__
cat <<- __EOF__ | sudo tee -a /etc/php/8.1/cli/conf.d/20-apcu.ini
[apcu]
apc.enabled=1
apc.shm_size=32M
apc.ttl=7200
apc.enable_cli=1
apc.serializer=php
__EOF__
sudo systemctl restart apache2.service

再設定後の確認

cd /var/www/html/nextcloud/
# nextcloudの格納ディレクトリに移動します

sudo -u www-data php ./occ
# エラーが出ず、occのオプションが表示されることを確認しました。

この後、Nextcloudにアクセスし、画面が表示されることを確認しました。

管理者画面確認

Nextcloudに管理者アカウントでログインし、管理者設定を確認すると

  • PHPのメモリ制限が推奨値の512MB以下です。
  • テーマ別アプリは有効ですが、PHPモジュール「imagick」が有効ではありません。ファビコン生成を正しく行うには、このモジュールをインストールし、有効化する必要があります。
  • PHP モジュール "gmp" および "bcmath" が有効になっていない。WebAuthnパスワードレス認証を利用する場合は、これらのモジュールが必要です。

が出てきました。これを修正していきます。

php.ini修正

sudo cp -pi /etc/php/8.1/apache2/php.ini /etc/old/php.ini.$(date +%Y%m%d)
# /etc/oldがなければディレクトリを作成するか、任意のバックアップパスを指定してください

diff -u /etc/php/8.1/apache2/php.ini /etc/old/php.ini.$(date +%Y%m%d)
# 差分が存在しないことにより、バックアップが取れていることを確認します。

sudo sed -i 's/memory_limit = 128M/memory_limit = 512M/g' /etc/php/8.1/apache2/php.ini
# memory_limitを推奨値の512Mに置き換えます。
差分確認
diff -u  /etc/old/php.ini.$(date +%Y%m%d) /etc/php/8.1/apache2/php.ini
# 取得したバックアップと置き換えたファイルの差分を確認します
  • 差分
-memory_limit = 128M
+memory_limit = 512M

不足モジュールのインストール

sudo aptitude install php8.1-{imagick,gmp}

設定反映と確認

sudo systemctl restart apache2.service

Nextcloudに管理者アカウントでログインし、管理者設定を確認。

「すべてのチェックに合格しました」

と出たので設定完了です。

Nextcloudのリリース判定。

そもそも、このNextcloudを導入しようと思っていたきっかけは「Dropboxの代わりにならないか」でした。

なので、それを判定です。

スマートフォンの画像をアップロードできるか

→ 問題なし。出先からアップロード出来ないという問題がありますが、逆に無線Wi-Fiルータの帯域を消費せずに住みます。

表示速度などは大丈夫か

→ やはり問題なし。むしろローカル環境なので(インターネット回線に左右されないので)回線速度は良好。プレビューが少しもたつくかなぐらいですが誤差の範囲内です。

システムリソースに負荷がかからないか

→ アップロードした画像にタグ付けや顔認識をする「recognize」のせいで、ロードアベレージが常時10を超える事態が導入直後から1週間以上続きました。

ですが、その処理が無事に終わったあとは収束を見せています。

データの冗長化はどうなっているか

→ こちらも、lsyncによるデータのリアルタイム動機により解決。

結論

10年以上用いていたDropboxを解約するに至りました。(というよりも、並行期間中、Dropboxが使えないことに不便は感じていません)

あと、やることがあるとするならこのサーバ自体のスペックアップとデータストレージの増強ぐらいかなと。

Nextcloudが稼働している小型PC[Chuwi Herobox pro]

NextCloudを利用してのフィードバック。

自身のオンプレ環境にNextcloudを運用するようになって一ヶ月ちょっと。

思ったことを少し述べます。

よかったこと

画像ファイルの保存

スマートフォン/iPadで保存したファイルを逐次アップロードしてくれる安心感は本当に素晴らしいです。しかも、自宅内NWでのみアップロードする環境なので不要な通信を抑えられます。

自動タグ付けによる取り回し

アプリ「recognize」のおかげで、ある程度の画像の分類をしてくれるようになりました。

やや難点

「統合的」に用いることはできない

  • カレンダー
  • ノート
  • スケジュール

など、様々なアプリが用意されていますが、それ専門に特化したWebサービスには及ばないという印象。ToodleDoなどのようにToDoの繰り返し登録などがあれば良かったのになと思います。

自動タグ付けのCPU消費

機械学習によるタグ付けは、それだけでCPUを激しく消費します。特に、画像を大量登録していた移行期〜3週間ほどはロードアベレージが7〜8を超えていてヒヤヒヤものでした。

今後の展望

「Dropboxから安全に移行できるか」が鍵になります。そうなると、ディスクの冗長化や一層のセキュリティ対策が求められるので、課題は続きます。

Nextcloudにアプリ『Quick Notes』を導入。

使い勝手を試してみます。

導入

Redmineのプラグインと異なり、NextcloudのアプリはWeb管理画面から行うことができます。

管理メニュー→アプリへと移動します。

検索などで「Quick Notes」を検索します。

アプリを有効化します。

「ダウンロードして有効にする」をクリックします。このとき、管理者パスワードを訊かれるので入力後に「Confirm」をクリックします。

有効化後、

トップページに「Quick notes」が出てきます。

アプリ外観

インストール直後は当然ながら、右側の所にはなにもありません。「+ New note」をクリックします。

Google Keepのような入力画面。写真も添付できますが、NextCloud上のものしか添付できません。

ファーストインプレッション

Google KeepのようでGoolge Keepでないというのが第一印象でした。特に、デフォルトでは自動セーブされない(更新したい場合はSaveを推す必要がある)のは結構違和感があります

なので、Settingsで

このチェックを外して自動セーブをデフォルトにするのがいい感じになりそうです。

そして、

  • 書いた文章の全てが表示される
  • ノート覧が左に表示される

のはKeepにない強み。

とはいえ、「Google Keepの代替になり得るか」に関しては現時点ではNo。今後の運用を見つけていく形です。

Nextcloudのバージョンアップ。

WordPressと変わらない操作感でバージョンアップを行うことができました。

操作手順

NextcloudのWeb画面にログインし、「Administration settings」をクリックします。

更新できることを確認します。

アップデーターを開きます。

「アップデーターを開く」をクリックします。

アップデートを開始します。

「Start update」をクリックします。

どの段階まで進んだかを示してくれる親切設計でした。(写真を大量に保管しているのでバックアップ作成はかなりの時間がかかりました)

メンテナンスモードを解除します。

「Disable maintenance mode and continue in the web based updater」をクリックします。

「アップデートを開始」をクリックします。

何も問題がなければ、Nextcloudの管理者にログインされた状態でページが切り替わります。

アップデート後の後処理を行います。

アップデート対象に「Themes」が含まれていたので、背景が真っ白になっていました。これを修正するため再び「Administation settings」に進み、テーマをクリックします。

Background and login imageをクリックして任意の画像に置き換えます。

この後、「概要」をクリックすることで

「最新版です」となっていることを確認しました。

Page 3 of 4

Powered by WordPress & Theme by Anders Norén