Nextcloud

Nextcloud は、いわゆるアプリによって、あらゆる種類の共有、コラボレーション、コミュニケーションを可能にするクライアントサーバーソフトウェア群です。例えば:

ファイル共有
個人情報管理 (連絡先、カレンダー、タスク)
メッセージング (メール, チャット、ビデオ会議)
文書の共同編集 (テキスト, Office 統合)

Nextcloud はオープンソースであり、オープンスタンダードに基づいています。データ主権は大きな利点です。つまり、Nextcloud の独自のインスタンスを使用すると、Dropbox、Office 365、Google Drive などの独自の (そして潜在的に信頼できない) サービスから解放されます。

ニーズに応じて、Nextcloud はシングルボードコンピューター (Raspberry Pi など) から数百万のユーザーにサービスを提供する本格的なデータセンターまで展開できます。Nextcloud は、綿密な認証スキームとフェデレーション (個別のインスタンスの接続) のオプションを備えており、エンタープライズ環境での使用に適しています。

Nextcloud は ownCloud のフォークです。ウィキペディアの歴史を参照してください。

1 セットアップの概要
2 インストール
3 設定
4 データベース
- 4.1 MariaDB / MySQL
- 4.2 PostgreSQL
5 アプリケーションサーバー
- 5.1 uWSGI
  - 5.1.1 nextcloud.ini
  - 5.1.2 uWSGI サービス
- 5.2 FPM
6 Web サーバー
- 6.1 nginx
- 6.2 Apache HTTP server
7 バックグラウンドジョブ
8 In-memory キャッシュ
9 同期
10 ヒントとテクニック
11 トラブルシューティング
12 参照

セットアップの概要

Nextcloud の完全なインストールには、(少なくとも) 次のコンポーネントが含まれます。

データベース を使用して Nextcloud (つまり、PHP コード) を実行する アプリケーションサーバー とペアになった Web サーバー

この記事では、データベースとして MariaDB/MySQL および PostgreSQL と、Web サーバーとアプリケーションサーバーの次の組み合わせについて説明します。

nginx → uWSGI (および uwsgi-plugin-php)
nginx → FPM,
Apache HTTP サーバー (mod_proxy_uwsgi を使用) → uWSGI (および uwsgi-plugin-php)
Apache HTTP サーバー (mod_proxy_fcgi を使用) → FPM

Nextcloud パッケージはウェブアプリケーションパッケージガイドラインに準拠しています。これにより、特に、専用ユーザー (この場合は nextcloud) で Web アプリケーションを実行することが義務付けられます。これが、ここでアプリケーションサーバーが登場する理由の 1 つです。まったく同じ理由で、php-apache を使用して Apache プロセスで Nextcloud の PHP コードを直接実行することはできなくなりました。

インストール

ノート: パッケージ nextcloud (メタパッケージ php-interpreter への依存関係による) は、php の上に Nextcloud のインストールを構築するか、またはパッケージ php-legacy 安全のために php-legacy を選択することを強くお勧めします。詳細については、php-legacy への移行を参照してください。この記事の残りの部分では、php-legacy を使用したインストールを想定しています。

nextcloud パッケージをインストールします。尋ねられたら、PHP バージョンとして php-legacy を選択します。これにより、かなりの数の依存パッケージが取り込まれます。すべての必要な PHP 拡張機能はこの方法で処理されます。

プレビュー生成用にパッケージ php-legacy-imagick と librsvg を追加インストールすることをお勧めします (できれば pacman オプション --asdeps を使用した依存パッケージとして)。他のオプションの依存関係については、具体的な設定 (選択したデータベースなど) に応じて後で説明します。

設定

PHP

このガイドは、PHP の中央構成ファイル /etc/php-legacy/php.ini を改ざんするものではなく、他の PHP ベースのアプリケーションの設定に干渉する可能性のない場所に Nextcloud 固有の PHP 構成を配置します。これらの場所は次のとおりです。

/etc/webapps/nextcloud/php.ini 内の php.ini の専用コピー (occ コマンドラインツールとバックグラウンドジョブ用)
アプリケーションサーバーの構成における対応する設定。これらについては、アプリケーションサーバーに関するセクションで説明します。

/etc/php-legacy/php.ini のコピーを /etc/webapps/nextcloud に作成します。厳密に必要というわけではありませんが、コピーの所有権を変更します。

# chown nextcloud:nextcloud /etc/webapps/nextcloud/php.ini

Nextcloud のインストール手順にリストされている前提条件のほとんどは、ベア PHP インストールですでに有効になっています。さらに、次の拡張機能を有効にします。

/etc/webapps/nextcloud/php.ini

extension=bcmath
extension=bz2
extension=exif
extension=gd
extension=iconv
extension=intl
extension=sysvsem
; in case you installed php-imagick (as recommended)
extension=imagick

date.timezone を希望のタイムゾーンに設定します。例:

/etc/webapps/nextcloud/php.ini

date.timezone = Europe/Berlin

PHP のメモリ制限を少なくとも 512MiB に引き上げます。

/etc/webapps/nextcloud/php.ini

memory_limit = 512M

オプション: セキュリティを強化するには、open_basedir を構成します。これにより、Nextcloud の PHP コードがファイルを読み書きできる場所が制限されます。実証済みの設定は、

/etc/webapps/nextcloud/php.ini

open_basedir=/var/lib/nextcloud:/tmp:/usr/share/webapps/nextcloud:/etc/webapps/nextcloud:/dev/urandom:/usr/lib/php-legacy/modules:/var/log/nextcloud:/proc/meminfo:/proc/cpuinfo

設定する追加の拡張機能に応じて、このリストを拡張する必要がある場合があります (例: Redis を選択した場合は /run/redis)

この php.ini は、occ コマンドラインツールとバックグラウンドジョブ、つまり短時間実行される PHP プロセスによってのみ使用されるため、ここで opcache を設定する必要はありません。

Nextcloud

次のエントリを Nextcloud の設定ファイルに追加します。

/etc/webapps/nextcloud/config/config.php

'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => 'cloud.mysite.com',
  ),    
'overwrite.cli.url' => 'https://cloud.mysite.com/',
'htaccess.RewriteBase' => '/',

