タグ: Nextcloud Page 1 of 6

NextcloudアップデートとDBバックアップを行うBashスクリプトの解説

Nextcloudのアップデートは、それほど頻繁に行う作業ではありません。しかし、だからこそ毎回「あれ、このコマンド実行したっけ?」となりがちです。

筆者自身も、メンテナンスモードの切り替えやデータベースのバックアップなど、手順を一つひとつ確認しながら作業していました。そこで「毎回やることはスクリプトに任せよう」と考え、更新前のバックアップから updater.phar の実行までを一通り補助する Bash スクリプトを作成しました。

今回は、そのスクリプトの仕組みを紹介します。

動作環境

動作を想定している環境は以下の通りです。

  • Ubuntu 20.04 LTS / 22.04 LTS / 24.04 LTS
  • MySQL または MariaDB
  • PHP / Bash
  • root 権限(sudo)
  • Apache実行ユーザ: www-data

Ubuntu系で一般的な構成であれば、そのまま利用できるようになっています。

スクリプト本体

最初に環境に合わせて、スクリプト冒頭の変数だけ変更します。

NC_DIR="/var/www/html/nextcloud"
NC_USER="www-data"

DB_NAME="nextcloud"
DB_USER="nextcloud"

BACKUP_DIR="/var/backups/nextcloud"

続いて実行権限を付与します。

chmod +x nextcloud_update.sh

最後に sudo で起動します。

sudo ./nextcloud_update.sh

途中では

  • データベースパスワード
  • 各ステップへ進むかどうか

を対話形式で確認します。

確認しながら進められるので、完全自動化というより「操作ミスを減らすための半自動化」という位置付けです。

Bashで自動化というと「全部ワンコマンドで終わらせる」方向へ行きがちですが、個人的にはサーバーの更新作業はそこまで割り切らない方が安心だと考えています。

特に Nextcloud のアップデートは、途中で状況を確認したくなる場面も少なくありません。

そのため、このスクリプトでは各工程ごとに確認を挟み、「人が判断するところ」と「機械に任せるところ」を分ける構成にしました。

毎回同じ手順を思い出しながら実行するより、確認すべきポイントだけに集中できるので、更新作業はかなり気楽になります。

以下がスクリプト全文です。

#!/bin/bash
# ==============================================================================
# Nextcloud Update & Database Backup Script
# ==============================================================================

set -euo pipefail

# --- 変数定義(環境に合わせて変更してください) ---
NC_DIR="/var/www/html/nextcloud"
NC_USER="www-data"
PHP_BIN="php"

# DB設定
DB_NAME="nextcloud"
DB_USER="nextcloud"
DB_HOST="localhost"
BACKUP_DIR="/var/backups/nextcloud"

# --- ユーティリティ関数 ---
log_info() {
    echo -e "\n\e[34m[INFO]\e[0m $(date '+%Y-%m-%d %H:%M:%S') - $1"
}

log_warn() {
    echo -e "\e[33m[WARN]\e[0m $(date '+%Y-%m-%d %H:%M:%S') - $1"
}

log_error() {
    echo -e "\e[31m[ERROR]\e[0m $(date '+%Y-%m-%d %H:%M:%S') - $1" >&2
}

ask_proceed() {
    local prompt_msg="${1:-次のステップに進みますか?}"
    while true; do
        read -rp "👉 ${prompt_msg} [y/N]: " answer
        case "${answer}" in
            [yY]|[yY][eE][sS])
                return 0
                ;;
            [nN]|[nN][oS]|"")
                log_warn "ユーザーにより処理が中断されました。"
                exit 1
                ;;
            *)
                echo "'y' または 'n' を入力してください。"
                ;;
        esac
    done
}

# --- 前提チェック ---
# root 権限チェック(sudo 経由を含む root 以外は即時終了)
if [ "${EUID}" -ne 0 ]; then
    log_error "このスクリプトは root 権限で実行する必要があります。(例: sudo $0)"
    exit 1
fi

log_info "前提条件と実行権限を確認しています..."

if [ ! -d "${NC_DIR}" ]; then
    log_error "Nextcloudディレクトリが見つかりません: ${NC_DIR}"
    exit 1
fi

if ! command -v mysqldump &> /dev/null && ! command -v mariadb-dump &> /dev/null; then
    log_error "mysqldump または mariadb-dump コマンドが見つかりません。"
    exit 1
fi

mkdir -p "${BACKUP_DIR}"

# ==============================================================================
# Step 1: データベースパスワードの取得と認証確認
# ==============================================================================
log_info "【Step 1】データベース情報の入力"
read -rsp "🔑 DBユーザー (${DB_USER}) のパスワードを入力してください: " DB_PASS
echo

# パスワードの疎通確認
if ! MYSQL_PWD="${DB_PASS}" mysqladmin -h "${DB_HOST}" -u "${DB_USER}" ping &>/dev/null; then
    log_error "データベースへの接続に失敗しました。パスワードまたはホスト設定を確認してください。"
    exit 1
fi
log_info "データベースへの接続を確認しました。"

# ==============================================================================
# Step 2: メンテナンスモードの有効化
# ==============================================================================
log_info "【Step 2】メンテナンスモードの有効化"
ask_proceed "メンテナンスモードをONにしますか?"

sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/occ" maintenance:mode --on
log_info "メンテナンスモードを有効化しました。"

# スクリプト異常終了時にメンテナンスモード解除を促すトラップを設定
cleanup() {
    if [ $? -ne 0 ]; then
        log_warn "エラーが発生したため処理を停止しました。"
        log_warn "必要に応じてメンテナンスモードを解除してください:"
        log_warn "sudo -u ${NC_USER} ${PHP_BIN} ${NC_DIR}/occ maintenance:mode --off"
    fi
}
trap cleanup EXIT

# ==============================================================================
# Step 3: DBバックアップの実行(インラインパスワード処理)
# ==============================================================================
log_info "【Step 3】DBバックアップの実行"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/${DB_NAME}_backup_${TIMESTAMP}.sql.gz"

ask_proceed "DBバックアップを開始しますか? (保存先: ${BACKUP_FILE})"

# dumpコマンドの判定(MariaDB/MySQL互換)
DUMP_CMD="mysqldump"
command -v mariadb-dump &> /dev/null && DUMP_CMD="mariadb-dump"

# MYSQL_PWD環境変数を使用することで、psコマンド等へのパスワード露出を防止
if MYSQL_PWD="${DB_PASS}" ${DUMP_CMD} -h "${DB_HOST}" -u "${DB_USER}" --single-transaction --quick "${DB_NAME}" | gzip > "${BACKUP_FILE}"; then
    log_info "バックアップが正常に完了しました: ${BACKUP_FILE}"
else
    log_error "バックアップ処理中にエラーが発生しました。"
    exit 1
fi

