NextcloudでZimaOSにホームクラウドのファイル同期を設定する

Nextcloudは要求されたセントラルクラウドモデルに適しているが、SQLiteは長期運用のデフォルトではない

ユーザーは、3つのアカウント、Webインターフェース、スマートフォンからのアップロード、そして1台のホームサーバーからのデスクトップ同期を求めています。これはセントラルクラウドモデルであるため、Nextcloudは、Syncthingのデバイス間設計よりも要件に適しています。このスレッドでは、基本的なNextcloudのSQLiteインストールは起動した一方、ownCloudはApp Storeからのインストールを完了できず、OpenCloudは未解決のままだったことが確認されています。

ただし、SQLiteに関するスレッド内の安心材料は、Nextcloud公式の案内より踏み込んでいます。Nextcloudのデータベース選択ガイドでは、SQLiteは最小構成または開発用インスタンス向けであり、クライアントがファイル同期を行う場合は強く推奨されないと説明されています。3ユーザーで長期運用する同期サービスでは、パッケージが対応しているなら最初からMariaDBまたはPostgreSQLを使用してください。SQLiteを使う場合は、移行計画とバックアップ計画を用意したうえで、意図的な試用に限定しましょう。

インストールのトラブルシューティングより先に、ワークフローで選ぶ

各ユーザーにアカウント、ブラウザーアクセス、共有、モバイルからのアップロード、そして1台の権威あるサーバーが必要なら、Nextcloudを選びます。信頼できるデバイス間で選択したフォルダーを複製することが本当の目的で、中央集約型のWebクラウド体験が不要なら、Syncthingを選びます。これらは互換性のある外観違いではなく、異なる運用モデルです。

このスレッドだけを根拠に、OpenCloudやownCloud全般に問題があると結論付けないでください。ユーザーはOpenCloudのエラーを提示しておらず、ownCloudのスクリーンショットも、原因が確認されていない未完了のインストールを示しているにすぎません。パッケージを変更する前に、最初に失敗した手順、イメージのバージョン、ボリュームマッピング、アプリケーションログを記録してください。

信頼できる家庭用サービスを必要とする初心者は、構成要素を減らしましょう。つまり、対応済みのアプリ定義を1つ、データベースパスを1つ、データパスを1つ、ホスト名を1つ、そしてバックアップ手順を1つにします。AIが生成したインストール手順と、別のGitHub Composeファイルを組み合わせる場合は、すべての設定を突き合わせて整合性を確認しない限り避けてください。

ZimaOS App StoreでownCloudのインストールが完了しない状態 — このスクリーンショットは1件のインストール失敗を記録していますが、スレッドから根本原因は特定できません。

Nextcloudの初期設定を完了する前に永続ストレージを割り当てる

Nextcloudのウェルカムページで指定できるのはコンテナ内のパスであり、任意のZimaOSホストパスではありません。コンテナに対応するマウントがない状態で /DATA/... と入力すると失敗します。まず、ZimaOSの「Apps → Nextcloud → Settings → Volumes」でマッピングを設定してください。

ホスト上の専用RAIDフォルダーを、Nextcloudコンテナが使用するデータディレクトリにマッピングします。今回説明しているイメージでは、通常 /var/www/html/data です。その後、ウェルカムページではコンテナ内部のこのパスをそのまま使用します。Dockerがマウントを通じて書き込みを永続ストレージへ転送します。

ユーザーを追加する前に、所有者設定と空き容量を確認してください。テストファイルを作成し、マッピング先のホストストレージに表示されることを確認してから、コンテナを再起動し、もう一度開きます。すでにデータが入っているディレクトリを、config.phpだけを編集して移動しないでください。データベースとファイルシステムの状態を一致させておく必要があります。

NextcloudのウェルカムページがZimaOSのホストパスを拒否している状態 — 初期設定画面が認識するのはコンテナ内のパスです。ホストのRAIDパスは、まずコンテナレベルでマウントする必要があります。

サービスの運用期間に合ったデータベースとバックアップ計画を使用する

実験用または最小構成の個人インスタンスでは、SQLiteによってセットアップ作業を減らせます。ただし、複数ユーザーがデスクトップ同期を定期的に行い、Nextcloudアプリを追加する場合は、上流の案内に従い、最初からMariaDBまたはPostgreSQLを構成してください。データベースに関する警告は、直ちに破損する証拠ではありません。しかし、容量と同時実行性の境界として尊重すべきものです。

ユーザーデータディレクトリとデータベースの状態の両方を永続化してください。アップロードしたファイルだけをコピーしても、Nextcloudの完全なバックアップにはなりません。共有、ユーザー、バージョン、アプリの状態、ファイルメタデータはデータベースに保存されているためです。サービスを唯一のコピーに託す前に、別の場所への復元をテストしてください。

スマートフォンからのアップロードやアプリを有効にした後は、ストレージの増加とバックグラウンドジョブを監視してください。すでにSQLiteを使用している場合、データベースファイルを手動で入れ替えないでください。検証済みのバックアップを作成したうえで、Nextcloudがサポートするデータベース変換手順に従ってください。

同期エンジンの競合を起こさずにクライアントを接続する

最終的なHTTPSホスト名に対して、公式のNextcloudデスクトップクライアントまたはモバイルクライアントを使用してください。リバースプロキシでTLSを終端する場合は、実際のプロキシアドレスを trusted_proxies に設定し、ヘッダーの検出に必要な場合に限って上書きパラメーターを使用します。プロキシが実際にローカルホストから接続している場合を除き、127.0.0.1 をそのままコピーしないでください。

このスレッドでは、Nextcloudの同期先をアクティブなOneDriveフォルダーに指定した結果、そのワークステーション上のOneDriveに深刻な支障が生じたと報告されています。2つの同期エンジンが同じツリー内で動作すると、名前の変更、ロック、重複排除、削除を互いに行う可能性があります。移行方法として、稼働中のフォルダーを重複させないでください。

移行する場合は、一方のクライアントを一時停止し、データをステージングフォルダーにコピーして、件数とハッシュ値を確認します。その後、1つの権威ある同期エンジンの管理下にアップロードまたは移動してください。ほかの家庭内ユーザーを登録する前に、1つのアカウントで競合ファイル、名前の変更、オフライン編集、再起動をテストします。