指定されたホスト名例 cloud.mysite.com を変更します。Nextcloud インストールがサブフォルダー経由でアクセスできる場合 (例: https://www.mysite.com/nextcloud) overwrite.cli.url htaccess.RewriteBase はそれに応じて変更する必要があります。

システムと環境

Nextcloud 固有の php.ini が occ ツールで使用されるようにするには、環境変数 NEXTCLOUD_PHP_CONFIG を設定します。

$ export NEXTCLOUD_PHP_CONFIG=/etc/webapps/nextcloud/php.ini

また、この設定を永続的にするには、この行を .bashrc (または .bash_profile ) に追加します。

プライバシーとセキュリティの予防措置として、セッションデータ用の専用ディレクトリを作成します。

# install --owner=nextcloud --group=nextcloud --mode=700 -d /var/lib/nextcloud/sessions

データベース

MariaDB/MySQL は Nextcloud の標準的な選択肢です。

MySQL または MariaDB データベースが推奨されるデータベースエンジンです。[1]

Nextcloud のデータベースに関するほとんどの情報は、MariaDB/MySQL を扱います。Nextcloud 開発者は、[2] があることを認めています。他のデータベースでは、あまり詳細な専門知識がありません。

PostgreSQL は、MariaDB/MySQL と比較してパフォーマンスが向上し、全体的に癖が少ないと言われています。SQLite は主にテスト/開発インストールでサポートされており、運用環境では推奨されません。サポートされるデータベースのリストには、Oracle データベースも含まれています。この製品についてはここでは扱いません。

MariaDB / MySQL

2013 年以降、MariaDB が Arch Linux のデフォルトの MySQL 実装になっているため [3] 、このテキストでは MariaDB についてのみ言及しています。

Nextcloud と同じホストでデータベースを実行する場合は、configure および起動 mariadb をインストールします (まだ実行していない場合)。詳細については、対応する article を参照してください。mariadb-install-db で MariaDB を初期化することを忘れないでください。セキュリティを強化するために、MariaDB をローカルの Unix ソケットでのみリッスンするように設定することをお勧めします。

/etc/my.cnf.d/server.cnf

[mysqld]
skip_networking

Nextcloud 独自のドキュメントを推奨では、トランザクション分離レベルを READ-COMMITTED に設定します。これは、多くの同時トランザクションによる高負荷が予想される場合に特に重要です。

/etc/my.cnf.d/server.cnf

[mysqld]
transaction_isolation=READ-COMMITTED

binlog_format=ROW を設定するというもう 1 つの推奨事項は廃止されました。最近の MariaDB バージョンのデフォルトの MIXED は、推奨される ROW と少なくとも同じくらい優れています。いずれの場合も、設定はレプリケーションが適用される場合にのみ関係します。

データベースをユーザー root で CLI ツール mysql を起動します。(デフォルトのパスワードは空ですが、できるだけ早く変更してください。)

$ mysql -u root -p

Nextcloud のユーザーとデータベースを作成します。

CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'db-password';
CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL PRIVILEGES on nextcloud.* to 'nextcloud'@'localhost';
FLUSH privileges;

(db-password は、選択する必要がある DB ユーザー nextcloud の実際のパスワードのプレースホルダーです。) \q でツールを終了します。

ノート: MariaDB は、UTF8 の意味についての理解に欠陥があり、その結果、コードポイント 0x10000 以上の文字 (絵文字など) を保存できなくなります。彼らは、utf8mb4 と呼ばれる新しいエンコーディングを導入することにより、バージョン 5.5 でこの問題を修正しました。結論: MariaDB の utf8 は決して使用せず、常に utf8mb4 を使用してください。移行が必要な場合は、[4] を参照してください。

Nextcloud インストールのデータベースとして MariaDB を使用することに決めたので、対応する PHP 拡張機能を有効にする必要があります。

/etc/webapps/nextcloud/php.ini

extension=pdo_mysql

これ以上の設定 (MariaDB に関連する) は必要ありません (Nextcloud の [5] に記載されている情報とは異なります) データベース管理者マニュアル])

次に、Nextcloud のデータベーススキーマを次のように設定します。

$ occ maintenance:install \
    --database=mysql \
    --database-name=nextcloud \
    --database-host=localhost:/run/mysqld/mysqld.sock \
    --database-user=nextcloud \
    --database-pass=db-password \
    --admin-pass=admin-password \
    --admin-email=admin-email \
    --data-dir=/var/lib/nextcloud/data

プレースホルダー (例: db-password) に注意して、適切な値に置き換えてください。このコマンドは、データベースを Nextcloud と同じホスト上で実行していることを前提としています。occ help maintenance:install と入力し、他のオプションについては Nextcloud のドキュメントを参照してください。このツールに関する Arch 固有の詳細については、"occ" コマンドラインツールの使用を参照してください。

PostgreSQL

PostgreSQL の詳細については、対応する article を参照してください。 Nextcloud と同じホストでデータベースを実行する場合は、設定および postgresql を起動 (まだ実行していない場合) をインストールします。このシナリオでのセキュリティを強化するには、PostgreSQL をローカルの UNIX ソケットでのみリッスンするように構成することをお勧めします。

/var/lib/postgres/data/postgresql.conf

listen_addresses = ''

特に、initdb を使用してデータベースを初期化することを忘れないでください。それが完了したら、PostgreSQL の CLI ツール psql を起動します。

$ sudo -u postgres -- psql

そして、データベースユーザー nextcloud と同じ名前のデータベースを作成します

CREATE USER nextcloud WITH PASSWORD 'db-password';
CREATE DATABASE nextcloud TEMPLATE template0 ENCODING 'UNICODE';
ALTER DATABASE nextcloud OWNER TO nextcloud;
GRANT ALL PRIVILEGES ON DATABASE nextcloud TO nextcloud;
\q

(db-password は、選択する必要があるデータベースユーザー nextcloud のパスワードのプレースホルダーです。)

追加パッケージ php-pgsql を依存関係としてインストールし (pacman オプション --asdeps)、/etc/webapps/nextcloud/php.ini で対応する PHP 拡張機能を有効にします。

/etc/webapps/nextcloud/php.ini

extension=pdo_pgsql

Now setup Nextcloud's database schema with:

$ occ maintenance:install \
    --database=pgsql \
    --database-name=nextcloud \
    --database-host=/run/postgresql \
    --database-user=nextcloud \
    --database-pass=db-password \
    --admin-pass=admin-password \
    --admin-email=admin-email \
    --data-dir=/var/lib/nextcloud/data

プレースホルダー (例: db-password) に注意して、適切な値に置き換えてください。このコマンドは、データベースを Nextcloud と同じホスト上で実行していることを前提としています。occ help maintenance:install と入力し、他のオプションについては Nextcloud のドキュメントを参照してください。このツールに関する Arch 固有の詳細については、"occ" コマンドラインツールの使用を参照してください。

アプリケーションサーバー

PHP コードの処理に使用できる一般的なアプリケーションサーバーは uWSGI または FPM の 2 つです。FPM はPHPに特化したものです。Web サーバーと FPM の間で使用されるプロトコルは fastcgi です。このツールのドキュメントには改善の余地があります。一方、uWSGI は、言語固有のプラグインを使用して、少数の言語で記述されたコードを提供できます。使用されるプロトコルは uwsgi(小文字)です。このツールは広範囲に文書化されていますですが、膨大な量の文書が混乱を招き、扱いにくくなる可能性があります。

uWSGI

uWSGI には独自の article があります。そこでは役立つ情報がたくさん見つかります。uwsgi とプラグイン uwsgi-plugin-php-legacy を、できれば依存関係として、つまり --asdeps とともにインストールします。Nextcloud のコードを uWSGI で (または uWSGI 内で) 実行するには、1 つの uWSGI 固有の構成ファイル (nextcloud.ini) を構成し、1 つの systemd サービスを定義する必要があります。

警告: 最近、uWSGI、特にその PHP プラグインのメンテナンスがまばらになっていることに言及しなければなりません[6] これはすでにの問題を引き起こしており、Arch Linux パッケージの管理者 (アップストリームではない) が uWSGI コードにパッチを適用することによってのみ解決できます。

nextcloud.ini

nextcloud パッケージには、適切な場所 /etc/uwsgi/nextcloud.ini にサンプル構成ファイルがすでに含まれています。ほとんどの場合、このファイルを要件と設定に適合させる必要があります。バージョンに多くのコメント付き変更が含まれているを見つけます (パッケージのバージョンと比較) これは、個人使用 (つまり、中程度の負荷) を目的とした、シンプルな Nextcloud インストールを前提としています。