# ==============================================================================
# Step 4: updater.phar によるアップデート実行
# ==============================================================================
log_info "【Step 4】updater.phar の実行"
log_warn "updater自体の対話プロンプトが表示されます。画面の指示に従って操作してください。"
ask_proceed "updater.phar を起動しますか?"

cd "${NC_DIR}"
sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/updater/updater.phar"

# ==============================================================================
# Step 5: 状態の確認とメンテナンスモードの調整
# ==============================================================================
log_info "【Step 5】最終確認とメンテナンスモードの解除"

current_mode=$(sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/occ" maintenance:mode)
echo "現在の状態: ${current_mode}"

if echo "${current_mode}" | grep -q "enabled"; then
    read -rp "👉 メンテナンスモードをOFF(解除)にしますか? [y/N]: " unfreeze
    if [[ "${unfreeze}" =~ ^[yY]$ ]]; then
        sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/occ" maintenance:mode --off
        log_info "メンテナンスモードを解除しました。"
    else
        log_warn "メンテナンスモードを維持したまま終了します。"
    fi
fi

# ==============================================================================
# Step 6: バージョン確認
# ==============================================================================
log_info "【Step 6】バージョンの確認"
sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/occ" status

log_info "すべての更新手順が完了しました。"
trap - EXIT

このスクリプトで重視したこと

単にコマンドを並べるだけではなく、「途中で失敗しても致命傷にならないこと」を意識しています。

set -euo pipefail

Bashスクリプトでは定番ですが、非常に重要です。

  • コマンドが失敗した
  • 未定義変数を参照した
  • パイプラインの途中でエラーが発生した

このような場合は、その時点で処理を停止します。

「バックアップに失敗したのに、そのままアップデートが続く」といった事故を防ぐためです。

root権限の確認

EUID を利用して、root 権限以外では実行できないようにしています。

sudo ./nextcloud_update.sh

以外の実行方法では即座に終了します。

パスワードをコマンドラインへ残さない

昔ながらの

mysqldump -pPASSWORD

という書き方は、ps コマンドなどからパスワードが見えてしまいます。

そこで本スクリプトでは

MYSQL_PWD

環境変数を利用しています。

賛否のある方法ではありますが、少なくともコマンドライン引数へ平文パスワードを残すより安全です。(なお筆者は別スクリプトを利用していますが、それはまた別のお話)

trapによる復旧案内

一番怖いのは

  • メンテナンスモードON
  • エラー発生
  • そのまま終了

というパターンです。

そこで trap cleanup EXIT を利用し、異常終了した場合は

occ maintenance:mode --off

を案内するようにしています。

「解除方法を忘れた」という事態を防ぐための保険です。

実行の流れ

処理は次の順番で進みます。

1. 前提条件の確認

まずは

  • root権限
  • Nextcloudディレクトリ
  • mysqldump または mariadb-dump

の存在を確認します。

ここで問題があれば、それ以上処理は進みません。

2. データベース接続の確認

パスワードを入力したあと、

mysqladmin ping

で接続テストを行います。

アップデート直前になって認証エラーが発覚するより、最初に確認してしまった方が安心です。

3. メンテナンスモードを有効化

occ maintenance:mode --on

を実行します。この操作の前にも確認プロンプトを表示するため、誤操作を防げます。

4. データベースをバックアップ

バックアップには

  • mysqldump
  • mariadb-dump

のどちらか利用可能な方を自動で選択します。

取得したSQLは、そのまま gzip 圧縮して保存します。

nextcloud_backup_20260821_153000.sql.gz

のように日時付きファイルになるため、履歴も管理しやすくしています。

5. updater.phar を起動

Nextcloud標準の

updater.phar

を実行します。ここから先はNextcloud側の対話画面になりますので、画面の案内に従って更新を進めます。

6. 最終確認

更新後は

  • メンテナンスモードの状態確認
  • 必要ならOFFへ変更
  • occ status

まで実行します。最後に現在のバージョンが表示されれば、一通りの更新は完了です。

さっくりとしたまとめ

サーバー運用では「バックアップを取ってから更新する」は当たり前ですが、人間は当たり前ほど慣れてしまうものです。だから私は、忘れない仕組みを作るようにしています。

「運用者は呼吸するかのようにできる。だが、第三者に任せられるか? すっごく焦ってるときに緊急アップデートをした時は?」のためにも、確実に動く仕組みは大切というお話でした。

Nextcloudにプロキシサーバを設定。

xtcloudサーバのあるネットワークがプロキシー配下にあったため

  • Nextcloudの管理画面がサーバやアプリのアップデートを検知できない
  • ネットと通信するアプリがNextcloudと通信できない

状況が発生。それを修正します。

やることは単純です。

「configファイルの修正」

OSはUbuntuです。

手順

config.php の場所を確認する

Nextcloudのインストール方法によって、設定ファイルの場所が異なります。一般的な場所は以下の通りです。

  • 手動インストール(Apache/Nginx)の場合:
    • /var/www/nextcloud/config/config.php
    • 筆者環境 /home/www-data/nextcloud/config/config.php
  • Snapでインストールした場合:
    • /var/snap/nextcloud/current/nextcloud/config/config.php

2. 設定ファイルのバックアップ

  • 設定ファイルバックアップ
sudo cp -pi /home/www-data/nextcloud/config/config.php /path/to/backup/config.php.$(date +%Y%m%d)
  • 設定ファイルのバックアップ確認
sudo diff -u /path/to/backup/config.php.$(date +%Y%m%d) /home/www-data/nextcloud/config/config.php

エラーがないことを確認します。ここで~sudo~をつけるのは、一般権限では読み込みすらできないからです。

3. プロキシ設定を追加する

上記ファイルを$CONFIG = array ( の中に、以下の3行(プロキシの設定)を追記します。既存の設定項目の末尾() の手前)に追加してください。 当然ながら管理者権限が必要です。

  'proxy' => '192.168.1.50:8080', // 自分の環境に合わせます。
  'proxyuserpwd' => '', // もしプロキシに認証(ユーザー名:パスワード)が必要ならここに記述
  'noproxy' => array('localhost', '127.0.0.1'), // プロキシを通さないローカルアドレス

【設定例】全体のイメージ

<?php
$CONFIG = array (
  'instanceid' => 'ocxxxxxxxxxx',
  'passwordsalt' => 'xxxxxxxxxxxxxxxxxxxxxxxxxx',
  // ・・・(中略)・・・
  'trusted_domains' => 
  array (
    0 => 'localhost',
  ),
  'datadirectory' => '/var/www/nextcloud/data',
  'dbtype' => 'mysql',

  // ここに追記します
  'proxy' => '192.168.1.50:8080',
  'proxyuserpwd' => '',
  'noproxy' => array('localhost', '127.0.0.1'),
);

設定後、ファイルを保存します

  • 設定ファイルの修正確認
sudo diff -u /path/to/backup/config.php.$(date +%Y%m%d) /home/www-data/nextcloud/config/config.php
+  'proxy' => '192.168.1.50:8080',
+  'proxyuserpwd' => '',
+  'noproxy' => array('localhost', '127.0.0.1'),

など、追加したプロキシ設定が追加されていることを確認します。

4. Webサーバー(またはPHP)の再起動

設定を反映させるため、Webサーバーを再起動します。

  • Apacheの場合:
sudo systemctl restart apache2
  • Nginx / Apache + PHP-FPMの場合:
sudo systemctl restart nginx
sudo systemctl restart php8.x-fpm  
  • Snapインストールの場合:
sudo snap restart nextcloud

接続テスト

設定完了後、Nextcloudの管理者画面にブラウザからログインし、以下の項目を確認してください。

  1. 「管理者設定」>「概要」 を開き、インターネット接続に関するエラー(「このサーバーにはインターネット接続がありません…」など)が消えているか確認。
  2. 「アプリ」画面 を開き、外部のアプリストアから新しいアプリの一覧が正常にロードされるか確認。

NextcloudのタスクとiOSのリマインダを認識させる

Nextdloudを更に統合プラットフォームとして使うため、以下の手順が必要でした。

環境

Nextcloud側

  • Ver 33
  • Nextdloud Task (標準アプリ)
  • Ubuntu 24.04
  • PHP-FPM 8.3
  • Apache 2.4
  • MySQL 8
  • ※二要素認証あり
  • ※外部からアクセスできる環境にあること

iOS側

  • iOS 26.42
  • iPhone Air

さっくりとした手順

  1. Nextdloud側でアプリパスワードを作ります。
  2. iOS側でアカウントを競ってします。

Nextcloud側でのアプリパスワードの設定

  1. 個人設定 > セキュリティに遷移します。
  2. デバイスとセッションの一番下、アプリ名というところに適当な名前を付けます。iOSリマインダー
  3. 新しいアプリパスワード作成をクリックします。このパスワードは一度しか表示されません。控えておきます。(一番手っ取り早いのはそのパスワードをコピーして、Nextdloud Talk等で貼り付けること。ただし、Nextdloud全てにアクセスできるパスワードです。設定後、速やかにTalkから削除しましょう。

iOS側での連携

  1. iPhoneの「設定」>「リマインダー(またはアカウント)」>「CalDAVアカウントを追加」の画面を開きます。
  2. 以下のように設定します。
    1. サーバ: 自分のNextdloudのドメイン
    2. アカウント:自分のNextdloudのアカウント
    3. パスワード:先ほど生成したアプリパスワード
    4. 設定:自分が覚えやすいもの
  3. 設定後「次へ」をタップして、エラーがないことを確認します。

連携の確認

Nextdloud側で適当なタスクを作成して、iOS側で表示されることを確認します。

iOSの「リマインダー」に、Nextdloudで設定したタスクが表示されることを確認します。

iOS側で適当なタスクを作成して、Nextdloud側で表示されることを確認します。

iPhoneの画像データを自宅内のNextcloudに一括送信。

連休で家にいる中でないとできない作業でした。

事前準備

  1. Nextcloud(宅内)のセットアップができている。
  2. NextcloudサーバとNASをNFSでマウントしている。(書き取り可能になっている)
  3. iPhoneにNextcloudアプリを入れ、同じNW内にあるNextcloudと連携が取れている。

2,019年からのiPhoneデータ。相当に苦労しました。

自動アップロード設定画面を開く

Nextcloudアプリの自動アップロード機能を有効化するしていきます。

Nextcloudアプリ右下「その他(…)」 → 「設定」 → 「自動アップロード」

の画面を開きます。

カメラロールの自動アップロードを有効化

iPhoneの写真アプリ内の画像・動画をNextcloudへ自動送信するため「カメラロールをアップロード」をオンにします。

必要に応じて「新しい写真のみ」「すべての写真」などの範囲を選択します。(筆者は全ての写真を選択)

保存先フォルダを指定(重要)

誤ったフォルダを選ぶと整理が崩れるため、最も重要なステップです。

  1. 「リモートフォルダ」をタップ
  2. 事前に作成した NAS側の外部ストレージフォルダ を選択しました。

必要に応じて「カメラロール」専用フォルダをNextcloud側で作っておきましょう。

同期条件を設定して安定性を確保

筆者は「Wi-Fi使用時のみ」をオンにしました。というのも、このNextcloudは完全に宅内で運用するからです。

初回のみ:自動ロックの解除

これがハマりポイントでした。

iPhoneの

設定 > 画面表示と明るさ > 自動ロック

に選び「なし」に変更。その上で先のiPhoneのNextcloudアプリを開きっぱなしにしておきます。

可能であればワイヤレス充電でつけっぱなしにしておくと良いでしょう。

参考までに、宅内無線LAN環境、45,000枚ほどの画像の転送に10時間ほどかかりました。

※この作業が終わったら自動ロックの設定を元に戻すのを忘れないようにしましょう。

Nextcloud Ver 32にアップデート後、高性能バックエンドのDockerをアップデート。

警告: 実行中のバージョン: 2.0.4~docker; サーバーはこのTalkバージョンの全ての機能をサポートしていません。欠落している機能: chat-relay

と出たので、それに対応していきます。

環境

  • Nextcloud 33.0
  • Dockerを利用して高性能バックエンドサーバ(Signaling Server)を構築。構築手順
  • それ以外はLAMP環境。
    • Apache 2.4
    • MySQL
    • PHP-FPM
    • その上でNextcloud

アップデートは、こちらの手順で、コマンドラインから行いました。

その後、管理画面で上記のエラーが出たという次第です。

やっぱり必要なフェイズ・ゼロ

このNextcloudを個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。

  • NextcloudのアップデートによりDockerコンテナもアップデートが必要。
  • ついてはこの計画でサーバ設定を行う
  • そのため、追加で作業時間をいただきたい
  • 作業時間は○時頃、○分程度で終わる。その間、Nextcloudは使えなくなる
    など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。

※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。

さっくりとした手順

  1. Nextcloudのメンテナンスモードを有効化します。
  2. Dockerの設定ファイルを修正します。
  3. Dockerコンテナを最多値揚げします。
  4. Nextcloudのメンテナンスモードを無効化します。
  5. エラーの解消を確認します。

メンテナンスモードを有効化

  • Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)

  • メンテナンスモード有効化
sudo -u www-data php occ maintenance:mode --on
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。

設定ファイル (server.conf) の構成

  • ファイルのバックアップ
sudo cp -pi /hoge/docker/files/nextcloud-signaling/server.conf /path/to/backup/directory/server.conf.$(date +%Y%m%d)

自分の環境に合わせます。

  • ファイルのバックアップ確認
diff -u /path/to/backup/directory/server.conf.$(date +%Y%m%d) /hoge/docker/files/nextcloud-signaling/server.conf

差分がないことを確認します。

  • server.confファイル修正

chat-relay 機能を有効にするため、以下のように項目を付け加えます。

  • [chat] セクション(新規追記)
[chat]
enabled = true

追記したら保存を行います。

  • ファイル修正確認
diff -u /path/to/backup/directory/server.conf.$(date +%Y%m%d) /hoge/docker/files/nextcloud-signaling/server.conf

以下の差分を確認します。

+ [chat]
+ enabled = true

Docker アップデート・再起動

これが地味にハマりました。古い docker-compose (v1.29.x等) を使用している環境だと、イメージのメタデータ構造の違いによるエラー(KeyError: 'ContainerConfig')が発生。

それを避けるための手順です。

  • 最新イメージの直接取得

docker-compose を介さず、Docker本体で最新イメージをプルする。

sudo docker pull strukturag/nextcloud-spreed-signaling:latest
sudo docker pull nats:2.9
  • 不完全なコンテナの掃除

作成失敗などで残った残骸を削除し、競合を防ぐ。

sudo docker container prune -f
  • コンテナの起動
sudo docker-compose up -d

Nextcloudのメンテナンスモードの無効化

  • メンテナンスモード無効化
sudo -u www-data php occ maintenance:mode --off
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、管理画面に入ります。

Nextcloud管理画面での反映

Nextcloudの「設定」>「Talk」にある高性能バックエンド設定で、URL横の「チェックマーク(保存)」を押し、chat-relayAvailable features に含まれたことを確認して対処完了です。

改めて思ったこと

Dockerは確かに便利な代物ですが、管理が複雑になっていくというのが難点。それ故、Dockerは最小限にして登録していきたいものです。

Nextcloud、ドメイン変更時のメモ。

正直、かなり甘く見ていました。

やろうとしたこと

a.hoge.comというサブドメインでNextcloudを立ち上げて運用していたのですが、唐突にexample.comというネイキッドドメインで運用しようとしたのがきっかけ。

当初の手順

  1. DBバックアップ
  2. 設定ファイルバックアップ(apacheバーチャルサイトとNextcloudのconfファイル)
  3. 新DNSレコード変更
  4. apacheバーチャルサイトのURL変更およびSSL証明書の差し替え
  5. NextcloudのconfファイルのURL変更
  6. Apache / PHP-FPM再起動

まではすんなりいきました。

URL変更後の苦行

Nextcloudは単なるファイルストレージではなく、統合コラボスイート。非常に多岐にわたって運用していたんだと改めて痛感。

  • デスクトップクライアント
  • スマートフォンアプリ
  • ブックマークの変更

がそれなりにヘビー。それ以上にヘビーだったのが

  • 高性能バックエンド
  • AppAPI

の設定変更を忘れていたことでした。

DBと参照ディレクトリ変更の更なる苦行

また、動作確認後、「DBの向き先とNextcloud格納ディレクトリが新ドメインに即していない」ことがわかり、

  1. apacheのconfファイルをいったん無効化
  2. 再度DBバックアップ(サイト名などを変えていたため)
  3. DB及びユーザー新規作成作成
  4. 再バックアップしていたDBから新DBにデータ流し込み
  5. Nextcloud格納ディレクトリを-pirオプションをつけてコピー&リネーム
  6. Nextcloudのconfigを修正。DBのユーザ名とDB名を新しく作成したDBに変更
  7. ログ格納ディレクトリを新規作成、www-dataに所有者変更
  8. apacheのconfファイルの格納ディレクトリとログ格納ディレクトリの向き先変更
  9. /etc/logrotate.d配下のローテーションを新しいログ格納ディレクトリに変更
  10. apacheのconfファイル有効化
  11. apache再起動
  12. Nextcloudのcronを新ディレクトリに合わせる

までやって、完全移行が完成しました。

「サーバリプレースとどう違うのか」レベルではありましたが、うまくいって良かったです。

詳細な手順は相当なボリュームになりそうなので、様子を見て描いていきます。

Nextcloud Client 4.0.5アップグレードの失敗時の対応。

ローカルサーバに設置されているNextcloudを利用するためのデスクトップクライアント。

自動更新するはずが、以下のメッセージが出て

「再起動してアップデート」をクリックしても同じエラーが発生。

これの対処のメモです。

参考手順(というよりもリリース)

対処手順

タスクバーから「Nextcloudを終了」でアプリを終了します。

Nextcloud クライアント公式に飛びます。

v4.0.6以降をダウンロードして、インストーラーを実行します。

インストール終了後、上記エラーが出ないことを確認します。

メモ

  • クライアントを上書きするだけなのでデータや設定が吹き飛ぶことはありません。
  • 対処しないと延々と上記エラーが出続けてフラストレーションがたまります。
  • Nextcloudの設定に問題があるわけでもありません。

Nextcloud高性能バックエンドサーバ (Signaling Server) 構築メモ。

概要:

Nextcloudアップデート後に出るようになった

高性能バックエンドが構成されていません - 高性能バックエンドなしでNextcloud Talkを実行すると、非常に小規模な通話 (最大2~3人の参加者)でのみ利用できます。複数の参加者との通話がシームレスに機能するようにするためには高性能バックエンドを設定してください。

このメッセージを対処するため、「高性能バックエンドサーバ」とやらをインストールすることにします。

当初はこれは考慮していませんでした(個人用のファイルサーバとして使っていたため)が、

「自分の信条を曲げてまでDockerを入れてしまった以上、こいつもDockerで入れる」

と“それはそれ、これはこれ/That's another matter entirely, chaps."の精神でインストールしていきます。

これの導入により、何が変わるのか?

接続の安定化・高速化です。

これまでPHP(Nextcloud本体)が行っていた「誰と誰をつなぐか」という重い処理(シグナリング)を、専用のGo言語プログラム(高性能バックエンド)が肩代わりします。これにより、通話開始までの時間が短縮され、サーバー全体の負荷が劇的に下がります。

環境

  • Nextcloud 32.0.3
  • PHP 8.3
    • PHP-FPM 8.3
  • MySQL 8.0
  • Apache 2.4

さっくりとした手順

  1. 【コマンドライン】(オプション)docker-composeをインストールします。
  2. 【コマンドライン】レット文字列を生成します。
  3. 【コマンドライン】Dockerファイルを作成します。
  4. 【コマンドライン】コンテナを起動します。
  5. 【コマンドライン】Apache設定ファイルを編集します。
  6. 【Webブラウザ】動作を確認します。
  7. 【Webブラウザ】Nextcloud管理画面を設定します。

(オプション)docker-composeのインストール

sudo aptitude install docker-compose

筆者の好みでaptitudeを用いています。

シークレット文字列を生成します。

openssl rand -hex 16

4accc25d95464f00a9537dc956bd5414といった文字列が出ます。これを以下「共有シークレット」と呼びます。

Docker設定ファイルを作成します。

任意のコンテナ設定ファイル群に以下を作成します。

mkdir -p /path/to/container/directory/nextcloud-signaling
cd /path/to/container/directory/nextcloud-signaling && pwd

このディレクトリに入り、ファイルを作っていきます。

※ドメイン名などは自分の環境に合わせましょう。※

  • server.conf
[http]
listen = 0.0.0.0:8080

[app]

debug = false

[sessions]

# 手順1で生成した文字列を使用 hashkey = [共有シークレット] blockkey = [共有シークレット]

[backend]

# Nextcloud本体のURL backend = https://hoge.example.com # Docker内部からホストへのSSL検証をスキップ (接続エラー回避のため必須) allowall = true # 手順1で生成した文字列を使用 secret = [共有シークレット]

[nats]

url = nats://nats:4222

[mcu]

# 現時点ではJanus(MCU)は使用しないため無効化 # type = janus # url = ws://127.0.0.1:8188

※ これらシークレット文字列は、別個にしておいた方がより安全です。

-docker-compose.yml

version: '3.6'

services:
  nats:
    image: nats:2.9
    restart: always

  signaling:
    image: strukturag/nextcloud-spreed-signaling:latest
    restart: always
    ports:
      - "127.0.0.1:8080:8080" # ホストのApacheからのみアクセス許可
    volumes:
      - ./server.conf:/config/server.conf
    depends_on:
      - nats
    extra_hosts:
      # Docker内部から hoge.example.com を解決するためにホストIPを指定
      - "hoge.example.com:172.17.0.1"

※重要: extra_hosts には ip addr show docker0 で確認したホストIP (例: 172.17.0.1) を記述します。

Dockerファイルを起動します。

cd /path/to/container/directory/nextcloud-signaling && pwd

念のため、先ほど作成したディレクトリにいることを確認してください。

  • コンテナ起動
sudo docker-compose up -d
  • コンテナ起動確認
sudo docker ps

STATUS が UPになっていれば問題なく起動できています。

Nextcloudのバーチャルサイトの編集

  • バーチャルファイルのバックアップ
sudo cp -pi /etc/apache2/sites-available/nextcloud.conf /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d)

.confやバックアップディレクトリは自分の環境に合わせます。

  • バーチャルファイルのバックアップ確認
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

差分が無いことでバックアップを確認します。

  • ファイル編集

/etc/apache2/sites-available/nextcloud.conf を、任意の方法で編集します。(エディタという宗教問題が絡むため)

他のリダイレクト設定やセキュリティ設定(RewriteRuleなど)に干渉されないよう、<VirtualHost *:443> ブロック内のなるべく上の方に記述するのがコツです。

<VirtualHost *:443>
    # (その他既存の設定...)

    # ====================================================
    # Signaling Server 設定
    # ====================================================

    # 1. バックエンド(Docker)に正しいホスト名とプロトコルを伝える
    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto "https"

    # 2. プロキシ設定
    # "upgrade=websocket" オプションにより、http/ws を自動判別してヘッダーを渡す
    ProxyPass "/standalone-signaling/" "http://127.0.0.1:8080/" upgrade=websocket
    ProxyPassReverse "/standalone-signaling/" "http://127.0.0.1:8080/"

    # ====================================================

    # ... (これ以降にDocumentRootやセキュリティ設定が続く) ...
  • 編集後の差分確認
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

以下の差分を確認します。

+# ====================================================
+    # Signaling Server 設定
+    # ====================================================
+    # 1. バックエンド(Docker)に正しいホスト名とプロトコルを伝える
+    ProxyPreserveHost On
+    RequestHeader set X-Forwarded-Proto "https"
+
+    # 2. プロキシ設定
+    # "upgrade=websocket" オプションにより、http/ws を自動判別してヘッダーを渡す
+    ProxyPass "/standalone-signaling/" "http://127.0.0.1:8080/" upgrade=websocket
+    ProxyPassReverse "/standalone-signaling/" "http://127.0.0.1:8080/"
+    # ====================================================
+