一般に、有効な拡張機能、拡張機能固有の設定、および open_basedir を /etc/webapps/nextcloud/php.ini と同期させます (opcache を除く)

ヒント: /etc/uwsgi/nextcloud.ini への変更は広範囲になる可能性があります。パッケージ nextcloud によって提供される元のファイルに変更があった場合に備えて、パッケージの更新中に nextcloud.ini.pacnew という名前のファイルが作成されます。この後者のファイルの変更をより適切に追跡し、それらを /etc/uwsgi/nextcloud.ini に適用するには、次のアプローチを適用できます。:

パッケージによって提供されるファイルのコピーを (パッケージから抽出するなどして) 作成し、それを nextcloud.ini.package として保存します。
パッケージ nextcloud の更新により nextcloud.ini.pacnew が生成される場合は、diff nextcloud.ini.package nextcloud.ini.pacnew で変更を識別できます。
ご使用のバージョンに適しているかどうかに応じて、変更を nextcloud.ini に選択的に適用します。

uWSGI サービス

uwsgi パッケージは、テンプレートユニットファイル (uwsgi@.service) を提供します。インスタンス ID (ここでは nextcloud) は、適切な構成ファイルを選択するために使用されます。 uwsgi@nextcloud.service を有効化および起動します。

このように開始されたサービスが複数 (例: 2 つ) あり、これがリソースの無駄であると感じた場合は、emperor モードの使用を検討してください。

FPM

アプリケーションサーバーとして FPM を使用する場合は、php-legacy-fpm を依存パッケージ (--asdeps) としてインストールしてください。

構成は、FPM によって提供されるすべてのアプリケーションに関連する php.ini のコピーと、アプリケーション (ここでは Nextcloud) に固有のいわゆるプールファイルで構成されます。最後に、systemd サービスファイルを調整する必要があります。

php-fpm.ini

前に述べたように、この記事では、/etc/php-legacy/php.ini にある PHP の中央設定の変更を回避しています。代わりに、FPM 固有のコピーを作成します。

# cp /etc/php-legacy/php.ini /etc/php-legacy/php-fpm.ini

所有者であり、root のみが書き込み可能であることを確認してください (-rw-r--r-- 1 root root ... php-fpm.ini) 演算キャッシュを有効にします。つまり、行のコメントを解除します。

/etc/php-legacy/php-fpm.ini

;zend_extension=opcache

そして、次のパラメータを既存の行 [opcache] の下に配置します。

/etc/php-legacy/php-fpm.ini

opcache.enable = 1
opcache.interned_strings_buffer = 8
opcache.max_accelerated_files = 10000
opcache.memory_consumption = 128
opcache.save_comments = 1
opcache.revalidate_freq = 1

警告: php_value[...] および php_flag[...] を使用してこれらの設定をプールファイルに入れようとしないでください。FPM プロセスは、最初のリクエストで常にクラッシュします。

nextcloud.conf

次に、FPM 用のいわゆるプールファイルを作成する必要があります。これは、Nextcloud アプリケーション用の専用の FPM プロセスを生成する役割を果たす。ファイル /etc/php-legacy/php-fpm.d/nextcloud.conf を作成します - これが機能バージョンを開始点として使用できます。

もう一度、このプールファイルが root によって所有され、書き込み可能であることを確認してください (つまり、-rw-r--r-- 1 root root ... nextcloud.conf) アクセスログが設定されているかどうかに応じて (上記のサンプル nextcloud.conf の場合)、対応するディレクトリを作成する必要がある場合があります (ここでは {{ic|/var/log/php-fpm-legacy/access}) }) 好みに合わせて設定 (特に pm...、php_value[...]、および php_flag[...]) を調整または追加します。php_value[...] および php_flag[..] の設定は、/etc/webapps/nextcloud/php.ini の対応する設定と一致している必要があります。(ただし、/etc/php-legacy/php-fpm.ini ではありません)

php_value[...] および php_flag[...] によって行われた設定は、代わりに php-fpm.ini で指定できます。ただし、php-fpm.ini の設定は、FPM によって提供されるすべてのアプリケーションに適用されることに注意してください。

ヒント: パッケージ php-legacy-fpm には独自のプールファイル www.conf が付属していますが、ここではほとんど役に立ちません。これを取り除く良い方法は、名前を www.conf.package に変更し、コメント行 (セミコロンで始まる行) だけを含むファイル www.conf を作成することです。このようにすると、www.conf は何も行わなくなります。また、新しいバージョンの php-legacy-fpm のインストール中に上書きされることもありません。代わりに、ファイル www.conf.pacnew が作成されます。これを www.conf.package と比較して、nextcloud.conf で再現する必要がある重要な変更がプールファイルにないかどうかを確認できます。この手順の最後に、www.conf.pacnew の名前を www.conf.package に変更することを忘れないでください。

Systemd サービス

FPM は systemd サービスとして実行されます。Nextcloud を実行できるようにするには、サービス構成を変更する必要があります。これは、ドロップインファイルを使用して実現するのが最適です。

/etc/systemd/system/php-fpm-legacy.service.d/override.conf

[Service]
ExecStart=
ExecStart=/usr/bin/php-fpm-legacy --nodaemonize --fpm-config /etc/php-legacy/php-fpm.conf --php-ini /etc/php-legacy/php-fpm.ini
ReadWritePaths=/var/lib/nextcloud
ReadWritePaths=/etc/webapps/nextcloud/config

ExecStart 行を、前のセクションで説明した php-fpm.ini を使用する起動コマンドに置き換えます。
ディレクトリ /var/lib/nextcloud および /etc/webapps/nextcloud/config (および以下のすべて) が書き込み可能になります。元のサービス定義の ProtectSystem=full により、/usr、/boot、および /etc が読み取り専用でマウントされます。FPM プロセスの場合。

php-fpm-legacy サービスを有効化および起動することを忘れないでください。

/etc を整理整頓する

Nextcloud パッケージは、uWSGI 設定ファイル /etc/uwsgi/nextcloud.ini を無条件に作成します。もちろん、uWSGI の代わりに FPM を実行する場合には役に立ちません (そして、何の害もありません) それでも削除したい場合は、次の行を /etc/pacman.conf に追加してください。

/etc/pacman.conf

# uWSGI configuration that comes with Nextcloud is not needed
NoExtract = etc/uwsgi/nextcloud.ini

Web サーバー

選択できる Web サーバーは豊富にあります。最終的にどのオプションを選択する場合でも、Nextcloud アプリケーションは独自のシステムユーザー nextcloud で実行する必要があることに留意する必要があります。したがって、リクエストを上記のアプリケーションサーバーのいずれかに転送する必要があります。

nginx

nginx の構成は、この記事の範囲をはるかに超えています。詳細については、関連する article を参照してください。詳細な構成については、Nextcloud のドキュメントも参照してください。ほとんどの場合、これを適切な名前のファイル (ここでは例として cloud.mysite.com.conf) を /etc/nginx/sites-available の下にコピーする必要があります。対応するシンボリックリンクを /etc/nginx/sites-enabled に作成します。

上にリンクされている Nextcloud ドキュメントのサンプル nginx 構成を使用する場合は、ルートディレクトリを次のように変更する必要があります。

cloud.mysite.com.conf

  root /usr/share/webapps/nextcloud;