設定反映

  • 整合性確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • apache再開前確認
systemctl status apache2.service

active(running)を確認します

  • apache再開
sudo systemctl restart apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します。

動作確認

ブラウザで、

https://hoge.example.com/standalone-signaling/api/v1/welcome

にアクセスし、{"nextcloud-spreed-signaling":"Welcome", ...}の表示が出ていればOKです。

Nextcoloud管理画面設定

Nextcloudに管理者ログインし、[管理設定] > [Talk] > [高性能バックエンド] を設定します。

  • 高性能バックエンドURL: https://hoge.example.com/standalone-signaling/
  • 共有シークレット: 手順1で生成した文字列
  • SSL証明書を検証する: チェックを入れる

設定後、「保存」ボタンをクリックします。 「OK: 実行中のバージョン: x.x.x~docker」 と表示されれば完了です。

FAQ

Q. Dockerを入れることでサーバそのものが高負荷になるということは?

A. むしろ逆で、サーバー全体の負荷は「劇的に下がります」。

  • これまで(高性能バックエンドなし):
    • Nextcloudの画面を開いている間、ブラウザは数秒おきに「着信はありますか?」「新しいチャットはありますか?」とサーバー(Apache/PHP)に聞きに行きます(ポーリング方式)。 そのたびに Apacheが動き、PHPが起動し、データベースに接続し… という重い処理が走っていました。これがサーバーを高負荷にする原因です。
  • これから(高性能バックエンドあり):
    • Docker(Go言語)が、ブラウザと「1本のパイプ(WebSocket)」を繋ぎっぱなしにします。 情報はパイプを通ってスッと届くため、「着信確認」のための無駄な処理がゼロになります。

Q. メモリは食いますか?

A. メモリは食いますが、CPUは休まります。

  • Dockerコンテナが常駐するため、約50MB〜100MB程度のメモリ を常に確保(占有)します。これは増えます。
  • しかし、上記の「無駄な確認作業」がなくなるため、CPUの利用率はガクンと下がります。 サーバーにとって一番きついのは「メモリを確保すること」ではなく「CPUをブン回すこと」なので、トータルではサーバーが楽になります。

もっとさっくり言うと:

  • 1. 以前(高性能バックエンドなし)
    • 動作: ブラウザが「ねえ、着信ある?」「ねえ、メッセージ来た?」と、数秒おきにApacheを叩き起こしていました。
    • 負荷: そのたびに、数十MBのメモリを使うPHPプロセス が起動し、データベースに接続し、確認して終了する…という「重い開け閉め」を繰り返していました。
  • 2. 現在(高性能バックエンドあり)
    • 動作: 今回導入した signaling コンテナ(7MB/筆者環境)が、ブラウザと細い糸電話(WebSocket)を繋ぎっぱなしにします。
    • 負荷: 何もなければただ待っているだけ(CPU 0.02%/筆者環境)。着信があった時だけ、「来たよ!」と一瞬で伝えます。

重たいApacheやPHPは、本当に必要な画面表示の時だけ働けば良くなったので、サーバー全体が静かになり、反応速度(レスポンス)が向上します。