ブロック upstream php-handler { ... } を使用する必要はありません。PHP URI を含むリクエストのアプリケーションサーバーへの転送を処理する location ブロックに fastcgi_pass unix:/run/php-fpm-legacy/nextcloud.sock; を指定するだけです。FPM の代わりに uWSGI を使用する場合は、この location ブロックを次のように置き換えます。

cloud.mysite.com.conf

location ~ \.php(?:$|/) {
    include uwsgi_params;
    uwsgi_modifier1 14;
    # Avoid duplicate headers confusing OC checks
    uwsgi_hide_header X-Frame-Options;
    uwsgi_hide_header X-XSS-Protection;
    uwsgi_hide_header X-Content-Type-Options;
    uwsgi_hide_header X-Robots-Tag;
    uwsgi_hide_header X-Download-Options;
    uwsgi_hide_header X-Permitted-Cross-Domain-Policies;
    uwsgi_pass unix:/run/uwsgi/nextcloud.sock;
}

適応する必要がある可能性のあるもの (すべてではありません):

サーバー名 (server_name 句2倍)、つまり Nextcloud インストールが到達可能な URL のサーバー部分です。
SSL/TLS に使用する証明書とキーの名前。
アクセスログをどこに書き込むか。
Certbot (または他の ACME クライアント) がドメイン検証チャレンジを置く場所。ここでは、try_files の代わりに alias を使用する方が適切でしょう。
Nextcloud のインストール先へのパス。(URL のサーバー名&ポートセクションの右側の部分)
使用しているアプリケーションサーバー (uWSGI または FPM)、つまり PHP コードをトリガーする必要があるリクエストを nginx がどこにどのように渡すか。(上記参照)
OCSP_stapling を設定します。

nginx は FastCGI と uwsgi の両方のプロトコルをネイティブにサポートしているため、追加のモジュールをインストールする必要はありません。

Apache HTTP server

Apache HTTP Server に関する記事には役立つ情報がたくさんあります。Nextcloud のドキュメントにはサンプル設定が含まれており、/usr/share/doc/nextcloud/apache.example.conf にもあります。どちらも暗黙的に mod_php に依存していますが、これはもう使用できません。 mod_proxy_fcgi または mod_proxy_uwsgi を適用する必要があります。

Apache と FPM を統合する方法に関する情報は、この Wiki にあります。uWSGI のドキュメントには、uWSGI および mod_proxy_uwsgi を使用して Apache と PHP を統合する方法に関する情報が記載されています。Apache パッケージには mod_proxy_fcgi と mod_proxy_uwsgi の両方のモジュールが付属していることに注意してください。必要に応じてロードする必要があります。

Nextcloud を実行するには、次の Apache モジュールが必要です。

/etc/httpd/conf/httpd.conf

# these are already loaded in a standard Apache installation
LoadModule headers_module modules/mod_headers.so
LoadModule env_module modules/mod_env.so
LoadModule dir_module modules/mod_dir.so
LoadModule mime_module modules/mod_mime.so
LoadModule setenvif_module modules/mod_setenvif.so

# these need to be uncommented explicitely
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule ssl_module modules/mod_ssl.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
LoadModule proxy_module modules/mod_proxy.so

# either this one in case you use FPM
LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so
# or this one in case you opt for uWSGI
LoadModule proxy_uwsgi_module modules/mod_proxy_uwsgi.so

また、TLS 設定パラメータを取り込むには、次のディレクティブのコメントを解除します。

/etc/httpd/conf/httpd.conf

Include conf/extra/httpd-ssl.conf

TLS 設定を最適化する方法の詳細については、Mozilla の SSL configurator を参照してください。

Nextcloud インストールへのアクセス方法に応じて、次の 2 つのサンプル設定ファイルを参照してください。