Nextcloud 32.xにClient Pushを導入して高速化させる(Mod_Security導入状況で躓いたこと)

Nextcloud32.0.2にアップデート後に表示された際に出てきた

Client Push
Client Push is not installed, this might lead to performance issue when using desktop clients.

と出てきたので、これを導入しました。筆者のようにIP/クローラー制限やMod_Securityを利用している方でもなんとかなる手順にしています。

Client Push (notify_push) とは?

正式名称は「High Performance Back-end / notify_push」。
一言でいうと、「ファイルの変更をクライアントに『瞬時に』知らせる機能」です。

導入前と導入後の違い

郵便受けの確認に例えるとわかりやすいでしょう。

  • Client Pushなし(ポーリング方式)
    • クライアントが、30秒おきに「ねえ、何か新しいファイルある?」「変更ない?」とサーバーへ聞きに行きます。
    • デメリット: サーバーはずっと質問攻めにされます。また、変更があってから聞きに行くまでにタイムラグ(遅延)が発生します。
  • Client Pushあり(プッシュ方式)
    • クライアント~サーバーが専用のホットライン(WebSocket)で繋がりっぱなしになります。
    • サーバー上のファイルが変更された瞬間、サーバーから「変更あったよ!」と通知(プッシュ)します。
    • メリット: 変更が即座に反映されます。無駄な問い合わせがなくなるため、サーバーの負荷も下がります。

Client Pushは導入すべきか?

「必須ではありませんが、導入すると劇的に快適になります」

  • 個人利用:
    • PCで保存した写真がスマホに「パッ」と出るようになるので非常に快適です。
  • 複数人/組織利用:
    • 強く推奨します。多数のユーザーによる「変更ある?」というアクセス集中を防げるため、サーバー安定化に寄与します。

環境

  • Nextcloud 32.0.2
  • Ubuntu 24.04
  • Apache 2.4
  • MySQL 8.0
  • PHP 8.3 (PHP-FPM 8.3)

(再掲)フェイズゼロ:政治交渉

このNextcloudを個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。

  • Nextcloudの高速化に寄与するnotify_pushをサーバに入れる。
  • Apacheの設定変更を行う
  • ついてはこの計画でサーバ設定を行う
  • そのため、追加で作業時間をいただきたい
  • 作業時間は○時頃、○分程度で終わる。その間、Nextcloudは使えなくなる

など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。

※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。

もちろん、新サービス(Docker)の追加という文書管理も必要になっていきます。以下の手順は

  • 個人運用だからそもそも関係ない
  • フェイズゼロをクリアした

方向けの手順です。おそらく、組織でNextcloudを運用している方はここが一番のハードルだと思います。

さっくりとした手順

  1. 【Nextcloud Web画面】Client Pushをインストールします。
  2. 【コマンドライン】Nextcloudのメンテナンスモードを有効化します。
  3. 【コマンドライン】Apacheの設定ファイルを編集します。
  4. 【コマンドライン】Apacheの設定ファイルを反映させます。
  5. 【コマンドライン】Nextcloudのメンテナンスモードを無効化します。
  6. 【コマンドライン】notify_pushをサービス化します。
  7. 【コマンドライン】Nextcloudのconfigで、Trusted Proxyを有効化します。
  8. 【コマンドライン】Nextcloudのpushサービスを有効化します。
  9. 【Nextcloudクライアント】レスポンスの向上を確認します。

ClientPushのインストール

Nextcloudの管理者画面 >「アプリ」> 虫眼鏡アイコンで 「Client Push」を検索 > インストール・有効化します。

ここまでは単純です。

メンテナンスモードを有効化

  • Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)

  • メンテナンスモード有効化
sudo -u www-data php occ maintenance:mode --on
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。

Apache設定

Client Pushは「WebSocket」という特殊な通信を使用します。Apacheでこれを扱えるようにモジュールを有効化します。

sudo a2enmod proxy proxy_http proxy_wstunnel

念のため:apacheリスタート

  • apache再開前確認
systemctl status apache2.service

active(running)を確認します

  • apache再開
sudo systemctl restart apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します

このタイミングでサービス再起動が必要なのは何故かというと、

  • proxy
  • proxy_http
  • proxy_wstunnel

を有効化していないと、この後のApache設定変更時に「これらのモジュールが無い」とサーバは判断するからです。

Nextcloudのバーチャルサイトの編集

  • バーチャルファイルのバックアップ
sudo cp -pi /etc/apache2/sites-available/nextcloud.conf /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d)

.confやバックアップディレクトリは自分の環境に合わせます。

  • バーチャルファイルのバックアップ確認
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

差分が無いことでバックアップを確認します。

※余談:執拗なまでのバックアップ

「責任範囲を明確にするため」です。

設定ファイルというものは、どこかのミスであっという間に破綻する「すぐそこにある破滅」です。「起きてしまった破滅」からすぐリカバリーできるため、「何かあったときの責任者は誰か(芋を引くのはどいつか?)」を決める絶好の証拠になります。

○自分の設定でミスが起きた:潔く諦め、原状回復に努めましょう。
○誰かの設定ミス:追求や晒し上げは後にして、原状回復に努めましょう。責任者は誰かと追求してもサーバは止まり続けます。

ここで重要なのは、サービスが止まった「この時点で」重要なのは、「誰がやったか」ではなく「いかに早く復旧させるか」です。

  • ファイル編集

/etc/apache2/sites-available/nextcloud.conf を、任意の方法で編集します。(エディタという宗教問題が絡むため)

他のリダイレクト設定やセキュリティ設定(RewriteRuleなど)に干渉されないよう、<VirtualHost *:443> ブロック内のなるべく上の方に記述するのがコツです。

<VirtualHost *:443>
    # (その他既存の設定...)

    # ====================================================
    # Nextcloud Client Push (notify_push) 設定
    # ====================================================
    <Location /push>
        ProxyPass ws://127.0.0.1:7867/ws
        ProxyPassReverse ws://127.0.0.1:7867/ws
    </Location>

    ProxyPass /push/ http://127.0.0.1:7867/
    ProxyPassReverse /push/ http://127.0.0.1:7867/
    # ====================================================

    # ... (これ以降にDocumentRootやセキュリティ設定が続く) ...
  • 編集後の差分確認
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

以下の差分を確認します。

+# ====================================================
+# Nextcloud Client Push (notify_push) 設定
+# ====================================================
+    <Location /push>
+        ProxyPass ws://127.0.0.1:7867/ws
+        ProxyPassReverse ws://127.0.0.1:7867/ws
+    </Location>
+    
+    ProxyPass /push/ http://127.0.0.1:7867/
+    ProxyPassReverse /push/ http://127.0.0.1:7867/
+# ====================================================
+

設定反映

  • 整合性確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • apache再開前確認
systemctl status apache2.service