Nextcloud のインストールが専用ホスト名でアクセスされる場合 (例:https://cloud.mysite.com/)、/etc/httpd/conf/extra/httpd-vhosts.conf にこれを記述してください。

Nextcloud が Web サイトのサブフォルダ (例:https://www.mysite.com/nextcloud/) にインストールされている場合は、/etc/httpd/conf/httpd.conf にこれを記述してください。

もちろん、これらのサンプル設定ファイルを実際の設定に適合させる必要があります。uWSGI を使用する場合は、SetHandler ディレクティブを SetHandler "proxy:unix:/run/uwsgi/nextcloud.sock|uwsgi://nextcloud/" に置き換えます。

Nextcloud パッケージには、多くの書き換えやヘッダー処理がすでに行われている .htaccess が付属しています。occ maintenance:update:htaccess を実行して、このファイルを調整します。これには、/etc/webapps/nextcloud/config/config.php のパラメータ htaccess.RewriteBase が重要です。

バックグラウンドジョブ

Nextcloud では、特定のタスクをスケジュールに従って実行する必要があります。詳細については、Nextcloud のドキュメントを参照してください。これらのバックグラウンドジョブを設定する最も簡単な (そして最も信頼性の高い) 方法は、nextcloud によってすでにインストールされている systemd サービスとタイマーユニットを使用することです。ジョブが正しい PHP ini ファイル (グローバルの php.ini ではなく) を使用するように、サービスユニットを微調整する必要があります。ドロップインファイルを作成し、以下を追加します。

/etc/systemd/system/nextcloud-cron.service.d/override.conf

[Service]
ExecStart=
ExecStart=/usr/bin/php-legacy -c /etc/webapps/nextcloud/php.ini -f /usr/share/webapps/nextcloud/cron.php

その後 nextcloud-cron.timer を有効化して起動 (サービスではありません)

警告: nextcloud-systemd-timers^AUR をインストールして使用しないでください。時代遅れで、メンテナンスされていません。4 つのスケジュールされたジョブをインストールします。

1. nextcloud-preview-pre-generate は occreview:pre-generate を実行します。このコマンドは、nextcloud-app-previewgenerator^AUR がインストールされている場合にのみ存在します。

2. nextcloud-preview-generate-all は occreview:generate-all を実行します。このコマンドも、nextcloud-app-previewgenerator^AUR がインストールされている場合にのみ存在します。さらに、これははスケジュールに基づいて実行されることを意図したものではありません

3. nextcloud-files-scan-all は occ files:scan --all を実行します。これは標準のバックグラウンドジョブですでにカバーされています。テーブル oc_jobs を見て、class = 'OCA\Files\BackgroundJob\ScanFiles' のエントリを見つけてください。

4. nextcloud-app-update-all は occ app:update --all を実行します。Nextcloud アプリの自動更新は、完全に危険ではないにしても、少なくとも疑わしいです。アプリの新しいバージョンは、過去にもすでに問題を引き起こしています。バックアップを行い運用環境でのアプリの更新は監視する必要があります。

In-memory キャッシュ

Nextcloud のドキュメントでは、パフォーマンスを大幅に向上させるために、ある種のメモリ内オブジェクトキャッシュを適用することを推奨しています。

ノート: プッシュ通知 (サーバーによる通知によってクライアントのポーリングを置き換え、同期遅延を大幅に短縮する Nextcloud サービス) は Redis に依存していることに注意してください。

同期

デスクトップ

公式クライアントは、nextcloud-client パッケージでインストールできます。代替バージョンは AUR: nextcloud-client-git^AUR で入手できます。Nextcloud での owncloud-client の使用はサポートされていないことに注意してください。

デスクトップクライアントは基本的に、デスクトップコンピューターの 1 つ以上のディレクトリを Nextcloud のファイルサービス内の対応するフォルダーと同期します。デスクトップのファイルマネージャー (KDE Plasma の Dolphin、Gnome の Nautilus) とうまく統合され、同期と共有ステータスを表すオーバーレイが表示されます。各ファイルのコンテキストメニューには、このファイルの共有とパブリックまたは内部共有リンクの取得を管理するための追加エントリ Nextcloud が表示されます。Nextcloud のドキュメントには、デスクトップクライアントのみに関する volume があります。

統合が説明どおりに機能しない場合は、パッケージ nextcloud-client (pacman -Qi nextcloud-client) のオプションの依存関係を調べてください。たとえば、Nautilus (Gnome) には python-nautilus が必要です。pacman -S --asdeps を使用して依存パッケージとしてインストールします。

Thunderbird

バージョン 91 以降 Thunderbird は、自動検出を使用しても CalDAV と CardDAV を完全にサポートしています (つまり、カレンダーやアドレス帳にアクセスするために長い URL を指定する必要はありません) Nextcloud のドキュメントは、この点に関して最新ではありません。

カレンダー

Mozilla Thunderbird の Lightning カレンダーを使って Nextcloud のカレンダーにアクセスするには以下の URL を使います:

https://ADDRESS/remote.php/caldav/calendars/USERNAME/CALENDARNAME

Kontact や Evolution など CalDAV に対応するプログラムを使って Nextcloud のカレンダーにアクセスするには、以下の URL を使います:

https://ADDRESS/remote.php/caldav

詳しくは公式ドキュメントを見てください。

連絡先

Thunderbird と連絡先を同期するには、SOGo フロントエンドと Lightning エクステンションをインストールして公式ドキュメントの手順に従う必要があります。

davfs2 でファイルをマウントする

ownCloud を永続的にマウントしたい場合、まず davfs2 をインストールしてください (Davfs2 に説明があります)。

もし ownCloud が https://own.example.com にある場合、WebDAV の URL は https://own.example.com/remote.php/webdav になります (ownCloud 6.0 現在)。

ownCloud をマウントするには、次のコマンドを使います:

# mount -t davfs https://own.example.com/remote.php/webdav /path/to/mount

/etc/fstab にエントリを作成することもできます:

/etc/fstab

https://own.example.com/remote.php/webdav /path/to/mount davfs rw,user,noauto 0 0

ヒント: 自動でマウントしたい場合、Davfs2#接続情報の保存で説明されているようにファイルにユーザー名 (と必要であればパスワード) を保存できます。

ノート: ディレクトリは作成・コピーできるのに、ファイルの作成やコピーができない場合、Davfs2#ファイルの作成やコピーができないを見てください。

GNOME Files (Nautilus) でファイルをマウントする

Nautilus ('+ Other Locations') では WebDAV プロトコルを使ってファイルに直接アクセスできます。Nextcloud のインストール Web GUI で表示されるリンクを使ってください (通常は https://example.org/remote.php/webdav/)。ただしプロトコルの名前は 'https' から 'davs' に置き換えてください。Nautilus は接続時にユーザー名とパスワードを要求します。

Android

Nextcloud の公式アプリは Google Play や F-Droid からダウンロードできます。

連絡先やカレンダーの同期を有効化するには (Android 4 以上):

DAVdroid (Play Store, F-Droid) をダウンロード。
httpd.conf で mod_rewrite.so を有効化。
Account 設定で DAVdroid アカウントを新しく作成して、短いサーバーアドレス (例: https://cloud.example.com、リダイレクトをウェブサーバーで正しく設定していれば /remote.php/{carddav,webdav} の部分は不要です。DAVdroid は自動的に URL を検索します) とログイン名・パスワードを指定する。

iOS

App Store から Nextcloud の公式アプリをダウンロードしてください。

ヒントとテクニック

"occ" コマンドラインツールの使用

サーバー管理に役立つツールは occ です Nextcloud のドキュメントの詳細を参照してください。occ を使用すると、ユーザーの管理やアプリの構成など、多くの一般的なサーバー操作を実行できます。

元の /usr/share/webapps/nextcloud/occ の便利なラッパーは、デフォルトユーザー (nextcloud) として自動的に実行される /usr/bin/occ で提供されます。)、デフォルトの PHP 実行可能ファイルと PHP 設定ファイルを使用します。環境変数 NEXTCLOUD_USER、NEXTCLOUD_PHP、および NEXTCLOUD_PHP_CONFIG を使用して、デフォルト以外のユーザー、PHP 実行可能ファイル、および PHP 設定ファイルを (それぞれ) 指定できます。特に後者 (NEXTCLOUD_PHP_CONFIG を使用) は、セクション設定および Application サーバーで説明されている方法で Nextcloud がセットアップされた場合、つまり、 Nextcloud に固有の PHP 設定。この場合、export NEXTCLOUD_PHP_CONFIG=/etc/webapps/nextcloud/php.ini を .bashrc に追加します。

推奨パッケージ php-legacy の代わりにパッケージ php を使用する場合は、NEXTCLOUD_PHP も設定する必要があります。つまり、export NEXTCLOUD_PHP=/usr/ bin/php

警告: キャッシュに php-apcu を使用する場合は、必ず /etc/webapps/nextcloud/php.ini で apc.enable_cli=1 を設定してください。そうしないと、occ コマンドは、APCu が適切に設定されていないというエラーを表示します。

Pacman フック

nextcloud パッケージには、パッケージの更新後に Nextcloud データベースを自動的にアップグレードする pacman フックが付属しています。/usr/share/doc/nextcloud/nextcloud.hook をご覧ください。

残念ながら、このフックは occ upgrade の実行時にグローバルの php.ini を無条件に使用します。つまり、前述したように環境変数 NEXTCLOUD_PHP_CONFIG の値は考慮されません。上記の "occ" コマンドラインツールの使用で説明しています。

考えられる回避策として、提供されたフックファイルのコピーを適切な場所に作成します。

# mkdir -vp /etc/pacman.d/hooks
# cp -a /usr/share/doc/nextcloud/nextcloud.hook /etc/pacman.d/hooks/10-nextcloud.hook

Exec で始まる行を次のように変更します。

/etc/pacman.d/hooks/10-nextcloud.hook

Exec = /usr/bin/runuser -u nextcloud -- /usr/bin/php-legacy --php-ini /etc/webapps/nextcloud/php.ini /usr/share/webapps/nextcloud/occ upgrade

Nextcloud をサブディレクトリで実行する

Web サーバーセクションの手順により、Nextcloud インストールが専用サーバー名 (例: cloud.mysite.com) 経由でアクセスできるセットアップが行われます。Nextcloud をサブディレクトリに置きたい場合。例: www.mysite.com/nextcloud の場合:

nginx については、これを明示的に説明している Nextcloud のドキュメントのセクションを参照してくださいウェブルートトピック

apache の場合は、インクルードされた /etc/httpd/conf/extra/nextcloud.conf を編集して、<VirtualHost *:80> ... </VirtualHost> の部分をコメントアウトします。

ノート: サービス検出用に .well-known URL を構成することを忘れないでください。詳細については、Nextcloud のドキュメントのサービス検出を参照してください。

Docker

Docker の ownCloud あるいは Nextcloud リポジトリを見てください。

Office 統合

現在、Office 統合には 3 つの異なるソリューションがあります。

3 つの共通点は、専用サーバーが必要であり、特定のリクエストをオフィスサービスに転送するように Web サーバーを適合させる必要があるという点です。Nextcloud との実際の統合は、上記の製品のいずれかに固有の Nextcloud アプリを使用して実現されます。

3 つの製品はすべてビジネス向けであることに注意してください。つまり、オフィスサービスの料金を支払う必要があります。Collabora のみが開発者プラン (CODE) を無料で提供しています。 ONLYOFFICE は、ホームサーバープランを手頃な価格で提供しています。

インストール、セットアップ手順、Nextcloud との統合については、以下を参照してください。

アプリの推奨を無効にする

デフォルトでは、Nextcloud は新しいクライアントにアプリを推奨するため、大量の通知が発生する可能性があります。これを無効にするには、occ app:disable Recommendation を使用してレコメンデーションアプリを無効にします。

calcardbackup を使用してカレンダーとアドレス帳をバックアップする

calcardbackup^AUR パッケージをインストールして構成すると、カレンダーやアドレス帳のデータベースを定期的にバックアップできます。/etc/calcardbackup/calcardbackup.conf を好みに合わせて編集し、calcardbackup.timer を起動して有効化します。

トラブルシューティング

ログを読む

デフォルトでは、Web アプリケーションのログは /var/log/nextcloud/nextcloud.log で利用できます。エントリ (行) は JSON 形式であり、非常に長くなる場合があります。jq を使用すると、可読性が大幅に向上します。

# jq . </var/log/nextcloud/nextcloud.log | less

ImageMagick によるバージョン警告

/var/log/nextcloud/nextcloud.log に次のような警告が大量に表示される場合があります。

Version warning: Imagick was compiled against ImageMagick version 1808 but version 1809 is loaded. Imagick will run but may behave surprisingly at Unknown#0

FS#69636 によると、これは誤報であり、無視して構いません。これらの警告を無くすには、ログ内の重要なメッセージをより目立つように、次の行を追加します。

imagick.skip_version_check = 1

/etc/php-legacy/php-fpm.ini と /etc/webapps/nextcloud/php.ini にあります。あるいは、/etc/php-legacy/conf.d/imagick.ini でこの行のコメントを解除することもできます。

アップグレード v25 → v26

バージョン 25 のインストールをバージョン 26 にアップグレードするには、次の手順が必要です。

拡張機能 sysvsem を有効にする

バージョン 26 には、追加の PHP 拡張機能 sysvsem が 1 つ必要です。この拡張機能は次の 2 つの場所で有効にする必要があります。

/etc/webapps/nextcloud/php.ini occ コマンドとバックグラウンドジョブによって使用されます。
使用するアプリケーションサーバーに応じて、
- /etc/uwsgi/nextcloud.ini (uWSGI の場合) または
- FPM の場合は /etc/php-legacy/php-fpm.d/nextcloud.conf

他の拡張機能が有効になっている既存のセクションを探して、sysvsem に対応する行を追加するだけです。

/proc/cpuinfo を open_basedir に追加

セットアップで PHP パラメータ open_basedir も定義している場合 (推奨)、このディレクトリのリストに /proc/cpuinfo を追加する必要があります。この行を見つけます

/etc/webapps/nextcloud/php.ini occ コマンドとバックグラウンドジョブによって使用されます。
使用するアプリケーションサーバーに応じて、
- /etc/uwsgi/nextcloud.ini (uWSGI の場合) または
- /etc/php-legacy/php-fpm.d/nextcloud.conf (FPM の場合)

そして、行の最後に :/proc/cpuinfo を追加します。(コロンに注意してください。)

HTTP 応答ヘッダー X-Robots-Tag を適応させる

これは、Apache の httpd (例:nginx) を使用しないインストールにのみ適用されます。

v25 インストールから継承された Web サーバー設定を使用すると、Nextcloud は HTTP 応答ヘッダー X-Robots-Tag が適切に設定されていないというメッセージを表示するようになります。これを "none" から "noindex, nofollow" に変更する必要があります。Web サーバーの設定内で関連する行を見つけて、それに応じて調整します。nginx の場合、この行は次のようになります。

cloud.mysite.com.conf

    add_header X-Robots-Tag "noindex, nofollow" always;

php から php-legacy への移行

これはオプションであり、(パッケージ php-legacy ではなく) パッケージ php にまだ依存している Nextcloud のインストールにのみ適用されます。詳細と移行が推奨される理由については、php-legacy への移行を参照してください。

php-legacy への移行

過去に、php パッケージが (Arch Linux のローリングリリースの理念に沿って) タイムリーに最新の PHP バージョンに更新されることが何度かありましたが、Nextcloud はこの新しいバージョンと互換性がありませんでした。既存のインストールが破壊され、パッケージ nextcloud のメンテナとユーザーに多大な労力がかかります。パッケージ php がバージョン 8.1 からバージョン 8.2 に切り替わったとき、この問題が再び発生しようとしていました。

この頻繁なトラブルを回避するために、新しい php-legacy パッケージのセットが導入されました [7] その時までに。これらは、最も古いもののまだがアクティブにサポートされている PHP ブランチに続きます。パッケージ nextcloud は、php および php-legacy によって提供されるメタパッケージ php-interpreter に依存するように変更されました。このようにして、パッケージ nextcloud のユーザーは、Nextcloud インストールを php の上に構築するか、php-legacy の上に構築するかを選択できます。

php-legacy を使用することを強くお勧めします。このわずかに古いバージョンの PHP では、システムのアップグレードによって既存の Nextcloud インストールが使用できなくなる可能性はほとんどありません。

警告: PHP の最新かつ最高のバージョン (つまり、php) を選択するユーザーは、パッケージ php がメジャーバージョンまたはマイナーバージョンに切り替わるときの問題に備える必要があります。これらの問題は主に、パッケージ nextcloud が突然 php を依存関係として提供しなくなることで発生します (その時点でそのバージョンが Nextcloud でサポートされていないため) これにより、実質的に php を使用するユーザーは一時的に php-legacy に移行することになります。つまり、しばらくしてから php に戻す必要があります。

php-legacy への移行には、いくつかの手動操作が必要です。実際の設定に応じて、次のタスクのサブセットを適用する必要があります。

ノート: 次のアクションのリストは、Nextcloud インストールがこの Wiki 記事に従って設定されていることを前提としています。セットアップがこのアプローチから逸脱する場合は、特に注意して手順を適切に調整してください。

PHP 拡張機能

php 拡張機能を対応する php-legacy 拡張機能に置き換えます。例えば

$ pacman -R php-apcu php-fpm php-gd php-imagick php-pgsql
$ pacman -S --asdeps php-legacy-apcu php-legacy-gd php-legacy-fpm php-legacy-imagick php-legacy-pgsql

以前の拡張 php-intl は、php および php-legacy の不可欠な部分となっているため、例外です。したがって、ここでこのパッケージを明示的に処理する必要はありません。

実際の PHP 拡張機能のセットは、データベース、メモリ内のオブジェクトキャッシュ、アプリケーションサーバー、およびその他の要因によって異なります。もちろん、別のアプリケーションが最新の PHP バージョンに依存している場合には、非レガシーモジュールが引き続き必要になる可能性があります。同じことが php 自体にも当てはまります。

`php.ini` の Nextcloud 固有のコピー

/etc/webapps/nextcloud/php.ini

open_basedir=...:/usr/lib/php-legacy/modules:...
extension_dir = "/usr/lib/php-legacy/modules/"
;extension=imap                                            <= 削除

FPM 設定

(これは、アプリケーションサーバー FPM が使用されている場合にのみ適用されます。)

$ mv /etc/php/php-fpm.ini /etc/php-legacy/php-fpm.ini
$ mv /etc/php/php-fpm.d/nextcloud.conf /etc/php-legacy/php-fpm.d/nextcloud.conf

/etc/php-legacy/php-fpm.ini を変更します

/etc/php-legacy/php-fpm.ini

extension_dir = "/usr/lib/php-legacy/modules/"
;extension=imap                                            <= 削除

/etc/php-legacy/php-fpm.d/nextcloud.conf を変更します

/etc/php-legacy/php-fpm.d/nextcloud.conf

listen = /run/php-fpm-legacy/nextcloud.sock
;       It's available in: /usr/share/php-legacy/fpm/status.html
access.log = /var/log/php-fpm-legacy/access/$pool.log
; uncomment if php-imap is installed and used              <= 削除
; php_value[extension] = imap                              <= 削除

オプションですが推奨: www.conf を no-op にしますが、php-legacy-fpm の将来の更新で行われる可能性のあるこのファイルの変更を追跡できるようにします。

$ mv /etc/php-legacy/php-fpm.d/www.conf /etc/php-legacy/php-fpm.d/www.conf.package
$ echo "; just a no-op" > /etc/php-legacy/php-fpm.d/www.conf

systemd サービス php-fpm.service を停止および無効化します。php-fpm-legacy.service のドロップインファイルを作成します。

/etc/systemd/system/php-fpm-legacy.service.d/override.conf

[Service]
ExecStart=
ExecStart=/usr/bin/php-fpm-legacy --nodaemonize --fpm-config /etc/php-legacy/php-fpm.conf --php-ini /etc/php-legacy/php-fpm.ini
ReadWritePaths=/var/lib/nextcloud
ReadWritePaths=/etc/webapps/nextcloud/config

systemd サービス php-fpm-legacy.service を有効化および起動します。

uWSGI 設定

(これは、アプリケーションサーバー uWSGI が使用されている場合にのみ適用されます。)

/etc/uwsgi/nextcloud.ini

php-set = open_basedir=...:/usr/lib/php-legacy/modules...
# uncomment if php-imap is installed and used               <= 削除
# php-set = extension=imap                                  <= 削除

Nginx 設定

アプリケーションサーバーへの特定のリクエストの転送が設定されているファイルを変更します。FPM の場合、例:

cloud.mysite.com.conf

fastcgi_pass unix:/run/php-fpm-legacy/nextcloud.sock;

uWSGI の場合、適応する必要はありません。

Apache HTTP server 設定

Apache の HTTP サーバーとアプリケーションサーバーとして FPM を使用する場合は、構成内でこの行を調整してください。

SetHandler "proxy:unix:/run/php-fpm-legacy/nextcloud.sock|fcgi://nextcloud/"

uWSGI の場合、適応する必要はありません。

バックグラウンドジョブ

Nextcloud のスケジュールされたバックグラウンドジョブのドロップインファイルを更新します。

/etc/systemd/system/nextcloud-cron.service.d/override.conf

[Service]
ExecStart=
ExecStart=/usr/bin/php-legacy -c /etc/webapps/nextcloud/php.ini -f /usr/share/webapps/nextcloud/cron.php

Pacman フック

pacman フック /etc/pacman.d/hooks/10-nextcloud.hook も調整する必要があります。Exec で始まる行を次のように変更します。

/etc/pacman.d/hooks/10-nextcloud.hook

Exec = /usr/bin/runuser -u nextcloud -- /usr/bin/php-legacy --php-ini /etc/webapps/nextcloud/php.ini /usr/share/webapps/nextcloud/occ upgrade

そうしないと、Nextcloud の次回のアップグレード中に pacman が /usr/bin/php が見つからないというエラーを表示します。

クリーンアップ

古くなった可能性のあるファイルとディレクトリをクリーンアップすることを忘れないでください。潜在的な候補者は次のとおりです。

/usr/lib/php
/etc/php

1 つ以上のアプリの奇妙な動作

Nextcloud アプリのファイルが含まれるフォルダーは 2 つの場所にあります。

/usr/share/webapps/nextcloud/apps (別名読み取り専用アプリディレクトリ) これは、nextcloud パッケージとアプリパッケージ (例: nextcloud-app-contacts) が Nextcloud アプリを構成するファイルを含むフォルダーを配置する場所です。

/var/lib/nextcloud/apps (別名書き込み可能なアプリディレクトリ) ここには、GUI または occ app:install コマンドを介してインストールされたアプリのファイルが含まれるフォルダーがあります。

アプリのファイルが両方のディレクトリ (特に異なるバージョン) で見つかると、あらゆる種類の奇妙なことが発生する可能性があります。具体的なケースでは、連絡先 アプリが読み取り専用アプリディレクトリと書き込み可能なアプリディレクトリの両方に存在する可能性があります。その結果、GUI に連絡先を含むページは表示されませんでした。ブラウザの Javascript コンソールに次のエラーメッセージが表示されました。

Uncaught Error: Could not find initial state contactsinteraction of contacts

両方の場所にアプリが存在するかどうかを確認します。アプリフォルダーを読み取り専用ディレクトリまたは書き込み可能なディレクトリのどちらで削除するかを確認するには、アプリがパッケージの一部であるかどうかを確認します。

# cd /usr/share/webapps/nextcloud/apps
# pacman -Qo * >/dev/null

報告されたすべてのフォルダー

error: No package owns ....

(書き込み可能なアプリディレクトリにもあります) は、/usr/share/webapps/nextcloud/apps から安全に削除できます。他の二重インストールされたアプリ (つまり、パッケージに属するアプリ) は、/var/lib/nextcloud/apps から削除する必要があります。

コード整合性チェックの失敗に関する警告 (v23)

バージョン 23 では、PHP 8.1 との互換性を実現するために、Nextcloud の PHP コードに Arch Linux パッケージ用のパッチを広範囲に適用する必要がありました。この欠点は、Nextcloud の組み込みコード整合性チェックがすべてのパッチ適用ファイルで失敗することでした。管理者のビューに表示される対応する警告は無視できます。バージョン 24 は PHP 8.1 とネイティブ互換性があります。したがって、パッチは必要ないため、整合性に関する警告も表示されなくなります。

InnoDB は ROW_FORMAT=COMPRESSED を指定したテーブルの書き込みを拒否します

MariaDB バージョン >= 10.6 および < 10.6.6 は、データベースが圧縮された InnoDB に対して read-only を強制されているため、Nextcloud と互換性がありませんでした。] Nextcloud は、次の種類のテーブルを使用してきました (そして現在も使用しています)

MariaDB 10.6.0 から MariaDB 10.6.5 まで、COMPRESSED 行形式のテーブルはデフォルトで読み取り専用です。これは、書き込みサポートの削除と機能の廃止に向けた最初のステップとなることを目的としていました。

この計画は廃止され、MariaDB 10.6.6 以降、COMPRESSED テーブルはデフォルトで読み取り専用ではなくなりました。

さらに、この問題は Nextcloud によってすでにで対処されています。Nextcloud v24 以降、Nextcloud の新規インストールでは行形式 COMPRESSED が使用されなくなりました。既存の (v24 より前の) インストールは行形式 COMPRESSED から自動的に移行されないことに注意してください。

結論: Arch Linux は 2022 年 2 月 10 日以降 MariaDB v10.6.6 以降を出荷しているため、おそらく影響を受けません。

この問題の影響を受ける可能性は低いですが、考えられる解決策がいくつかあります。

MariaDB 設定を調整します。

/etc/my.cnf.d/server.cnf

[mariadb-10.6]
  innodb_read_only_compressed=OFF

対応する Nextcloud issue のいくつかのコメントで提案されているように、MariaDB テーブルを行フォーマット COMPRESSED から DYNAMIC に移行してください。Nextcloud < v24 を使用している限り、新しいテーブルは再び行フォーマット COMPRESSED を使用しますので、同じ方法で移行する必要があります。

MariaDB を PostgreSQL に置き換え、Nextcloud インスタンスのデータを occ db:convert-type で移行します。詳細については、Nextcloud のドキュメントを参照してください。

21.0.0 以上にアップグレードした後の権限とセットアップの問題

ノート: nextcloud 21.0.0 より前では、Web アプリケーションは http ユーザーを使用して実行されていました。これは、このユーザーのアプリケーション間アクセス (すべての Web アプリケーションのすべてのデータにアクセスできる) に関するセキュリティ上の問題です。

バージョン 21.0.0 以降、nextcloud はウェブアプリケーションパッケージガイドラインにさらに厳密に従います。これにより、Web アプリケーションが実行される別のユーザー nextcloud が導入されます。

nextcloud < 21.0.0 からアップグレードした後、次のことを確認してください。

データディレクトリは /var/lib/nextcloud/data にあります。
書き込み可能な apps ディレクトリは /var/lib/nextcloud/apps にあります。
data ディレクトリと書き込み可能な apps ディレクトリの両方と、その下にあるすべてのファイルは書き込み可能で、nextcloud ユーザーが所有します。
Web アプリケーション設定ファイルが /etc/webapps/nextcloud/config/ に存在し、そのディレクトリとコンテンツが nextcloud ユーザによって書き込み可能かつ所有されていること。
アプリケーションサーバ (FPM や uWSGI など) が、http ユーザではなく nextcloud ユーザとして Web アプリケーションを実行するように設定されている。
新しいユーザーで実行するように cron ジョブ/systemd タイマーを更新する。
最後に、nextcloud インストール /usr/share/webapps/nextcloud への読み取りアクセスを、ウェブサーバーのユーザ http に許可します:

 # chown -R nextcloud:http /usr/share/webapps/nextcloud

access.log、error.log、nextcloud.log に手がかりがないログインループ

フォーラムの投稿で述べられているように、この問題は、sessions ディレクトリに正しいアクセス許可を設定することで修正できます。 (詳細については、Nextcloud のドキュメントを参照してください) sessions ディレクトリが完全に欠落している可能性もあります。このディレクトリの作成については、システムと環境に記載されています。

/var/lib/nextcloud は次のようになります。

drwxr-xr-x  6 nextcloud nextcloud 4096 17. Apr 00:56 ./
drwxr-xr-x 21 root      root      4096 17. Apr 00:53 ../
drwxr-xr-x  2 nextcloud nextcloud 4096 16. Feb 00:21 apps/
drwxrwx--- 10 nextcloud nextcloud 4096 16. Apr 13:46 data/
drwx------  2 nextcloud nextcloud 4096 17. Apr 01:04 sessions/

環境変数は使用できません

使用するアプリケーションサーバーに応じて、カスタム環境変数を Nextcloud の PHP コードに提供できます。

FPM

[8] に従って、/etc/php-legacy/php-fpm.d/nextcloud.conf に 1 行以上の行を追加します。 .html#php-fpm-tips-label Nextcloud のドキュメント]、例:

/etc/php-legacy/php-fpm.d/nextcloud.conf

env[PATH] = /usr/local/bin:/usr/bin:/bin

uWSGI

/etc/uwsgi/nextcloud.ini に 1 つ以上の行を追加します。例:

/etc/uwsgi/nextcloud.ini

env = PATH=/usr/local/bin:/usr/bin:/bin

2 番目の = の周囲に空白を入れてはいけないことに注意してください。

安全な接続を介してインスタンスにアクセスしていますが、インスタンスは安全でない URL を生成しています

管理設定で次のメッセージが表示された場合:

You are accessing your instance over a secure connection, however your instance is generating insecure URLs. This most likely means that you are behind a reverse proxy and the overwrite config variables are not set correctly. Please read the documentation page about this.

設定ファイルに以下を追加します: [9]

/etc/webapps/nextcloud/config/config.php

'trusted_proxies' => ['192.168.1.0'],
'overwriteprotocol' => 'https',

192.168.1.0 をパブリック IP に置き換えます。

Nextcloud が破損したインデックスを報告する (MariaDB)

たとえば、occ db: コマンド中または [管理] -> [ログ] で Nextcloud がインデックスの破損を報告した場合は、次のコマンドを実行してデータベースを修復できます。

$ mysqlcheck --check --auto-repair nextcloud -u nextcloud -p

コマンドが失敗した場合でも、破損したインデックスを含むテーブル TABLE が指摘されます。mariadb にログインして修復します。

$ mysql -u nextcloud -p
$ use nextcloud;
$ check table TABLE;
$ optimize table TABLE;
$ exit;

結果と一致するように TABLE を置き換えてください。

参照

Nextcloud

目次

セットアップの概要

インストール

設定

PHP

Nextcloud

システムと環境

データベース

MariaDB / MySQL

PostgreSQL

アプリケーションサーバー

uWSGI

nextcloud.ini

uWSGI サービス

FPM

php-fpm.ini

nextcloud.conf

Systemd サービス

/etc を整理整頓する

Web サーバー

nginx

Apache HTTP server

バックグラウンドジョブ

In-memory キャッシュ

同期

デスクトップ

Thunderbird

カレンダー

連絡先

davfs2 でファイルをマウントする

GNOME Files (Nautilus) でファイルをマウントする

Android

iOS

ヒントとテクニック

"occ" コマンドラインツールの使用

Pacman フック

Nextcloud をサブディレクトリで実行する

Docker

Office 統合

アプリの推奨を無効にする

calcardbackup を使用してカレンダーとアドレス帳をバックアップする

トラブルシューティング

ログを読む

ImageMagick によるバージョン警告

アップグレード v25 → v26

拡張機能 sysvsem を有効にする

/proc/cpuinfo を open_basedir に追加

HTTP 応答ヘッダー X-Robots-Tag を適応させる

php から php-legacy への移行

php-legacy への移行

PHP 拡張機能

php.ini の Nextcloud 固有のコピー

FPM 設定

uWSGI 設定

Nginx 設定

Apache HTTP server 設定

バックグラウンドジョブ

Pacman フック

クリーンアップ

1 つ以上のアプリの奇妙な動作

コード整合性チェックの失敗に関する警告 (v23)

InnoDB は ROW_FORMAT=COMPRESSED を指定したテーブルの書き込みを拒否します

21.0.0 以上にアップグレードした後の権限とセットアップの問題

access.log、error.log、nextcloud.log に手がかりがないログインループ

環境変数は使用できません

FPM

uWSGI

安全な接続を介してインスタンスにアクセスしていますが、インスタンスは安全でない URL を生成しています

Nextcloud が破損したインデックスを報告する (MariaDB)

参照

案内メニュー

検索

`php.ini` の Nextcloud 固有のコピー