active(running)を確認します

  • apache再開
sudo systemctl restart apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します

Notifyデーモン(サービス)を作成します。

Client Pushは、Webサーバーとは別に裏方で動くプログラムです。これを常駐させるための設定ファイルを作成します。

  • ファイル作成

`/etc/systemd/system/notify_push.service`

を、任意の方法で作成します。

UserWorkingDirectoryExecStart のパスは、ご自身のNextcloudインストール環境(例: /var/www/nextcloudなど)に合わせて必ず修正してください。

[Unit]
Description = Nextcloud Client Push Node binary
After = network.target

[Service]
Type = simple
User = www-data
Group = www-data
# 【重要】環境に合わせて変更してください。特に、ExecStartは2カ所、修正箇所があります。
WorkingDirectory = /var/www/nextcloud
ExecStart = /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push /var/www/nextcloud/config/config.php
Restart = on-failure

[Install]
WantedBy = multi-user.target
  • サービス有効化
sudo systemctl daemon-reload
  • サービス起動
sudo systemctl enable --now notify_push
  • サービス起動確認
systemctl status notify_push.service 

active(running)を確認します

Trusted Proxiesの設定(どハマりした部分)

ここがつまずきポイントでした。

サーバーが自分自身のURL(https://your.domain.com)にアクセスした際、ネットワーク環境(ヘアピンNATなど)によっては一度外に出てグローバルIP経由で戻ってくる場合があります。

この場合、Nextcloudは「外部からのアクセス」とみなして通信を拒否してしまいます。これを防ぐため、config.php に自身のグローバルIPを信頼済みプロキシとして登録します。

  • configファイルのバックアップ
sudo cp -pi /path/to/nextcloud/root/config/config.php /path/to/backup/directory/config.php.$(date +%Y%m%d)

格納場所は自分の環境に合わせます。

  • 差分確認(※sudo付き)
sudo diff -u /path/to/backup/directory/config.php.$(date +%Y%m%d) /path/to/nextcloud/root/config/config.php

差分が無いことを確認します。

ここでsudoをつけるのは、NextcloudのファイルパーミッションがNextcloudの実行ユーザとrootしか読み取れないため(640)のためです。

Nextcloudの config/config.php を開き、trusted_proxies 配列に追記します。

  'trusted_proxies' => 
  array (
    0 => '127.0.0.1',
    1 => '::1',
    2 => '203.0.113.123',  // ← 【ここに追加】あなたのサーバーのグローバルIP
  ),
  • 差分確認(※sudo付き)
sudo diff -u /path/to/backup/directory/config.php.$(date +%Y%m%d) /path/to/nextcloud/root/config/config.php

以下を確認します。

+    2 => '203.0.113.123',

設定の手動登録

通常は occ notify_push:setup コマンドを使いますが、Bot検知やIP制限などのセキュリティ設定が厳しい環境では、接続テストで「403 Forbidden」や「404 Not Found」が出て失敗することがあります。

そのため、テストをスキップして強制的に設定値を登録するコマンドを使います。

sudo -u www-data php /var/www/nextcloud/occ config:app:set notify_push base_endpoint --value "https://your.domain.com/push"

URLはご自身のものに合わせてください。また、パス(/var/www/nextcloud)は環境に合わせて変更してください。

  • notify_pushサービス再起動
sudo systemctl restart notify_push
  • サービス起動確認
systemctl status notify_push.service 

active(running)を確認します。

確認

Nextcloudの管理画面(「概要」または「ログ」)を確認し、「Client Push」に関する警告が消えていれば導入成功です。

これでファイル同期が爆速になり、サーバー負荷も低減されているはずです。警告を消したいだけの場合でも、この手順を行っておけば「高セキュリティかつ高性能」な環境が手に入ります。

Nextcloud 32.xでAppAPIデプロイデーモンをDockerでインストール。

Nextcloudを32.0.2にアップデート後、以下のエラーを確認しました。

AppAPIデプロイデーモン
AppAPIデフォルトのデプロイデーモンが設定されていません。外部アプリ(Ex-Apps)をインストールするための設定で、デフォルトのデプロイデーモンを登録してください。

Mimetypeの移行が可能
1つ以上のmimetypeマイグレーションが利用できます。時折、特定のファイルタイプをよりよく扱うために新しいmimetypesが追加されます。大規模なインスタンスではmimetypesの移行に時間がかかるため、アップグレード時には自動的には行われません。移行を行うには occ maintenance:repair --include-expensive コマンドを使用してください。

データベースに存在しないインデックス
いくつかの欠落しているオプションのインデックスを検出しました。データベースのパフォーマンスを向上させるために、(Nextcloudまたはインストールされたアプリケーションによって)新しいインデックスが追加されることがあります。インデックスの追加には時間がかかり、一時的にパフォーマンスが低下することがあるため、アップグレード時には自動的には行われません。インデックスが追加されると、それらのテーブルへのクエリが速くなるはずです。インデックスを追加するには、occ db:add-missing-indices コマンドを使用してください。 インデックスが不足: "properties_name_path_user" テーブル内の "properties", "unique_category_per_user" テーブル内の "vcategory", "calobjects_by_uid_index" テーブル内の "calendarobjects"

これについて解消していきます。

環境

  • Nextcloud 32.0.2
  • Ubuntu 24.04
  • Apache 2.4
  • MySQL 8.0
  • PHP 8.3 (PHP-FPM 8.3)

フェイズゼロ:政治交渉

このNextcloudを個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。

  • NextcloudのアップデートによりDockerコンテナが必要になった。
  • ついてはこの計画でサーバ設定を行う
  • そのため、追加で作業時間をいただきたい
  • 作業時間は○時頃、○分程度で終わる。その間、Nextcloudは使えなくなる

など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。

※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。

もちろん、新サービス(Docker)の追加という文書管理も必要になっていきます。以下の手順は

  • 個人運用だからそもそも関係ない
  • フェイズゼロをクリアした

方向けの手順です。おそらく、組織でNextcloudを運用している方はここが一番のハードルだと思います。

さっくりとした手順

  1. Nextcloudのメンテナンスモードを有効化します。
  2. Dcokerをインストールします。
  3. Dockerの起動と自動起動設定を行います。
  4. Docker Socket Proxyのコンテナを立ち上げます。
  5. Nextcloudのメンテナンスモードを無効化します。
  6. NextcloudでDockerデーモンを登録します。
  7. ついでに他のエラーも解消します。
  8. エラーの解消を確認します。

正直、筆者はDockerを信用していませんが「必要ならば入れるまで」です。

メンテナンスモードを有効化

  • Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)

  • メンテナンスモード有効化
sudo -u www-data php occ maintenance:mode --on
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。

Dockerのインストールを行います。

AppAPIは、背後でDockerコンテナを立ち上げてアプリケーションを実行します。まずはUbuntuサーバー自体にDockerが入っているか確認し、なければインストールします。

  • パッケージ全体のアップデート
sudo aptitude update

※筆者の好みでaptitudeを用いています。好みに応じてaptに読み替えてください。

  • Dockerのインストール
sudo aptitude install docker.io
  • Docker有効化
sudo systemctl start docker
  • Dockerの自動起動
sudo systemctl enable docker
  • Dockerのサービス状況確認
systemctl status docker.service docker.socket 

active(running)enabledを確認します。

Docker Socket Proxyのセットアップ

NextcloudはApacheユーザー(通常 www-data)で動作していますが、Dockerは roto 権限で動いています。NextcloudからDockerを安全に操作させるために、Docker Socket Proxy という中継役のコンテナを立ち上げるのが推奨される方法です。

  • Docker Socket Proxy (socat) を起動
sudo docker run -d \
  --name nextcloud_app_api_dsp \
  --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -p 2375:2375 \
  alpine/socat \
  tcp-listen:2375,fork,reuseaddr unix-connect:/var/run/docker.sock
  • 稼働中のコンテナ一覧を見る
sudo docker ps

出力されたリストの中に、以下の特徴があれば成功です。

  1. NAMES: nextcloud_app_api_dsp という名前がある。
  2. STATUS: Up X secondsUp X minutes となっている。(ここが Exited だと停止しています)
  3. PORTS: 0.0.0.0:2375->2375/tcp のようにポートが表示されている。

※出力例:

CONTAINER ID   IMAGE          STATUS          PORTS                    NAMES
a1b2c3d4e5f6   alpine/socat   Up 2 minutes    0.0.0.0:2375->2375/tcp   nextcloud_app_api_dsp

  • ポートが開いているか確認する

OS側から見て、ポート2375番が待受状態になっているか確認します。

ss -nlt | grep 2375

※成功時の表示例:

LISTEN 0      512          0.0.0.0:2375        0.0.0.0:

※注意: 2375ポートは内部アクセス専用とし、外部公開しないようFW設定を確認してください

これが出ていれば、Nextcloudからの接続を受け付ける準備が完了しています。

  • もし「動いていない(表示されない)」場合

sudo docker ps で何も表示されない場合は、起動に失敗して終了してしまった可能性があります。その場合は以下でエラー原因を確認します。

  • 停止したものも含めて表示
sudo docker ps -a
  • ログ(エラー内容)を表示
sudo docker logs nextcloud_app_api_dsp

※よくあるエラー:
もしログに permission denied と出る場合は、Docker自体へのアクセス権限の問題ですが、今回の sudo docker run で実行していればこの動作は置きにくいでしょう。

  • メンテナンスモード無効化
sudo -u www-data php occ maintenance:mode --off
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、管理画面に入ります。

NextcloudでDockerデーモンを登録します。

管理者権限でNextcloudにログインし、

管理 > AppAPI

に進みます。

Deploy Daemonsの項目の+デーモンを登録に進みます。

以下のように設定します。

  • Daemon configuration template
    • Docker Socket Proxy を選択。
  • 名前
    • docker_socket_proxy (デフォルトのままでOK)
  • 表示名
    • Docker Socket Proxy (デフォルトのままでOK)
  • Deployment method
    • docker-install (デフォルトのままでOK)
  • Daemon host
    • localhost:2375
    • → ここはデフォルトと異なります。せっかくDockerを自サーバ(localhost)に接続したのですから、localhostを入れましょう。
  • Haproxyパスワード
    • HaProxyパスワード」に入っている黒丸(……)をすべて消して空白にします。
    • 先ほどコマンドで立ち上げた alpine/socat というコンテナは、パスワード認証機能を持たないシンプルな「通信中継(土管)」です。そのため、「HaProxyパスワード」という項目は、今回の構成(Docker Socket Proxy)では無視されます。(HaRP Proxyなどもっと複雑な構成で使用します)
  • Nextcloud URL
    • 管理しているNextcloudのURLを入れます。

このあと、「Check connection」をクリックします。「Daemon connection successful」と出たら「Register」をクリックします。

他のエラーの解消

  • MymeTypeの登録

再びNextcloudがインストールされているWebサーバに接続します。

  • Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)

sudo -u www-data php occ maintenance:repair --include-expensive
  • インデックスの追加

先ほどのNextcloudのルートディレクトリのまま実行します。

sudo -u www-data php occ db:add-missing-indices

念のため:apacheリスタート

  • apache再開前確認
systemctl status apache2.service

active(running)を確認します

  • apache再開
sudo systemctl restart apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します

エラーの解消を確認します。

管理者権限でNextcloudにログインし、

AppAPIデフォルトのデプロイデーモンはHaRPを使用していません。パフォーマンス向上のため、アップグレードをご検討ください。

とメッセージが警告に変わっていればOKです。

この作業に関するFAQ

Dockerインストールによるメモリ消費量は大丈夫か?

全く問題ありません。誤差レベルです。

今回使用する alpine/socat というコンテナは、非常に軽量なことで有名な「Alpine Linux」というOSをベースに、socat という単純な転送プログラムだけが動いています。

  • 消費メモリ:
    • およそ 2MB ~ 6MB程度です。
  • CPU負荷:
    • 待機時はほぼ 0%です。

サーバー全体のメモリが数GBある環境であれば、このコンテナの存在に気づかないレベルの軽さですので、ご安心ください。

サーバ再起動時、Dockerの設定が消えるのではないか?

このコンテナに関しては、「データが消えても問題ない(そもそもデータを保存しない)」仕組みになっているため、大丈夫です。

なぜ消えても大丈夫なのか(仕組みの解説)

このコンテナ nextcloud_app_api_dsp は、「土管(パイプ)」のような役割しかしていません。

  • データの保存場所:
    -「どのデーモンを使うか」という設定情報は、このコンテナの中ではなく、Nextcloud本体のMySQLデータベースに保存されます。今後インストールする外部アプリ(AIなど)のデータも、Nextcloudのストレージ領域に保存されます。
  • このコンテナの役割:
    • Nextcloud(Webサーバー)からの命令を、Ubuntu本体のDockerシステムに「中継」するだけです。中継役なので、自分自身は何も記憶する必要がありません。
  • 再起動時の挙動:
    • Docker立ち上げ時、コマンド内の --restart always というオプションのおかげで、Ubuntuサーバーを再起動すると、このコンテナも自動的に「新品の状態」で立ち上がります。立ち上がった瞬間から、再び「中継役(土管)」としての仕事を再開します。前回の中身を覚えている必要がないため、これで正常に動作します。

まとめ

  • メモリ: スマートフォンの写真1枚分(数MB)しか使いません。
  • 保存: このコンテナは「ただの通信ケーブル」のようなものなので、記憶を保持する必要がなく、再起動してもNextcloud側の設定(DB)が残っている限り繋がり続けます。

Page 1 of 6

Powered by WordPress & Theme by Anders Norén