Nextcloud: Difference between revisions

From ArchWiki
VisualWikitext
(add note about optional dependency needed for GNOME to display the status tray icon for nextcloud-client)
 
(336 intermediate revisions by 54 users not shown)
Line 1: Line 1:
[[Category:File sharing]]
[[Category:File sharing]]
[[Category:Web applications]]
[[Category:Web applications]]
[[fr:Owncloud]]
[[ja:Nextcloud]]
[[ja:Nextcloud]]
[[zh-hans:Nextcloud]]
{{Related articles start}}
{{Related articles start}}
{{Related|Apache HTTP Server}}
{{Related|Apache HTTP Server}}
{{Related|Nginx}}
{{Related|Nginx}}
{{Related|UWSGI}}
{{Related|OpenSSL}}
{{Related|OpenSSL}}
{{Related|WebDAV}}
{{Related|WebDAV}}
{{Related articles end}}
{{Related articles end}}


From [[Wikipedia:Nextcloud]]:
[https://nextcloud.com/ Nextcloud] is a suite of client-server-software that (by means of so-called [https://apps.nextcloud.com/ apps]) allows all kinds of sharing, collaboration and communication, e.g.:


:Nextcloud is a suite of client-server software for creating and using file hosting services. It is functionally similar to Dropbox, although Nextcloud is free and open-source, allowing anyone to install and operate it on a private server. In contrast to proprietary services like Dropbox, the open architecture allows adding additional functionality to the server in form of applications.
* file sharing
* personal information manager ([https://apps.nextcloud.com/apps/contacts contacts], [https://apps.nextcloud.com/apps/calendar calendar], [https://apps.nextcloud.com/apps/tasks tasks])
* messaging ([https://apps.nextcloud.com/apps/mail mail], [https://apps.nextcloud.com/apps/spreed chat, video conferencing])
* collaborative editing of documents ([https://github.com/nextcloud/text text], [[#Office integration|Office integration]])


Nextcloud is a fork of ownCloud. For differences between the two, see [[wikipedia:Nextcloud#Differences from ownCloud]].
Nextcloud is open source and based on open standards. Data sovereignty is a big plus, i.e. with your own instance of Nextcloud, you break free from proprietary (and potentially untrustworthy) services like Dropbox, Office 365, or Google Drive.


== Prerequisites ==
Depending on your needs Nextcloud can be deployed from single-board computers (like e.g. a Raspberry Pi) all the way up to full scale data centers serving millions of users. With an elaborated authorization scheme and the option for federation (connecting discrete instances) Nextcloud is well suited for use in enterprise environments.


Nextcloud requires several components:[https://docs.nextcloud.com/server/latest/admin_manual/installation/system_requirements.html#server]
Nextcloud is a fork of [https://owncloud.com/ ownCloud]. See Wikipedia for the [[Wikipedia:Nextcloud#History|history]].


* A web server: [[Apache HTTP Server]] or [[nginx]]
== Setup overview ==
* A database: [[MariaDB]]/MySQL, [[PostgreSQL]], [[SQLite]] or [[Oracle Database]]
* [[PHP]] with [[#PHP setup|additional modules]]


These will be configured in [[#Setup]].
A complete installation of Nextcloud comprises (at least) the following components:


Make sure the required components are installed before proceeding.
A '''web server''' paired with an '''application server''' on which runs '''Nextcloud''' (i.e. the PHP code) using a '''database'''.
 
This article will cover [[MariaDB]]/MySQL and [[PostgreSQL]] as databases and the following combinations of web server and application server:
 
* nginx → uWSGI (plus uwsgi-plugin-php)
* nginx → FPM,
* Apache HTTP server (using mod_proxy_uwsgi) → uWSGI (plus uwsgi-plugin-php)
* Apache HTTP server (using mod_proxy_fcgi) → FPM
 
The Nextcloud package complies with the [[web application package guidelines]]. Among other things this mandates that the web application be run with a dedicated user - in this case {{ic|nextcloud}}. This is one of the reasons why the application server comes into play here. For the very same reason it is not possible anymore to execute Nextcloud's PHP code directly in the Apache process by means of {{pkg|php-apache}}.


== Installation ==
== Installation ==


[[Install]] the {{Pkg|nextcloud}} package.
{{Note|The package {{Pkg|nextcloud}} (by means of a dependency on meta package ''php-interpreter'') offers the choice to build an installation of Nextcloud on top of either {{Pkg|php}} or on top of package {{Pkg|php-legacy}}. It is highly recommended to choose {{Pkg|php-legacy}} to be on the safe side (and for your peace of mind). See [[#Migrating to php-legacy|Migrating to php-legacy]] for details. For the remainder of this article we assume an installation using {{Pkg|php-legacy}}.}}
 
Install the {{Pkg|nextcloud}} package. When asked choose {{Pkg|php-legacy}} as your PHP version. This will pull in quite a few dependent packages. All [https://docs.nextcloud.com/server/stable/admin_manual/installation/source_installation.html#prerequisites-for-manual-installation required PHP extensions] will be taken care of this way.
 
It is recommended to additionally install the packages {{Pkg|php-legacy-sodium}} for the argon2 hashing algorithm and {{Pkg|php-legacy-imagick}} and {{Pkg|librsvg}} for preview generation (preferrably as dependent package with pacman option {{ic|--asdeps}}). Other optional dependencies will be covered later depending on your concrete setup (e.g. which database you choose).


== Configuration ==
== Configuration ==


The web application is configured in {{ic|/etc/webapps/nextcloud/config/config.php}}.
=== PHP ===


{{Note|Nextcloud should store user data in {{ic|/var/lib/nextcloud/data/}}, as that directory is only accessible by root and the application itself. For the installation of apps using the web application {{ic|/var/lib/nextcloud/apps/}} should be used.}}
This guide does not tamper with PHP's central configuration file {{ic|/etc/php-legacy/php.ini}} but instead puts Nextcloud specific PHP configuration in places where it does not potentially interfere with settings for other PHP based applications. These places are:


=== Data directory ===
* A dedicated copy of {{ic|php.ini}} in {{ic|/etc/webapps/nextcloud}} (for the {{ic|occ}} command line tool and the background job). This is literally a copy of the original {{ic|php.ini}} as provided by the {{Pkg|php-legacy}} package with some Nextcloud specific additions / modifications.


By default nextcloud stores its user data in {{ic|/var/lib/nextcloud/data/}}. This location is configurable:
* Corresponding settings in the configuration of the application server. These will be covered in the section about application servers.


{{hc|/etc/webapps/nextcloud/config/config.php|2=
Make a copy of {{ic|/etc/php-legacy/php.ini}} to {{ic|/etc/webapps/nextcloud}}. Although not strictly necessary, change ownership of the copy:
$CONFIG = [
{{bc|# cp /etc/php-legacy/php.ini /etc/webapps/nextcloud
/* [..] */
# chown nextcloud:nextcloud /etc/webapps/nextcloud/php.ini}}
'datadirectory' => '/var/lib/nextcloud/data',
 
/* [..] */
Most of the prerequisites listed in Nextcloud's [https://docs.nextcloud.com/server/stable/admin_manual/installation/source_installation.html#prerequisites-for-manual-installation installation instructions] are already enabled in the just copied bare PHP installation config file. Additionally enable the following extensions:
]
 
{{hc|/etc/webapps/nextcloud/php.ini|2=
extension=bcmath
extension=bz2
extension=exif
extension=gd
extension=iconv
extension=intl
# sodium for the argon2 hashing algorithm
extension=sodium
extension=sysvsem
; in case you installed php-legacy-imagick (as recommended)
extension=imagick
}}
}}


{{Note| The {{ic|datadirectory}} needs to be writable by the {{ic|nextcloud}} user.}}
Set {{ic|date.timezone}} to your preferred timezone, e.g.:


=== Writable apps directory ===
{{hc|/etc/webapps/nextcloud/php.ini|2=
date.timezone = Europe/Berlin
}}


The default apps location in {{ic|/usr/share/webapps/nextcloud/apps/}} is not writable to the {{ic|nextcloud}} user, as it is part of the package.
Raise PHP's memory limit to at least 512MiB:


To be able to install apps from the app store, it is possible to use a separate, writable apps directory. This defaults to {{ic|/var/lib/nextcloud/apps/}} and is accessible via a symlink ({{ic|/usr/share/webapps/nextcloud/wapps}}) in the web application's root directory.
{{hc|/etc/webapps/nextcloud/php.ini|2=
memory_limit = 512M
}}


The directories are configurable:
Optional: For additional security configure {{ic|open_basedir}}. This limits the locations where Nextcloud's PHP code can read and write files. Proven settings are


{{hc|/etc/webapps/nextcloud/config/config.php|2=
{{hc|/etc/webapps/nextcloud/php.ini|2=
$CONFIG = [
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
/* [..] */
'apps_paths' => [
        [
                'path'=> '/usr/share/webapps/nextcloud/apps',
                'url' => '/apps',
                'writable' => false,
        ],
        [
                'path'=> '/var/lib/nextcloud/apps',
                'url' => '/wapps',
                'writable' => true,
        ],
],
/* [..] */
]
}}
}}


{{Note|
Depending on which additional extensions you configure you may need to extend this list, e.g. {{ic|/run/redis}} in case you opt for [[Redis]].
* The {{ic|apps_paths}} entry declared as {{ic|writable}} needs to be writable by the {{ic|nextcloud}} user. Additionally a symlink to that directory needs to be created in {{ic|/usr/share/webapps/nextcloud/}}.
 
* The above syntax uses php's [https://wiki.php.net/rfc/short_list_syntax short array syntax]. The same could be written in the syntax most guides use:  
It is not necessary to configure opcache here as this {{ic|php.ini}} is only used by the {{ic|occ}} command line tool and the background job, i.e. by short running PHP processes.
 
=== Nextcloud ===
 
Add the following entries to Nextcloud's configuration file:
 
{{hc|/etc/webapps/nextcloud/config/config.php|2=
{{hc|/etc/webapps/nextcloud/config/config.php|2=
$CONFIG = (
'trusted_domains' =>
/* [..] */
  array (
  'apps_paths' => array (
    0 => 'localhost',
        0 => array (
    1 => '''cloud.mysite.com''',
                'path' => '/usr/share/webapps/nextcloud/apps',
  ),  
                'url' => '/apps',
'overwrite.cli.url' => 'https://''cloud.mysite.com''/',
                'writable' => false,
'htaccess.RewriteBase' => '/',
        ),
        1 => array (
                'path' => '/var/lib/nextcloud/apps',
                'url' => '/wapps',
                'writable' => true,
        ),
  ),
/* [..] */
)
}}
}}
Adapt the given example hostname {{ic|''cloud.mysite.com''}}. In case your Nextcloud installation will be reachable via a subfolder (e.g. {{ic|<nowiki>https://www.mysite.com/nextcloud</nowiki>}}) {{ic|overwrite.cli.url}} and {{ic|htaccess.RewriteBase}} have to be modified accordingly.
=== System and environment ===
To make sure the Nextcloud specific {{ic|php.ini}} is used by the {{ic|occ}} tool set the environment variable {{ic|NEXTCLOUD_PHP_CONFIG}}:
{{bc|1=
$ export NEXTCLOUD_PHP_CONFIG=/etc/webapps/nextcloud/php.ini
}}
}}


=== Log directory ===
Also add this line to your {{ic|.bashrc}} (or {{ic|.bash_profile}} ) to make this setting permanent.


By default logs are created in {{ic|/var/log/nextcloud/nextcloud.log}}. This location is configurable:
As a privacy and security precaution create the dedicated directory for session data:


{{hc|/etc/webapps/nextcloud/config/config.php|2=
{{bc|1=
$CONFIG = [
# install --owner=nextcloud --group=nextcloud --mode=700 -d /var/lib/nextcloud/sessions
/* [..] */
'logfile' => '/var/log/nextcloud/nextcloud.log',
]
/* [..] */
}}
}}


=== Database setup ===
== Database ==


An SQL database must be set up and used for your Nextcloud installation. After setting up the database here,
[[MariaDB]]/MySQL is the canonical choice for Nextcloud.
you will be prompted for its information when you first create an administrator account.


==== MariaDB ====
:The MySQL or MariaDB databases are the recommended database engines.[https://docs.nextcloud.com/server/stable/admin_manual/configuration_database/linux_database_configuration.html]


{{Note|Create or convert the database with MySQL 4-byte support in order to use Emojis (textbased smilies) on your Nextcloud server [https://docs.nextcloud.com/server/latest/admin_manual/configuration_database/mysql_4byte_support.html].}}
Most information concerning databases with Nextcloud deals with MariaDB/MySQL. The Nextcloud developers admit to have [https://github.com/nextcloud/server/issues/5912#issuecomment-318568370| less detailed expertise] with other databases.  


If you want to use Emojis, replace the following CREATE DATABASE... with:
[[PostgreSQL]] is said to deliver better performance and overall has fewer quirks compared to MariaDB/MySQL. [[SQLite]] is mainly supported for test / development installations and not recommended for production. The [https://docs.nextcloud.com/server/stable/admin_manual/configuration_database/linux_database_configuration.html list of supported databases] also contains Oracle database. This product will not be covered here.
{{bc|mysql> CREATE DATABASE '''nextcloud''' DEFAULT CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_general_ci';}}


It is recommended to set up an own database and user when using [[MariaDB]]:
=== MariaDB / MySQL ===


{{hc|$ mysql -u root -p|2=
Since [[MariaDB]] has been the default MySQL implementation in Arch Linux since 2013[https://archlinux.org/news/mariadb-replaces-mysql-in-repositories/] this text only mentions MariaDB.
mysql> CREATE DATABASE '''nextcloud''' DEFAULT CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci';
 
mysql> GRANT ALL PRIVILEGES ON '''nextcloud'''.* TO ''''nextcloud''''@'localhost' IDENTIFIED BY ''''password'''';
In case you want to run your database on the same host as Nextcloud install, [[MariaDB#Configuration|configure]] and [[start]] {{Pkg|mariadb}} (if you have not done so already). See the corresponding [[MariaDB|article]] for details. Do not forget to initialize MariaDB with {{ic|mariadb-install-db}}. It is recommended for additional security to configure MariaDB to [[MariaDB#Enable access locally only via Unix sockets|only listen on a local Unix socket]]:
mysql> FLUSH PRIVILEGES;
 
mysql> \q
{{hc|/etc/my.cnf.d/server.cnf|2=
[mysqld]
skip_networking
}}
}}


==== PostgreSQL ====
Nextcloud's own documentation [https://docs.nextcloud.com/server/stable/admin_manual/configuration_database/linux_database_configuration.html#database-read-committed-transaction-isolation-level recommends] to set the transaction isolation level to READ-COMMITTED. This is especially important when you expect high load with many concurrent transactions.


The following is an example of setting up a [[PostgreSQL]] user and database:
{{hc|/etc/my.cnf.d/server.cnf|2=
[mysqld]
transaction_isolation=READ-COMMITTED}}


{{hc|1=[postgres]$ createuser -h localhost -P nextcloud|2=
The other recommendation to set {{ic|1=binlog_format=ROW}} is obsolete. The default {{ic|MIXED}} in recent MariaDB versions is at least as good as the recommended {{ic|ROW}}. In any case the setting is only relevant when replication is applied.
Enter password for new role:
 
Enter it again:
Start the CLI tool {{ic|mysql}} with database user root. (Default password is empty, but hopefully you change it as soon as possible.)
}}


[postgres]$ createdb -O nextcloud nextcloud
{{bc|$ mysql -u root -p}}


=== PHP setup ===
Create the user and database for Nextcloud with


{{Tip|For all prerequisite PHP modules, see [https://docs.nextcloud.com/server/latest/admin_manual/installation/source_installation.html#prerequisites-label upstream documentation].}}
{{bc|
CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY &apos;''db-password''&apos;;
CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL PRIVILEGES on nextcloud.* to 'nextcloud'@'localhost';
FLUSH privileges;}}


Make sure that {{ic|session.save_path}} is configured. Install [[PHP#gd]] and {{pkg|php-intl}} as additional modules. Configure [[PHP#OPCache|OPcache]] as recommended by [https://docs.nextcloud.com/server/latest/admin_manual/installation/server_tuning.html#enable-php-opcache the documentation].
({{ic|''db-password''}} is a placeholder for the actual password of DB user ''nextcloud'' you must choose.) Quit the tool with {{ic|\q}}.


Some apps (e.g. ''News'') require the {{ic|iconv}} extension. If you wish to use these apps, uncomment the extension in {{ic|/etc/php/php.ini}}.
{{Note|MariaDB has a flawed understanding of what UTF8 means resulting in the inability to store any characters with codepoints 0x10000 and above (e.g. emojis). They 'fixed' this issue with version 5.5 by introducing a new encoding called ''utf8mb4''. Bottom line: Never ever use MariaDB's ''utf8'', always use ''utf8mb4''. In case you need to migrate see [https://docs.nextcloud.com/server/stable/admin_manual/configuration_database/mysql_4byte_support.html].}}


Depending on which database backend will be used:
So that you have decided to use MariaDB as the database of your Nextcloud installation you have to enable the corresponding PHP extension:


* For [[MySQL]], see [[PHP#MySQL/MariaDB]].
{{hc|/etc/webapps/nextcloud/php.ini|2=
* For [[PostgreSQL]], see [[PHP#PostgreSQL]].
extension=pdo_mysql
* For [[SQLite]], see [[PHP#Sqlite]].
}}


Performance may be improved through the implementation of [[PHP#Caching|caching]], see [https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/caching_configuration.html Configuring Memory Caching] on the official documentation for details.
Further configuration (related to MariaDB) is not required (contrary to the information given in Nextcloud's [https://docs.nextcloud.com/server/stable/admin_manual/configuration_database/linux_database_configuration.html#configuring-a-mysql-or-mariadb-database admin manual]).


=== Nextcloud setup ===
Now setup Nextcloud's database schema with:


{{ic|occ}} is a command-line tool that can be used to control Nextcloud. It is located in {{ic|/usr/share/webapps/nextcloud/occ}} and should be run as the {{ic|nextcloud user}}. A wrapper is provided in {{ic|/usr/bin/occ}} which will run the command using [[sudo]].
{{bc|1=
$ 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
}}


To set up Nextcloud, you can use the {{ic|$ occ maintenance:install}} command. See [https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/occ_command.html#command-line-installation-label Nextcloud documentation] for more details. For example, to set up Nextcloud with [[PostgreSQL]]:
Mind the placeholders (e.g. {{ic|''db-password''}}) and replace them with appropriate values. This command assumes that you run your database on the same host as Nextcloud. Enter {{ic|occ help maintenance:install }} and see Nextcloud's [https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/occ_command.html#command-line-installation documentation] for other options. See [[#Using the "occ" command line tool|Using the "occ" command line tool]] for Arch-specific details about this tool.


$ occ maintenance:install --database pgsql --database-name nextcloud --database-host localhost --database-user nextcloud --database-pass=<password> --data-dir /var/lib/nextcloud/data/
=== PostgreSQL ===


Alternatively, [[#Web server setup|set up Nextcloud on a web server]], then navigate to your Nextcloud instance in a web browser to access an installation wizard. Enter your database details and the location of the [[#Data directory|data directory]].
Consult the corresponding [[PostgreSQL|article]] for detailed information about PostgreSQL. In case you want to run your database on the same host as Nextcloud install, [[PostgreSQL#Initial configuration|configure]] and [[start]] {{Pkg|postgresql}} (if you have not done so already). For additional security in this scenario it is recommended to configure PostgreSQL to [[PostgreSQL#Configure PostgreSQL to be accessible exclusively through UNIX Sockets|only listen on a local UNIX socket]]:


=== Configure caching ===
{{hc|/var/lib/postgres/data/postgresql.conf|2=
listen_addresses = <nowiki>''</nowiki>
}}


It is recommended to [https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/caching_configuration.html enable caching]. The Nextcloud documentation provides instructions on [[Redis]], Memcached and [[PHP#APCu|APCu]].
Especially do not forget to initialize your database with {{ic|initdb}}. After having done so start PostgreSQL's CLI tool ''psql'' and create the database user {{ic|nextcloud}} and the database of the same name


=== Install notify_push  ===
{{hc|[postgres]$ psql|2=
CREATE USER nextcloud WITH PASSWORD &apos;''db-password''&apos;;
CREATE DATABASE nextcloud TEMPLATE template0 ENCODING 'UNICODE';
ALTER DATABASE nextcloud OWNER TO nextcloud;
GRANT ALL PRIVILEGES ON DATABASE nextcloud TO nextcloud;
\q
}}


To lower the impact of desktop and web clients on your server (polling for file activity and other notifications), you may want to install the [https://apps.nextcloud.com/apps/notify_push notify_push app]. You can do so via the web interface or with {{AUR|nextcloud-app-notify_push}}. More information can be found on the initial [https://nextcloud.com/blog/nextcloud-faster-than-ever-introducing-files-high-performance-back-end/ blog post].
({{ic|''db-password''}} is a placeholder for the password of database user ''nextcloud'' that you have to choose.)


== Hosting ==
Install the additional package {{Pkg|php-legacy-pgsql}} as dependency (pacman option {{ic|--asdeps}}) and enable the corresponding PHP extension in {{ic|/etc/webapps/nextcloud/php.ini}}:


{{Note| Nextcloud needs to be run as its own user and group (i.e. {{ic|nextcloud}}). It is using {{ic|/etc/webapps/nextcloud/}}, {{ic|/var/lib/nextcloud/}}, {{ic|/var/log/nextcloud/}} and {{ic|/run/nextcloud/}} for configurations, state data (data and apps from the app store), logs and (potentially) sockets (respectively)!}}
{{hc|/etc/webapps/nextcloud/php.ini|2=
extension=pdo_pgsql
}}


As stated above, in order to set up Nextcloud, you must set up the appropriate PHP requirements;
Now setup Nextcloud's database schema with:
additionally, you must configure a database and a webserver.


=== Web server setup ===
{{bc|1=
$ 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
}}


{{Warning|It is recommended to use HTTPS instead of plain HTTP, see [[Apache HTTP Server#TLS]] or [[Nginx#TLS]] for examples and implement this in the examples given below.}}
Mind the placeholders (e.g. {{ic|''db-password''}}) and replace them with appropriate values. This command assumes that you run your database on the same host as Nextcloud. Enter {{ic|occ help maintenance:install }} and see Nextcloud's [https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/occ_command.html#command-line-installation documentation] for other options. See [[#Using the "occ" command line tool|Using the "occ" command line tool]] for Arch-specific details about this tool.


Depending on which [[web server]] you are using, further setup is required, indicated below.
== Application server ==


==== Apache ====
There are two prevalent application servers that can be used to process PHP code: [[uWSGI]] or [https://cwiki.apache.org/confluence/display/HTTPD/PHP-FPM FPM]. ''FPM'' is specialized on PHP. The protocol used between the web server and ''FPM'' is ''fastcgi''. The tool's [https://www.php.net/manual/en/install.fpm.php documentation] leaves room for improvement. ''uWSGI'' on the other hand can serve code written in a [https://uwsgi-docs.readthedocs.io/en/latest/LanguagesAndPlatforms.html handful of languages] by means of language specific plugins. The protocol used is ''uwsgi'' (lowercase). The tool is [https://uwsgi-docs.readthedocs.io/en/latest/index.html extensively documented] - albeit the sheer amount of documentation can become confusing and unwieldy.


If you have not already, install [[Apache HTTP Server]] and install and enable [[Apache HTTP Server#PHP|Apache's PHP module]]
=== uWSGI ===


Copy the Apache configuration file to the configuration directory:
uWSGI has its own [[uWSGI|article]]. A lot of useful information can be found there. Install {{pkg|uwsgi}} and the plugin {{pkg|uwsgi-plugin-php-legacy}} - preferrably as dependencies, i.e. with {{ic|--asdeps}}. To run Nextcloud's code with (or in) uWSGI you have to configure one uWSGI specific configuration file ({{ic|nextcloud.ini}}) and define one systemd service.


# cp /usr/share/doc/nextcloud/apache.example.conf /etc/httpd/conf/extra/nextcloud.conf
{{Warning|It has to be mentioned that maintenance of uWSGI and especially of its PHP plugin has been sparse lately[https://github.com/unbit/uwsgi/issues/2287]. This has already caused [https://bugs.archlinux.org/task/73470 issues] that could only be solved by patching uWSGI code by the maintainers of Arch Linux packages, i.e. not upstream.}}


Modify the file according to your preferences. By default it includes an alias for {{ic|/nextcloud}} pointing to {{ic|/usr/share/webapps/nextcloud}}.
==== nextcloud.ini ====


And include it in {{ic|/etc/httpd/conf/httpd.conf}}:
The {{Pkg|nextcloud}} package includes a sample configuration file already in the right place {{ic|/etc/uwsgi/nextcloud.ini}}. In almost any case you will have to adapt this file to your requirements and setup. Find a [https://gist.githubusercontent.com/wolegis/fc0c01882b694777a6565aa1d0a4da47 version with lots of commented changes] (compared to the package's version). It assumes a no-frills Nextcloud installation for private use (i.e. with moderate load).


Include conf/extra/nextcloud.conf
In general keep the enabled extensions, extension specific settings and {{ic|open_basedir}} in sync with {{ic|/etc/webapps/nextcloud/php.ini}} (with the exception of opcache).


Ensure that the root location of your Nextcloud installation (e.g., {{ic|/usr/share/webapps/nextcloud}}) is accessible by the webserver's user {{ic|http}}.
{{Tip|The changes to {{ic|/etc/uwsgi/nextcloud.ini}} can become extensive. A file named {{ic|nextcloud.ini.pacnew}} will be created during package update in case there are changes in the original file provided by the package {{Pkg|nextcloud}}. In order to better track changes in this latter file and apply them to {{ic|/etc/uwsgi/nextcloud.ini}} the following approach can be applied:


Now restart Apache ({{ic|httpd.service}}).
* Make a copy of the file as provided by the package (e.g. by extracting from the package) and store it as {{ic|nextcloud.ini.package}}.
* In case an update of package {{Pkg|nextcloud}} produces a {{ic|nextcloud.ini.pacnew}} you can identify the changes with {{ic|diff nextcloud.ini.package nextcloud.ini.pacnew}}.
* Selectively apply the changes to your {{ic|nextcloud.ini}} depending on whether they make sense with your version or not.
* Move {{ic|nextcloud.ini.pacnew}} over {{ic|nextcloud.ini.package}}.
}}


If nextcloud keeps reporting an internal server error depending on your setup it might be needed to allow apache to access your files using nextcloud user permission. Install [[AUR]]: {{AUR|mod_itk}} and add this to your vhost setup:
==== uWSGI service ====
{{hc|/etc/httpd/conf/extra/nextcloud.conf|output=<nowiki>
  <IfModule mpm_itk_module>
      AssignUserId nextcloud nextcloud
  </IfModule>
</nowiki>}}
{{hc|/etc/httpd/conf/httpd.conf|output=<nowiki>
LoadModule mpm_itk_module modules/mpm_itk.so
</nowiki>}}


{{Note|
The package {{pkg|uwsgi}} provides a template unit file ({{ic|uwsgi@.service}}). The instance ID (here ''nextcloud'') is used to pick up the right configuration file. [[Enable]] and [[start]] {{ic|uwsgi@nextcloud.service}}.  
Be aware however that {{ic|mpm_itk}} is [http://mpm-itk.sesse.net/ not compatible with threading], so the Apache server can't use {{ic|mpm_event_module}} nor {{ic|mpm_worker_module}}. You will get an error message such as `mpm-itk cannot use threaded MPMs; please use prefork`. For a discussion of pros and cons of these see [https://serverfault.com/questions/383526/how-do-i-select-which-apache-mpm-to-use this Serverfault question] (mpm_itk is derived from mpm_prefork). {{ic|mod_php}} isn't compatible with threaded mpm's either, so unless you are using php-fpm you probably are already "stuck" on {{ic|mpm_prefork_module}}. However, note also that the {{ic|http2_module}} is not compatible with {{ic|mpm_prefork_module}} and hence with {{ic|mpm_itk}}…
}}


===== WebDAV =====
In case you have more than a few (e.g. 2) services started like this and get the impression this is a waste of resource you might consider using [https://uwsgi-docs.readthedocs.io/en/latest/Emperor.html emperor mode].


Nextcloud comes with its own [[WebDAV]] implementation enabled, which may conflict with the one shipped with Apache. If you have enabled WebDAV in Apache (not enabled by default), disable the modules {{ic|mod_dav}} and {{ic|mod_dav_fs}} in {{ic|/etc/httpd/conf/httpd.conf}}. See [https://forum.owncloud.org/viewtopic.php?f=17&t=7240] for details.
=== FPM ===


===== With php-fpm =====
In case you opt to use ''FPM'' as your application server install {{pkg|php-legacy-fpm}} - preferrably as a dependent package ({{ic|--asdeps}}).


Set up [[#php-fpm]] if you want to use it as a FastCGI handler with Apache. Then set it as the request handler for PHP files:
Configuration consists of a copy of {{ic|php.ini}} relevant for all applications served by ''FPM'' and a so-called pool file specific for the application (here Nextcloud). Finally you have to tweak the systemd service file.


{{hc|/etc/httpd/conf/extra/php-fpm.conf|output=<nowiki>
==== php-fpm.ini ====
DirectoryIndex index.php index.html
<FilesMatch \.php$>
  SetHandler "proxy:unix:/run/nextcloud/nextcloud.sock|fcgi://localhost/"
</FilesMatch>
</nowiki>
}}


Place {{ic|<FilesMatch>}} section directly in {{ic|<VirtualHost>}} if you use virtual hosts.
As stated earlier this article avoids modifications of PHP's central configuration in {{ic|/etc/php-legacy/php.ini}}. Instead create a ''FPM'' specific copy.


==== php-fpm ====
{{bc|
# cp /etc/php-legacy/php.ini /etc/php-legacy/php-fpm.ini
}}


{{Pkg|php-fpm}} is PHP's FastCGI implementation. It can be used by web servers that support the protocol.
Make sure it is owned and only writeable by root ({{ic|-rw-r--r-- 1 root root ... php-fpm.ini}}). Enable the op-cache, i.e. uncomment the line


Add an additional pool that runs as the {{ic|nextcloud}} user/group:
{{hc|/etc/php-legacy/php-fpm.ini|2=;zend_extension=opcache}}
{{hc|/etc/php/php-fpm.d/nextcloud.conf|2=
[nextcloud]
user = nextcloud
group = nextcloud
listen = /run/nextcloud/nextcloud.sock
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp


; should be accessible by your web server
and put the following parameters below the existing line {{ic|[opcache]}}:
listen.owner = http
listen.group = http


pm = dynamic
{{hc|/etc/php-legacy/php-fpm.ini|2=
pm.max_children = 15
opcache.enable = 1
pm.start_servers = 2
opcache.interned_strings_buffer = 16
pm.min_spare_servers = 1
opcache.max_accelerated_files = 10000
pm.max_spare_servers = 3
opcache.memory_consumption = 128
opcache.save_comments = 1
opcache.revalidate_freq = 1
}}
}}


The php-fpm service runs with the system mounted as read-only for hardening purposes, so it is necessary to explicitly grant write permissions on the appropriate Nextcloud paths.
{{Warning|Do not try to put these settings in the pool file by means of {{ic|php_value[...]}} and {{ic|php_flag[...]}}. Your ''FPM'' processes will consistently crash with the very first request.}}
Create an {{ic|override.conf}} for {{ic|php-fpm}}:
# systemctl edit php-fpm.service


Add and save following content.
==== nextcloud.conf ====
{{hc|/etc/systemd/system/php-fpm.service.d/override.conf|2=
[Service]
# Your data directory
ReadWritePaths=/var/lib/nextcloud/data


# Optional: add if you've set the default apps directory to be writable in config.php
Next you have to create a so called pool file for ''FPM''. It is responsible for spawning dedicated ''FPM'' processes for the Nextcloud application. Create a file {{ic|/etc/php-legacy/php-fpm.d/nextcloud.conf}} - you may use this [https://gist.githubusercontent.com/wolegis/0d9c83acd0c8bf83bcfb3983931bc364 functional version] as a starting point.
ReadWritePaths=/usr/share/webapps/nextcloud/apps


# Optional: unnecessary if you've set 'config_is_read_only' => true in your config.php
Again make sure this pool file is owned and only writeable by root (i.e. {{ic|-rw-r--r-- 1 root root ... nextcloud.conf}}). Depending on whether access log is configured (it is with above sample {{ic|nextcloud.conf}}) you may need to create the corresponding directory (here {{ic|/var/log/php-fpm-legacy/access}}). Adapt or add settings (especially {{ic|pm...}}, {{ic|php_value[...]}} and {{ic|php_flag[...]}}) to your liking. The settings {{ic|php_value[...]}} and {{ic|php_flag[..]}} must be consistent with the corresponding settings in {{ic|/etc/webapps/nextcloud/php.ini}} (but not {{ic|/etc/php-legacy/php-fpm.ini}}).
ReadWritePaths=/usr/share/webapps/nextcloud/config
ReadWritePaths=/etc/webapps/nextcloud/config


# Optional: add if you want to use Nextcloud's internal update process
The settings done by means of {{ic|php_value[...]}} and {{ic|php_flag[...]}} could instead be specified in {{ic|php-fpm.ini}}. But mind that settings in {{ic|php-fpm.ini}} apply for all applications served by ''FPM''.
# ReadWritePaths=/usr/share/webapps/nextcloud
}}


[[Enable]] and [[start]] the {{ic|php-fpm}} service.
{{Tip|The package {{pkg|php-legacy-fpm}} comes with its own pool file {{ic|www.conf}} that is of little use here. A good approach to get rid of it is to rename it to {{ic|www.conf.package}} and create a file {{ic|www.conf}} with only comment lines (lines starting with a semicolon). This way {{ic|www.conf}} becomes a no-op. It is also not overwritten during installation of a new version of {{pkg|php-legacy-fpm}}. Instead a file {{ic|www.conf.pacnew}} is created. You can compare this against {{ic|www.conf.package}} to see if anything significant has changed in the pool file that you may have to reproduce in {{ic|nextcloud.conf}}. Do not forget to rename {{ic|www.conf.pacnew}} to {{ic|www.conf.package}} at the end of this procedure.}}


==== Nginx ====
==== Systemd service ====


Make sure [[#php-fpm]] has been configured correctly.
''FPM'' is run as a systemd service. You have to modify the service configuration to be able to run Nextcloud. This is best achieved by means of a [[drop-in file]]:


Create a [[Nginx#Server_blocks|server block]] and add the content according to the [https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html Nextcloud documentation].
{{hc|/etc/systemd/system/php-fpm-legacy.service.d/override.conf|2=
[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
}}


Use {{ic|unix:/run/nextcloud/nextcloud.sock}} as {{ic|server}} in the {{ic|upstream php-handler}} block and {{ic|/usr/share/webapps/nextcloud}} as {{ic|root}} location:
* It replaces the {{ic|ExecStart}} line by a start command that uses the {{ic|php-fpm.ini}} covered in the previous section.
{{hc|/etc/nginx/sites-enabled/nextcloud|2=
* The directories {{ic|/var/lib/nextcloud}} and {{ic|/etc/webapps/nextcloud/config}} (and everything below) are made writable. The {{ic|1=ProtectSystem=full}} in the original service definition causes {{ic|/usr}}, {{ic|/boot}} and {{ic|/etc}} to be mounted read-only for the ''FPM'' processes.
upstream php-handler {
    server unix:/run/nextcloud/nextcloud.sock;
}


# ...
Do not forget to [[enable]] and [[start]] the service ''php-fpm-legacy''.


server {
==== Keep /etc tidy ====
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    # ...
    root /usr/share/webapps/nextcloud;
    # ...
}
}}


See [[nginx#FastCGI]] for more information on using FastCGI with nginx.
The Nextcloud package unconditionally creates the uWSGI configuration file {{ic|/etc/uwsgi/nextcloud.ini}}. Of course it is of no use when you run ''FPM'' instead of ''uWSGI'' (and it does no harm whatsoever). In case you nevertheless want to get rid of it just add the following lines to {{ic|/etc/pacman.conf}}


==== lighttpd ====
{{hc|/etc/pacman.conf|2=
# uWSGI configuration that comes with Nextcloud is not needed
NoExtract = etc/uwsgi/nextcloud.ini
}}


Enable [[lighttpd#FastCGI]], e.g. by adding {{ic|code=server.modules += ( "mod_fastcgi" )}} to {{ic|/etc/lighttpd/lighttpd.conf}}.
== Web server ==


Create a link to {{ic|/usr/share/webapps/nextcloud}} in your {{ic|/srv/http/}} directory (or configured root).
There is an abundance of web servers you can choose from. Whatever option you finally pick you have to keep in mind that the Nextcloud application needs to be run with its own system user ''nextcloud''. So you will need to forward your requests to one of the above mentioned application servers.


== Security Hardening ==
=== nginx ===


See the [https://docs.nextcloud.com/server/latest/admin_manual/installation/harden_server.html Nextcloud documentation] and [[Security]]. Nextcloud additionally provides a [https://scan.nextcloud.com/ Security scanner].
Configuration of ''nginx'' is way beyond the scope of this article. See the relevant [[nginx|article]] for further information. Also consult [https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html Nextcloud's documentation] for an elaborated configuration. It is up to you how to include this snippet into your nginx' configuration. One common approach is to use directories {{ic|/etc/nginx/sites-available}} and {{ic|/etc/nginx/sites-enabled}} to separate configurations for various servers (aka virtual hosts). See [[Nginx#Managing server entries]] for details.  


=== uWSGI ===
If using the example ''nginx'' config from the Nextcloud documentation linked above, the root directory should be changed to:


You can run Nextcloud in its own process and service by using the [[uWSGI]] application server with {{pkg|uwsgi-plugin-php}}. This allows you to define a [[PHP#Configuration|PHP configuration]] only for this instance of PHP, without the need to edit the global {{ic|php.ini}} and thus keeping your web application configurations compartmentalized. ''uWSGI'' itself has a wealth of features to limit the resource use and to harden the security of the application, and by being a separate process it can run under its own user.
{{hc|''cloud.mysite.com''.conf|  root /usr/share/webapps/nextcloud;}}


The only part that differs from [[#Nginx]] is the {{ic|<nowiki>location ~ \.php(?:$|/) {}</nowiki>}} block:
The usage of the block {{ic|upstream php-handler { ... } }} is not necessary. Just specify {{ic|fastcgi_pass unix:/run/php-fpm-legacy/nextcloud.sock;}} in the {{ic|location}} block that deals with forwarding request with PHP URIs to the application server. When using ''uWSGI'' instead of ''FPM'' replace this {{ic|location}} block with:


{{bc|<nowiki>
{{hc|''cloud.mysite.com''.conf|
  location ~ \.php(?:$|/) {
location ~ \.php(?:${{!}}/) {
     include uwsgi_params;
     include uwsgi_params;
     uwsgi_modifier1 14;
     uwsgi_modifier1 14;
Line 340: Line 362:
     uwsgi_hide_header X-Content-Type-Options;
     uwsgi_hide_header X-Content-Type-Options;
     uwsgi_hide_header X-Robots-Tag;
     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;
     uwsgi_pass unix:/run/uwsgi/nextcloud.sock;
    }
}
</nowiki>}}
}}


Then create a config file for ''uWSGI'':
Things you might have to adapt (not exhaustive):


{{hc|/etc/uwsgi/nextcloud.ini|<nowiki>
* Your server name ({{ic|server_name}} clauses 2x), i.e. the server part of the URL your Nextcloud installation will be reachable with.
[uwsgi]
* The name of the certificate and key you use for SSL / TLS.
; load the required plugins
* If and where you want an access log written to.
plugins = php
* The location where [[Certbot]] (or any other ACME client) will put the domain verification challenges. Usage of {{ic|alias}} instead of {{ic|try_files}} is probably more adequate here.
; force the sapi name to 'apache', this will enable the opcode cache 
* The path used to reach your Nextcloud installation. (The part right to the server name &amp; port section in the URL.)
php-sapi-name = apache
* What application server (uWSGI or FPM) you are using, i.e. how and where nginx will pass requests that need to trigger some PHP code. (See above.)
* Configure [[Wikipedia:OCSP_stapling|OCSP stapling]].


; set master process name and socket
There is no need to install any additional modules since nginx natively supports both protocols FastCGI and uwsgi.
; '%n' refers to the name of this configuration file without extension
procname-master = uwsgi %n
master = true
socket = /run/uwsgi/%n.sock


; drop privileges
=== Apache HTTP server ===
uid    = nextcloud
gid    = nextcloud
umask  = 027


; run with at least 1 process but increase up to 4 when needed
Find lots of useful information in the article about the [[Apache HTTP Server]]. Nextcloud's documentation has some [https://docs.nextcloud.com/server/latest/admin_manual/installation/source_installation.html#apache-web-server-configuration sample configuration] that can also be found in {{ic|/usr/share/doc/nextcloud/apache.example.conf}}. Both implicitly rely on ''mod_php'' that cannot be used anymore. ''mod_proxy_fcgi'' or ''mod_proxy_uwsgi'' need to be applied.
processes = 4
cheaper = 1


; reload whenever this config file changes
Information about how to [[Apache HTTP Server#Using php-fpm and mod_proxy_fcgi|integrate Apache with FPM]] can be found here in this wiki. uWSGI's documentation has some information about how to [https://uwsgi-docs.readthedocs.io/en/latest/Apache.html integrate Apache with PHP by means of uWSGI and mod_proxy_uwsgi]. Mind that the Apache package comes with both modules ''mod_proxy_fcgi'' and ''mod_proxy_uwsgi''. They need to be loaded as required.
; %p is the full path of the current config file
touch-reload = %p


; disable uWSGI request logging
The following Apache modules are required to run Nextcloud:
;disable-logging = true


; enforce a DOCUMENT_ROOT
{{hc|/etc/httpd/conf/httpd.conf|
php-docroot    = /usr/share/webapps/%n
# these are already loaded in a standard Apache installation
; limit allowed extensions
LoadModule headers_module modules/mod_headers.so
php-allowed-ext = .php
LoadModule env_module modules/mod_env.so
; and search for index.php if required
LoadModule dir_module modules/mod_dir.so
php-index = index.php
LoadModule mime_module modules/mod_mime.so
LoadModule setenvif_module modules/mod_setenvif.so


; set php configuration for this instance of php, no need to edit global php.ini
# these need to be uncommented explicitly
php-set = date.timezone=Etc/UTC
LoadModule rewrite_module modules/mod_rewrite.so
;php-set = open_basedir=/tmp/:/usr/share/webapps/nextcloud:/etc/webapps/nextcloud:/dev/urandom
LoadModule ssl_module modules/mod_ssl.so
php-set = expose_php=false
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
; avoid security risk of leaving sessions in world-readable /tmp
LoadModule proxy_module modules/mod_proxy.so
php-set = session.save_path=/usr/share/webapps/nextcloud/data


; port of php directives set upstream in /usr/share/webapps/nextcloud/.user.ini for use with PHP-FPM
# either this one in case you use FPM
php-set = upload_max_filesize=513M
LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so
php-set = post_max_size=513M
# or this one in case you opt for uWSGI
php-set = memory_limit=512M
LoadModule proxy_uwsgi_module modules/mod_proxy_uwsgi.so
php-set = output_buffering=off
}}


; load all extensions only in this instance of php, no need to edit global php.ini
Also uncomment the following directive to pull in TLS configuration parameters:
;; required core modules
php-set = extension=gd
php-set = extension=iconv
;php-set = extension=zip    # enabled by default in global php.ini


;; database connectors
{{hc|/etc/httpd/conf/httpd.conf|
;; uncomment your selected driver
Include conf/extra/httpd-ssl.conf}}
;php-set = extension=pdo_sqlite
;php-set = extension=pdo_mysql
;php-set = extension=pdo_pgsql


;; recommended extensions
Consult [https://ssl-config.mozilla.org/#server=apache&config=intermediate Mozilla's SSL configurator] for details about how to optimize your TLS configuration.
;php-set = extension=curl    # enabled by default in global php.ini
php-set = extension=bz2
php-set = extension=intl


;; required for specific apps
Refer to the following two sample configuration files depending on how you want to access your Nextcloud installation:
;php-set = extension=ldap    # for LDAP integration
;php-set = extension=ftp    # for FTP storage / external user authentication
;php-set = extension=imap    # for external user authentication, requires php-imap


;; recommended for specific apps
* In case your Nextcloud installation is accessed via a dedicated host name (e.g. {{ic|<nowiki>https://cloud.mysite.com/</nowiki>}}) put [https://gist.github.com/wolegis/1659786ded9128935f638ee2bf228906 this] fragment into {{ic|/etc/httpd/conf/extra/httpd-vhosts.conf}}.
;php-set = extension=exif    # for image rotation in pictures app, requires exiv2
;php-set = extension=gmp    # for SFTP storage


;; for preview generation
* In case your Nextcloud installation is located in a subfolder of your web site (e.g. {{ic|<nowiki>https://www.mysite.com/nextcloud/</nowiki>}}) put [https://gist.github.com/wolegis/002e198c2db7980a84fd8d160c2bdb9a this] fragment in your {{ic|/etc/httpd/conf/httpd.conf}}.
;; provided by packages in AUR
; php-set = extension=imagick


; opcache
Of course you must adapt these sample configuration files to your concrete setup. Replace the {{ic|SetHandler}} directive by {{ic|SetHandler "proxy:unix:/run/uwsgi/nextcloud.sock{{!}}uwsgi://nextcloud/"}} when you use ''uWSGI''.
php-set = zend_extension=opcache


; user cache
The Nextcloud package comes with a {{ic|.htaccess}} that already takes care of a lot of rewriting and header stuff. Run {{ic|occ maintenance:update:htaccess}} to adapt this file. Parameter {{ic|htaccess.RewriteBase}} in {{ic|/etc/webapps/nextcloud/config/config.php}} is vital for this.
; provided by php-acpu, to be enabled **either** here **or** in /etc/php/conf.d/apcu.ini
php-set = extension=apcu
; per https://github.com/krakjoe/apcu/blob/simplify/INSTALL
php-set = apc.ttl=7200
php-set = apc.enable_cli=1


; web server is already handling URL rewriting, so tell NextCloud not to repeat this
== Background jobs ==
env = front_controller_active=true


cron2 = minute=-15,unique=1 /usr/bin/php -f /usr/share/webapps/nextcloud/cron.php 1>/dev/null
Nextcloud requires certain tasks to be run on a scheduled basis. See Nextcloud's [https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/background_jobs_configuration.html documentation] for some details. The easiest (and most reliable) way to set up these background jobs is to use the systemd service and timer units that are already installed by {{Pkg|nextcloud}}. The service unit needs some tweaking so that the job uses the correct PHP ini-file (and not the global {{ic|php.ini}}). Create a [[drop-in file]] and add:
</nowiki>}}


{{Note|1=
{{hc|/etc/systemd/system/nextcloud-cron.service.d/override.conf|2=
* Do not forget to set your timezone and uncomment the required database connector in the uWSGI config file
[Service]
* The [[PHP#Configuration|open_basedir]] directive is optional and commented out. You can uncomment to harden security. Be aware that it may [https://github.com/owncloud/core/search?q=open_basedir&type=Issues occasionally break things].
ExecStart=
* Use {{ic|1=php-docroot = /usr/share/webapps}} if placing nextcloud in /nextcloud subdirectory.
ExecStart=/usr/bin/php-legacy -c /etc/webapps/nextcloud/php.ini -f /usr/share/webapps/nextcloud/cron.php
}}
}}


{{Warning|The way the [https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/background_jobs_configuration.html Nextcloud background job] is currently set up with [https://uwsgi-docs.readthedocs.org/en/latest/Cron.html uWSGI cron] will make use of the default global configuration from {{ic|/etc/php/php.ini}}. This means that none of the specific parameters defined (e.g. required modules) will be enabled, [https://github.com/owncloud/core/issues/12678#issuecomment-66114448 leading to various issues]. One solution is to copy {{ic|/etc/php/php.ini}} to e.g. {{ic|/etc/uwsgi/cron-php.ini}}, make the required modifications there (mirroring {{ic|/etc/uwsgi/nextcloud.ini}} parameters) and referencing it in the cron directive by adding the {{ic|-c /etc/uwsgi/cron-php.ini}} option to ''php'' invocation.}}
After that [[enable]] and [[start]] {{ic|nextcloud-cron.timer}} (not the service).


==== Activation ====
As recommended by the [https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/background_jobs_configuration.html#maintenance-window-start documentation] add the parameter


[[uWSGI]] provides a [[Systemd#Using_units|template unit]] that allows to start and enable application using their configuration file name as instance identifier. For example, [[start]]ing {{ic|uwsgi@nextcloud.socket}} would start it on demand referencing the configuration file {{ic|/etc/uwsgi/nextcloud.ini}}.
{{hc|/etc/webapps/nextcloud/config/config.php|2=
....
'maintenance_window_start' => 0,
....
}}


To enable the uwsgi service by default at start-up, [[enable]] {{ic|uwsgi@nextcloud.socket}}.
to Nextcloud's configuration file. The value is the hour of the day in UTC defining the start of a 4 hours window. Time consuming jobs that need to be run only once a day will be scheduled in this time frame, i.e. outside working hours.  


{{Note|Here we make use of [http://0pointer.de/blog/projects/socket-activation.html systemd socket activation] to prevent unnecessary resources consumption when no connections are made to the instance. If you would rather have it constantly active, simply remove the {{ic|.socket}} part to start and enable the service instead.}}
{{Warning|Do not try to install and use {{AUR|nextcloud-systemd-timers}}. It is outdated and unmaintained.}}


See also [[UWSGI#Running uWSGI]].
== In-memory caching ==


== Synchronization ==
Nextcloud's [https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/caching_configuration.html documentation] recommends to apply some kind of in-memory object cache to significantly improve performance.


=== Desktop ===
{{Note|Mind that [https://github.com/nextcloud/notify_push push notify] (the Nextcloud service that replaces client polling by notification by the server thus drastically reducing sync latency) depends on ''Redis''.}}


The official client can be installed with the {{Pkg|owncloud-client}} or {{Pkg|nextcloud-client}} package.
=== APCu ===
Alternative versions are available in the [[AUR]]: {{AUR|owncloud-client-git}}. Additional packages are needed for some features:


* '''Auto-login:''' All of them use {{Pkg|qtkeychain}}{{Broken package link|replaced by {{Pkg|qtkeychain-qt5}}}} to store and retrieve account-specific access tokens. To achieve auto-login when the client starts, one of optional dependencies of ''qtkeychain'' should be installed as well. Moreover, if you choose {{Pkg|libsecret}} as the backend for ''qtkeychain'', a service that provides [https://archlinux.org/packages/?q=org.freedesktop.secrets org.freedesktop.secrets] should be running when the client starts.
Install {{Pkg|php-legacy-apcu}} (as dependency {{ic|--asdeps}}). Enable the extension in the relevant configuration files. These are
* '''File manager integration:''' for {{Pkg|nextcloud-client}}, integration with file managers (e.g., show Nextcloud folders in GTK+ file dialogs) requires another package {{Pkg|nextcloud-client-cloudproviders}}. {{Pkg|owncloud-client}} already includes cloudproviders supports by default.


==== Calendar ====
* {{ic|/etc/webapps/nextcloud/php.ini}} used by the {{ic|occ}} command and the background jobs and
* depending on the application server you use either
** {{ic|/etc/uwsgi/nextcloud.ini}} in case of ''uWSGI'' or
** {{ic|/etc/php-legacy/php-fpm.d/nextcloud.conf}} in case of ''FPM''.


To access your Nextcloud calendars using Mozilla [[Thunderbird]]'s Lightning calendar you would use the following URL:
In {{ic|/etc/webapps/nextcloud/php.ini}} add the lines


<nowiki>https://ADDRESS/remote.php/caldav/calendars/USERNAME/CALENDARNAME</nowiki>
{{hc|/etc/webapps/nextcloud/php.ini|2=
extension=apcu
apc.ttl=7200
apc.enable_cli = 1
}}


To access your Nextcloud calendars using CalDAV-compatible programs like Kontact or [[Evolution]], you would use the following URL:
(preferably somewhere below {{ic|Module Settings}}).


<nowiki>https://ADDRESS/remote.php/caldav</nowiki>
For the other two files the setting to activate ''APCu'' is already in place and only needs to be uncommented. Two other configuration parameters related to ''APCu'' are also already there. No need to touch {{ic|/etc/php-legacy/php.ini}} or {{ic|/etc/php-legacy/conf.d/apcu.ini}}.


For details see the [https://docs.nextcloud.com/server/latest/user_manual/en/pim/index.html official documentation].
Restart your application server (not the web server as Nextcloud's documentation claims). Add the following line to your Nextcloud configuration file:


==== Contacts ====
{{hc|/etc/webapps/nextcloud/config/config.php|2='memcache.local' => '\OC\Memcache\APCu',}}


To sync contacts with [[Thunderbird]], see [https://docs.nextcloud.com/server/latest/user_manual/pim/sync_thunderbird.html these instructions] from the official doc.
=== Redis ===


==== Mounting files with davfs2 ====
Install {{Pkg|php-legacy-igbinary}} and {{Pkg|php-legacy-redis}} (as dependency {{ic|--asdeps}}) in case you run this component locally (i.e. on the same host as ''Nextcloud''). Alternatively the ''Redis'' server can be run on a different machine. For more information see [https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/caching_configuration.html#id2 Nextcloud's documentation].


If you want to mount your Nextcloud using WebDAV, install {{Pkg|davfs2}} (as described in [[davfs2]]).
{{Note|Using ''Redis'' does not exclude using ''APCu'' in parallel as a local cache. In fact, Nextcloud's documentation recommends this setup.}}


To mount your Nextcloud, use:
Enable the required extensions {{ic|igbinary}} and {{ic|redis}} in the relevant configuration files. These are:


# mount -t davfs https://''your_domain''/nextcloud/remote.php/dav/files/''username''/ /path/to/mount
* {{ic|/etc/webapps/nextcloud/php.ini}} used by the {{ic|occ}} command and the background jobs and
* depending on the application server you use either
** {{ic|/etc/uwsgi/nextcloud.ini}} in case of ''uWSGI'' or
** {{ic|/etc/php-legacy/php-fpm.d/nextcloud.conf}} in case of ''FPM''.


You can also create an entry for this in {{ic|/etc/fstab}}
Locate the existing sections where other extensions are enabled and add two additional lines corresponding to {{ic|igbinary}} and {{ic|redis}}.


{{hc|/etc/fstab|
{{Note|It is important to load {{ic|1=extension=igbinary}} before {{ic|1=extension=redis}}. Otherwise {{ic|occ}} will report an error (''/usr/lib/php-legacy/modules/redis.so: undefined symbol: igbinary_serialize'').}}
https://''your_domain''/nextcloud/remote.php/dav/files/''username''/ /path/to/mount davfs rw,user,noauto 0 0
}}


{{Tip|In order to allow automount you can also store your username (and password if you like) in a file as described in [[davfs2#Storing credentials]].}}
In case you have specified the {{ic|open_basedir}} option in the above configuration files and use ''Redis'' locally with a local Unix socket, you have to extend the list of directories where PHP is allowed to read and write files. Locate the relevant lines in the files specified above and add  the directory containing the local Unix socket created by ''Redis'', e.g. {{ic|/run/redis}}.


{{Note|If creating/copying files is not possible, while the same operations work on directories, see [[davfs2#Creating/copying files not possible and/or freezes]].}}
{{Note|The sample configuration files [https://gist.githubusercontent.com/wolegis/fc0c01882b694777a6565aa1d0a4da47 nextcloud.ini] and [https://gist.githubusercontent.com/wolegis/0d9c83acd0c8bf83bcfb3983931bc364 nextcloud.conf] mentionend in the [[#Application server]] section already have {{ic|open_basedir}} enabled. So in case you use a copy of one of these files you have to adapt it.}}


=== Mounting files in GNOME Files (Nautilus) ===
Extend your Nextcloud configuration as follows:


You can access the files directly in Nautilus ('+ Other Locations') through WebDAV protocol - use the link as shown in your Nextcloud installation Web GUI (typically: https://example.org/remote.php/webdav/) but replace the protocol name from 'https' to 'davs'. Nautilus will ask for user name and password when trying to connect.
{{hc|1=/etc/webapps/nextcloud/config/config.php|2=
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
    'host'    => '/run/redis/redis.sock',
    'port'     => 0,
    'dbindex'  => 0,
    'password' => '<wbr>',
    'timeout'  => 1.5,
],
}}


=== Android ===
Again, adapt {{ic|/run/redis/redis.sock}} as required. {{ic|dbindex}}, {{ic|password}} and {{ic|timeout}} are optional.


Download the official Nextcloud app from [https://play.google.com/store/apps/details?id=com.nextcloud.client Google Play] or [https://f-droid.org/packages/com.nextcloud.client/ F-Droid].
In case ''Redis'' runs on a different machine:


To enable contacts and calendar sync (Android 4+):
{{hc|1=/etc/webapps/nextcloud/config/config.php|2=
# download [https://www.davx5.com/ DAVx<sup>5</sup>] ([https://play.google.com/store/apps/details?id=at.bitfire.davdroid Play Store], [https://f-droid.org/app/at.bitfire.davdroid F-Droid])
'memcache.local' => '\OC\Memcache\APCu',
# Enable mod_rewrite.so in httpd.conf
'memcache.distributed' => '\OC\Memcache\Redis',
# create a new DAVdroid account in the ''Account'' settings, and specify your "short" server address and login/password couple, e.g. {{ic|<nowiki>https://cloud.example.com</nowiki>}} (there is no need for the {{ic|<nowiki>/remote.php/{carddav,webdav}</nowiki>}} part if you configured your web server with the proper redirections, as illustrated previously in the article; ''DAVdroid'' will find itself the right URLs)
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
    'host' => &apos;''redis-host.mysite.com''&apos;,
    'port' => 6379,
],
}}


=== iOS ===
{{ic|''redis-host.mysite.com''}} is just a placeholder. Adapt to your actual setup.


Download the official Nextcloud app from the [https://itunes.apple.com/us/app/nextcloud/id1125420102 App Store].
== Security Hardening ==


== Tips and tricks ==
See the [https://docs.nextcloud.com/server/latest/admin_manual/installation/harden_server.html Nextcloud documentation] and [[Security]]. Nextcloud additionally provides a [https://scan.nextcloud.com/ Security scanner].


=== Using the ownCloud console ===
== Synchronization ==


A useful tool for server administration is {{ic|occ}}, documented [https://docs.nextcloud.com/server/20/admin_manual/configuration_server/occ_command.html here]. You can perform many common server operations with occ, such as managing users and configuring apps.
{{Tip|It is recommended not to use your personal password but so-called app tokens for all software automatically authenticating against your Nextcloud server. This way in case you suspect credentials in one of the programs may have leaked you just need to revoke this one affected app token - instead of having to change your personal password and propagating this change to all places where it has been stored. You can generate a new app token in Nextcloud's web GUI in ''Settings > Security'' in the ''Devices & Sessions'' section.}}


{{Tip| A convenience wrapper around {{ic|/usr/share/webapps/nextcloud/occ}} is provided with {{ic|/usr/bin/occ}}, which automatically runs as the default user ({{ic|nextcloud}}), using the default [[PHP]] and PHP configuration file.
=== Desktop ===
The environment variables {{ic|NEXTCLOUD_USER}}, {{ic|NEXTCLOUD_PHP}} and {{ic|NEXTCLOUD_PHP_CONFIG}} can be used to specify a non-default user, PHP executable and PHP configuration file (respectively).}}


{{Warning| When using {{pkg|php-apcu}} for caching, make sure to set {{ic|1= apc.enable_cli=1}} in {{ic|/etc/php/conf.d/apcu.ini}}, as the {{ic|occ}} command will otherwise run out of memory ([https://bugs.archlinux.org/task/69726 FS#69726]).}}
The official client can be installed with the {{Pkg|nextcloud-client}} package. Alternative versions are available in the [[AUR]]: {{AUR|nextcloud-client-git}}. Please keep in mind that using {{Pkg|owncloud-client}} with Nextcloud is not supported.


=== Pacman hook ===
The desktop client basically syncs one or more directories of your desktop computer with corresponding folders in your Nextcloud's file service. It integrates nicely with your desktop's file manager (Dolphin in KDE Plasma, Nautilus in Gnome) displaying overlays representing synchronization and share status. The context menu of each file gets an additional entry ''Nextcloud'' to manage sharing of this file and getting the public or internal share link. Nextcloud's documentation has a [https://docs.nextcloud.com/desktop/latest/ volume] exclusively about the desktop client.


To automatically upgrade the Nextcloud database on package update, you can make use of the included [[pacman hook]]:
In case the integration does not work as described consult the optional dependencies of package {{Pkg|nextcloud-client}} ({{ic|pacman -Qi nextcloud-client}}). E.g. Nautilus (Gnome) requires {{Pkg|python-nautilus}}. Install as dependent package with {{ic|pacman -S --asdeps}}).


  # mkdir -vp /etc/pacman.d/hooks
{{Note|The desktop client provides a system tray icon that indicates sync status[https://docs.nextcloud.com/desktop/latest/visualtour.html], but GNOME does not provide a system tray icon API out-of-the-box[https://gitlab.archlinux.org/archlinux/packaging/packages/nextcloud-client/-/issues/5#note_180692]. If this is a desired feature, one possible solution is to install and enable {{Pkg|gnome-shell-extension-appindicator}}. See [[GNOME#Extensions]] for more info.}}
  # ln -sv /usr/share/doc/nextcloud/nextcloud.hook /etc/pacman.d/hooks/


{{Note| The packaged pacman hook implies, that the global {{ic|php.ini}} is used for the application.}}
=== Thunderbird ===


=== Running Nextcloud in a subdirectory ===
Since version 102 [[Thunderbird]] fully supports CalDAV and CardDAV - even with auto detection (i.e. you do not have to provide long URLs to access your calendars and address books). See Nextcloud's [https://docs.nextcloud.com/server/latest/user_manual/en/groupware/sync_thunderbird.html documentation] for details.


By including the default {{ic|nextcloud.conf}} in {{ic|httpd.conf}}, Nextcloud will take control of port 80 and your localhost domain.
=== Mounting files with davfs2 ===


If you would like to have Nextcloud run in a subdirectory, then
If you want to mount your Nextcloud using WebDAV, install {{AUR|davfs2}} (as described in [[davfs2]]).


For apache, edit the {{ic|/etc/httpd/conf/extra/nextcloud.conf}} you included and comment out the {{ic|<nowiki><VirtualHost *:80> ... </VirtualHost></nowiki>}} part of the include file.
To mount your Nextcloud, use:


For nginx, you can use the following config when using Nextcloud with uwsgi:
{{bc|
# mount -t davfs https://''cloud.mysite.com''/remote.php/dav/files/''username''/ ''/path/to/mount''
}}


{{hc|head=/etc/nginx/conf.d/nextcloud.conf|output=<nowiki>
You can also create an entry for this in {{ic|/etc/fstab}}:
location = /.well-known/carddav {
  return 301 $scheme://$host/nextcloud/remote.php/dav;
}


location = /.well-known/caldav {
{{hc|/etc/fstab|
  return 301 $scheme://$host/nextcloud/remote.php/dav;
https://''cloud.mysite.com''/remote.php/dav/files/''username''/ ''/path/to/mount'' davfs rw,user,noauto 0 0
}
}}


location /.well-known/acme-challenge { }
{{Tip|In order to allow automount you can also store your username (and password if you like) in a file as described in [[davfs2#Storing credentials]].}}


location ^~ /nextcloud {
{{Note|If creating/copying files is not possible, while the same operations work on directories, see [[davfs2#Creating/copying files not possible and/or freezes]].}}


  root /usr/share/webapps;
=== Mounting files in GNOME Files (Nautilus) ===


  # set max upload size
You can access the files directly in Nautilus ('+ Other Locations') via the WebDAV protocol. Use the link as shown in your Nextcloud installation Web GUI (e.g. {{ic|<nowiki>https://cloud.mysite.com/remote.php/webdav/</nowiki>}}) but replace the protocol name {{ic|https}} by {{ic|davs}}. Nautilus will ask for user name and password when trying to connect.
  client_max_body_size 512M;
  fastcgi_buffers 64 4K;


  # Disable gzip to avoid the removal of the ETag header
=== Android ===
  gzip off;


  # Uncomment if your server is build with the ngx_pagespeed module
Download the official Nextcloud app from [https://play.google.com/store/apps/details?id=com.nextcloud.client Google Play] or [https://f-droid.org/packages/com.nextcloud.client/ F-Droid].
  # This module is currently not supported.
  #pagespeed off;


  location /nextcloud {
To enable contacts and calendar sync (Android 4+):
    rewrite ^ /nextcloud/index.php$uri;
  }


  location ~ ^/nextcloud/(?:build|tests|config|lib|3rdparty|templates|data)/ {
# Download [https://www.davx5.com/ DAVx<sup>5</sup>] ([https://play.google.com/store/apps/details?id=at.bitfire.davdroid Play Store], [https://f-droid.org/app/at.bitfire.davdroid F-Droid]).
    deny all;
# Create a new DAVdroid account in the ''Account'' settings and specify your server URL (e.g. {{ic|<nowiki>https://cloud.mysite.com</nowiki>}}) and login / password pair.
  }


  location ~ ^/nextcloud/(?:\.|autotest|occ|issue|indie|db_|console) {
{{Note|There is no need for the {{ic|/remote.php/{carddav,webdav}<nowiki/>}} part if you configured your web server with the proper redirections, as illustrated in the above section [[#Web server|Web server]]. ''DAVdroid'' will find itself the right URLs.}}
    deny all;
  }


  location ~ ^/nextcloud/(?:updater|ocs-provider)(?:$|/) {
=== iOS ===
    try_files $uri/ =404;
    index index.php;
  }


  location ~ ^/nextcloud/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) {
Download the official Nextcloud app from the [https://itunes.apple.com/us/app/nextcloud/id1125420102 App Store].
    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_pass unix:/run/uwsgi/owncloud.sock;
  }


  # Adding the cache control header for js and css files
== Tips and tricks ==
  # Make sure it is BELOW the PHP block
  location ~* \.(?:css|js) {
    try_files $uri /nextcloud/index.php$uri$is_args$args;
    add_header Cache-Control "public, max-age=7200";
    # Add headers to serve security related headers  (It is intended
    # to have those duplicated to the ones above)
    # Before enabling Strict-Transport-Security headers please read
    # into this topic first.
    # add_header Strict-Transport-Security "max-age=15768000;
    # includeSubDomains; preload;";
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    add_header X-Download-Options noopen;
    add_header X-Permitted-Cross-Domain-Policies none;
    # Optional: Do not log access to assets
    access_log off;
  }


  location ~* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg) {
=== Using the "occ" command line tool ===
    try_files $uri /nextcloud/index.php$uri$is_args$args;
    # Optional: Do not log access to other assets
    access_log off;
  }
}
</nowiki>}}


{{Note| Do not forget to configure the {{ic |.well-known}} URLs for service discovery. For more information please see [https://docs.nextcloud.com/server/18/admin_manual/issues/general_troubleshooting.html#service-discovery General troubleshooting and service discovery section of Nextcloud documentation]. }}
A useful tool for server administration is {{ic|occ}}. Refer to Nextcloud's documentation for [https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/occ_command.html details]. You can perform many common server operations with {{ic|occ}}, such as managing users and configuring apps.


=== Docker ===
A convenience wrapper around the original {{ic|/usr/share/webapps/nextcloud/occ}} is provided with {{ic|/usr/bin/occ}} which automatically runs as the default user (''nextcloud''), using the default PHP executable and PHP configuration file. The environment variables {{ic|NEXTCLOUD_USER}}, {{ic|NEXTCLOUD_PHP}} and {{ic|NEXTCLOUD_PHP_CONFIG}} can be used to specify a non-default user, PHP executable and PHP configuration file (respectively). Especially the latter (using {{ic|NEXTCLOUD_PHP_CONFIG}}) is necessary when Nextcloud was setup in a way as described in the sections [[#Configuration|Configuration]] and [[#Application server|Application server]], i.e. using a PHP configuration specific to Nextcloud. In this case put {{ic|1=export NEXTCLOUD_PHP_CONFIG=/etc/webapps/nextcloud/php.ini}} in your {{ic|.bashrc}}.


See the [https://hub.docker.com/_/owncloud/ ownCloud] or [https://github.com/nextcloud/docker Nextcloud] repository for [[Docker]].
When using package {{Pkg|php}} instead of the recommended package {{Pkg|php-legacy}} you also have to set {{ic|NEXTCLOUD_PHP}}, i.e. {{ic|1=export NEXTCLOUD_PHP=/usr/bin/php}}.


=== Upload and share from File Manager ===
{{Warning| When using {{pkg|php-legacy-apcu}} for caching, make sure to set {{ic|1= apc.enable_cli=1}} in {{ic|/etc/webapps/nextcloud/php.ini}}. Otherwise the {{ic|occ}} command will complain about APCu not being configured properly.}}


[https://github.com/schiesbn/shareLinkCreator shareLinkCreator] provides the ability to upload a file to
=== Pacman hook ===
OwnCloud via a supported file manager and receive a link to the uploaded file which can then be emailed or shared in another way.


=== Defining Background Jobs ===
The {{Pkg|nextcloud}} package comes with a [[pacman hook]] that takes care of automatically upgrading the Nextcloud database after the package has been updated. Take a look {{ic|/usr/share/doc/nextcloud/nextcloud.hook}}.


Nextcloud requires scheduled execution of some tasks, and by default it achieves this by using AJAX,
Unfortunately, this hook unconditionally uses the global {{ic|php.ini}} when running {{ic|occ upgrade}}, i.e. it does not take into account the value of environment variable {{ic|NEXTCLOUD_PHP_CONFIG}} as mentioned above in [[#Using the "occ" command line tool|Using the "occ" command line tool]].
however AJAX is the least reliable method, and it is recommended to use [[Cron]] instead. However,
ArchLinux ships with {{Pkg|systemd}}, so the preferred way of executing scheduled tasks is a [[systemd timer]].  


==== Manual install ====
As a possible workaround make a copy of the delivered hook file in the appropriate location:


First create a service:
{{bc|
# mkdir -vp /etc/pacman.d/hooks
# cp -a /usr/share/doc/nextcloud/nextcloud.hook /etc/pacman.d/hooks/10-nextcloud.hook
}}


{{hc|/etc/systemd/system/nextcloudcron.service|<nowiki>
and change the line starting with {{ic|Exec}} to:
[Unit]
Description=Nextcloud cron.php job


[Service]
{{hc|1=/etc/pacman.d/hooks/10-nextcloud.hook|2=
User=nextcloud
Exec = /usr/bin/runuser -u nextcloud -- /usr/bin/php-legacy --php-ini /etc/webapps/nextcloud/php.ini /usr/share/webapps/nextcloud/occ upgrade
ExecStart=/usr/bin/php -f /usr/share/webapps/nextcloud/cron.php
}}


[Install]
=== Running Nextcloud in a subdirectory ===
WantedBy=basic.target
</nowiki>}}


Then create a timer for that service:
The instructions in section [[#Web server|Web server]] will result in a setup where your Nextcloud installation is reachable via a dedicated server name, e.g. {{ic|cloud.mysite.com}}. If you would like to have Nextcloud located in a subdirectory. e.g. {{ic|www.mysite.com/nextcloud}}, then:


{{hc|/etc/systemd/system/nextcloudcron.timer|<nowiki>
* For nginx refer to the section in Nextcloud's documentation that explicitly covers this [https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html#nextcloud-in-a-subdir-of-the-nginx-webroot topic].
[Unit]
Description=Run Nextcloud cron.php every 5 minutes


[Timer]
* For apache edit the {{ic|/etc/httpd/conf/extra/nextcloud.conf}} you included and comment out the {{ic|<nowiki><VirtualHost *:80> ... </VirtualHost></nowiki>}} part of the include file.
OnBootSec=5min
OnUnitActiveSec=5min
Unit=nextcloudcron.service


[Install]
{{Note| Do not forget to configure the {{ic |.well-known}} URLs for service discovery. For more information please see [https://docs.nextcloud.com/server/latest/admin_manual/issues/general_troubleshooting.html#service-discovery Service discovery] in Nextcloud's documentation.}}
WantedBy=timers.target
</nowiki>}}


==== Activate timer ====
=== Docker ===


[[Start/enable]] {{ic|nextcloudcron.timer}}.
See the [https://hub.docker.com/_/nextcloud Nextcloud] repository on Docker Hub for running Nextcloud in [[Docker]].


Confirm that it is running by running
=== Office integration ===


# systemctl list-timers
There are currently three different solutions for office integration:


==== AUR package ====
* [https://www.collaboraoffice.com/collabora-online/ Collabora Online]
* [https://www.onlyoffice.com/ ONLYOFFICE]
* [https://docs.microsoft.com/en-us/officeonlineserver/office-online-server-overview MS Office Online Server]


Install {{AUR|nextcloud-systemd-timers}}.
All three have in common that a dedicated server is required and your web server needs to be adapted to forward certain requests to the office service. The actual integration with Nextcloud is then accomplished by means of a Nextcloud app specific for one of the above products.


Provided services can be checked with:
Mind that all three products are aimed at businesses, i.e. you will have to pay for the office service. Only Collabora offers a developers plan ([https://www.collaboraoffice.com/code/ CODE]) for free. ONLYOFFICE offers a [https://www.onlyoffice.com/en/docs-enterprise-prices.aspx Home Server] plan for a reasonable price.
$ pacman -Ql nextcloud-systemd-timers


For instance, to run the <code>cron.php</code> script every 5 minutes:
For installation, setup instructions and integration with Nextcloud consult:
# systemctl start nextcloud-cron.timer
# systemctl enable nextcloud-cron.timer


=== Collabora Online Office integration ===
* [https://nextcloud.com/collaboraonline/ Collabora online], [https://apps.nextcloud.com/apps/richdocuments app]
* [https://api.onlyoffice.com/editors/nextcloud ONLYOFFICE], [https://apps.nextcloud.com/apps/onlyoffice app]
* [https://github.com/nextcloud/officeonline MS Office Online Server], [https://apps.nextcloud.com/apps/officeonline app]


{{Expansion|What is the correct {{ic|domain}} (or {{ic|server_name}} in the config) when [[#Running NextCloud in a subdirectory|Nextcloud runs in a subdirectory]]?}}
=== Disabling app recommendations ===


==== Solution with Docker ====
By default, Nextcloud recommends apps to new clients, which can result in a lot of notifications. To disable this, disable the recommendations app using {{ic|occ app:disable recommendations}}.


The first, install a {{Pkg|docker}} package to provide collabora files and setup a Collabora server.
=== Backup calendars and address books with calcardbackup ===


[[Start/enable]] {{ic|docker.service}}.
The {{AUR|calcardbackup}} package can be installed and configured to provide regular backups of the calendar and/or address book databases. Edit {{ic|/etc/calcardbackup/calcardbackup.conf}} to your liking and then [[start]] and [[enable]] {{ic|calcardbackup.timer}}.


Then, download the official Docker image:
== Troubleshooting ==


# docker pull collabora/code
=== Reading the log ===


And, installing a Collabora server. Make sure {{ic|cloud//.example//.com}} is your nextcloud's domain, not a collabora :
By default, the logs of the web application are available in {{ic|/var/log/nextcloud/nextcloud.log}}. The entries (lines) are in JSON format and can be very long. Readability can be greatly improved by using {{Pkg|jq}}:


# docker run -t -d -p 127.0.0.1:9980:9980 -e "domain=cloud\\.example\\.com" --restart always --cap-add MKNOD collabora/code
{{bc|# jq . </var/log/nextcloud/nextcloud.log {{!}} less}}


Also make sure to escape all dots with double backslashes (\), since this string will be evaluated as a regular expression (and your bash 'eats' the first backslash.) If you want to use the docker container with more than one Nextcloud, you will need to use 'domain=cloud\\.example\\.com\|second\\.example\\.com' instead. (All hosts are separated by \|.) When using `localhost` as domain for testing you need to add {{ic|--net host}} to ensure the docker container can access your Nextcloud server.
=== Work around "is_file(): open_basedir restriction in effect" ===


If you need to delete or reinstall Collabora server use:
With Nextcloud v28.0.4 a regression was introduced that manifests in error messages containing


For recognition CONTAINER_ID of server
is_file(): open_basedir restriction in effect


# docker ps
in the log file {{ic|/var/log/nextcloud/nextcloud.log}}. The file path given after this messages is missing one slash at one position, whereas at another position there is one too many, e.g.


Stop and delete
File (/usr/share/webapps/nextcloudapps//dav/l10n/de.js)


# docker stop CONTAINER_ID
This is a known [https://github.com/nextcloud/server/issues/44358 bug] that has already been [https://github.com/nextcloud/server/pull/44408 fixed] and [https://github.com/nextcloud/server/pull/44413 backported to v28.0.5]. For v28.0.4 you may apply the following work-around:
# docker rm CONTAINER_ID


Futher, follow the instruction of webserver you are using:
* Add a symbolic link {{ic|/usr/share/webapps/nextcloudapps}} pointing to {{ic|/usr/share/webapps/nextcloud/apps}}


'''Nginx setup example:'''
{{bc|# cd /usr/share/webapps
# ln -sf nextcloud/apps nextcloudapps
}}


Add following to your nextcloud domain config or add new config file in /etc/nginx/conf.d/ directory, (Do not forget to change {{ic|office.example.com}} and {{ic|ssl_certificate}} to the right values. If you are using docker image, change {{ic|http}} to {{ic|https}}.)
* Add the path of this symbolic link to the {{ic|open_basedir}} settings relevant for your Nextcloud installation. These are:


{{hc|/etc/nginx/conf.d/example.conf|<nowiki>
{{hc|1=/etc/webapps/nextcloud/php.ini|
upstream office.example.com {
2=open_basedir=...:/usr/share/webapps/nextcloudapps:...}}
    server 127.0.0.1:9980;
}


server {
and depending on the application server you use either (FPM)
    listen 443 ssl;
    server_name office.example.com;
    ssl_certificate /etc/letsencrypt/live/office.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/office.example.com/privkey.pem;


    # static files
{{hc|1=/etc/php-legacy/php-fpm.d/nextcloud.conf|
    location ^~ /loleaflet {
2=php_value[open_basedir] = ...:/usr/share/webapps/nextcloudapps:...}}
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $host;
    }


    # WOPI discovery URL
or (uWSGI)
    location ^~ /hosting/discovery {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $host;
    }


    # Main websocket
{{hc|1=/etc/uwsgi/nextcloud.ini|
    location ~ /lool/(.*)/ws$ {
2=php-set = open_basedir=...:/usr/share/webapps/nextcloudapps:...}}
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 36000s;
    }


    # Admin Console websocket
With v28.0.5 you should be able to roll back this work-around again.
    location ^~ /lool/adminws {
proxy_buffering off;
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 36000s;
    }


    # download, presentation and image upload
=== Upgrading v27 to v28 ===
    location ~ /lool {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $host;
    }


    location ^~ /hosting/capabilities {
Upgrading a version 27 installation to version 28 requires the following steps:
        proxy_pass http://localhost:9980;
        proxy_set_header Host $http_host;
    }


}
==== Install and enable extension sodium ====
</nowiki>}}


Restart a nginx:
With version 28 it is recommended to install and enable PHP extension ''sodium'' that provides the argon2 hashing algorithm. Install the corresponding package {{Pkg|php-legacy-sodium}} as a dependency (i.e. with {{ic|--asdeps}}) and  enable it in two places:


# nginx -s reload
* {{ic|/etc/webapps/nextcloud/php.ini}} used by the {{ic|occ}} command and the background jobs and
* depending on the application server you use either
** {{ic|/etc/uwsgi/nextcloud.ini}} in case of ''uWSGI'' or
** {{ic|/etc/php-legacy/php-fpm.d/nextcloud.conf}} in case of ''FPM''.


or [[restart]] {{ic|nginx.service}}.
Just look for the existing sections where other extensions are enabled and add an additional line corresponding to {{ic|sodium}}.


'''Apache setup example:'''
==== Add maintenance_window_start to configuration ====


Add following to nextcloud config file. Do not forget to change to the right values
It is recommended to add parameter {{ic|maintenance_window_start}} to Nextcloud's configuration file {{ic|/etc/webapps/nextcloud/config/config.php}}. See section [[#Background jobs]] and Nextcloud's [https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/background_jobs_configuration.html#maintenance-window-start documentation] for details.


{{hc|/etc/httpd/conf/extra/nextcloud.conf|<nowiki>
==== Work around "ResourceLocator can not find a web root" ====
<VirtualHost *:443>
ServerName office.nextcloud.com:443


# SSL configuration, you may want to take the easy route instead and use Lets Encrypt!
{{Note|This issue has been resolved with version v28.0.4.}}
SSLEngine on
SSLCertificateFile /path/to/signed_certificate
SSLCertificateChainFile /path/to/intermediate_certificate
SSLCertificateKeyFile /path/to/private/key
SSLProtocol            all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
SSLHonorCipherOrder    on


# Encoded slashes need to be allowed
Up until version 28.0.3 Nextcloud suffers a regression that manifests in the log {{ic|/var/log/nextcloud/nextcloud.log}} being flooded with messages like
AllowEncodedSlashes NoDecode


# Container uses a unique non-signed certificate
: ResourceLocator can not find a web root
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off


# keep the host
See the corresponding [https://github.com/nextcloud/server/issues/42493 GitHub ticket]. Fortunately, the issue has no impact on Nextcloud's functionality, but real problems may become burried in this log noise. The work-around is to change Nextcloud's configuration file:
ProxyPreserveHost On


# static html, js, images, etc. served from loolwsd
{{hc|/etc/webapps/nextcloud/config/config.php|2=
# loleaflet is the client part of LibreOffice Online
  'apps_paths' =>
ProxyPass          /loleaflet https://127.0.0.1:9980/loleaflet retry=0
  array (
ProxyPassReverse    /loleaflet https://127.0.0.1:9980/loleaflet
    0 =>
    array (
      'path' => '/usr/share/webapps/nextcloud/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => &apos;'''/usr/share/webapps/nextcloud/wapps'''&apos;,
      'url' => '/wapps',
      'writable' => true,
    ),
  ),
}}


# WOPI discovery URL
{{ic|/usr/share/webapps/nextcloud/wapps}} is a symlink to {{ic|/var/lib/nextcloud/apps}}. It is part of the {{Pkg|nextcloud}} package - so usually is already present. If it does not exist for whatever reason create it with:
ProxyPass          /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
ProxyPassReverse    /hosting/discovery https://127.0.0.1:9980/hosting/discovery


# Main websocket
{{bc|# ln -sf /var/lib/nextcloud/apps /usr/share/webapps/nextcloud/wapps}}
ProxyPassMatch "/lool/(.*)/ws$" wss://127.0.0.1:9980/lool/$1/ws nocanon


# Admin Console websocket
When the issue has been resolved the {{ic|path}} can be changed back to {{ic|/var/lib/nextcloud/apps}}.
ProxyPass  /lool/adminws wss://127.0.0.1:9980/lool/adminws


# Download as, Fullscreen presentation and Image upload operations
=== Migrating to php-legacy ===
ProxyPass          /lool https://127.0.0.1:9980/lool
ProxyPassReverse    /lool https://127.0.0.1:9980/lool
</VirtualHost>
</nowiki>}}


After configuring these do restart your apache by [[restart]]ing {{ic|httpd.service}}.
In the past it had happened several times that the {{Pkg|php}} package was updated to the latest PHP version in a timely manner (in line with Arch Linux' rolling release philosophy) but Nextcloud not being compatible with this brand new version - breaking existing installations and causing lots of efforts for maintainers and users of package {{Pkg|nextcloud}}. When package {{Pkg|php}} switched from version 8.1 to version 8.2 this was about to happen once again.


'''Install the Nextcloud app'''
To avoid this frequent hassle a new [https://archlinux.org/packages/?q=php-legacy set of php-legacy] packages has been [https://archlinux.org/news/php-82-update-and-introduction-of-legacy-branch/ introduced] by that time. These will follow the oldest but still [https://www.php.net/supported-versions.php actively supported PHP] branch. Package {{Pkg|nextcloud}} has been modified to depend on meta package ''php-interpreter'' which is provided by {{Pkg|php}} and {{Pkg|php-legacy}}. This way users of package {{Pkg|nextcloud}} have the choice to build their Nextcloud installation either on top of {{Pkg|php}} or on top of {{Pkg|php-legacy}}.


Go to the Apps section and choose “Office & Text”, install the “Collabora Online” app. In admin panel select Collabora Online tab and specific the server's domain you have setup before.
It is highly recommended to go for {{Pkg|php-legacy}}. With this only slightly aged version of PHP it will be very unlikely that a system upgrade renders an existing Nextcloud installation unusable.


==== Solution without Docker ====
{{Warning|Users choosing the latest and greatest version of PHP (i.e. {{Pkg|php}}) have to be prepared for troubles when package {{Pkg|php}} switches major or even minor versions. These troubles will mainly manifest in package {{Pkg|nextcloud}} suddenly not offering {{Pkg|php}} as dependency (because its version not being supported by Nextcloud at that point in time). This effectively will force users going for {{Pkg|php}} to occasionally migrate to {{Pkg|php-legacy}} temporarily, i.e. some time later they will have to migrate back to {{Pkg|php}}.}}


The {{AUR|collabora-online-server-nodocker}} package provides the Collabora Office (the desktop suite) and the “CODE” (Collabora Online Development Edition) server, which is based on “lool” (LibreOffice OnLine).
Migrating to {{Pkg|php-legacy}} requires some manual actions. Depending on your actual setup a subset of the following tasks must be applied:


Alter the {{ic|/etc/loolwsd/loolwsd.xml}} file, so that:
{{Note|The following list of actions assumes that your Nextcloud installation has been set up according to this wiki article. In case your setup deviates from this approach please be extra careful and adapt the steps appropriately.}}


* {{ic|config > server_name}} contains the host and port of the public Nextcloud address, separated by a colon (e.g. {{ic|example.org:443}}),
==== PHP extensions ====
* {{ic|config > ssl > enable}} is false (i.e. web browser —HTTPS→ proxy —HTTP→ loolwsd),
* {{ic|config > ssl > termination}} is true (I suppose you’ll manage TLS at the proxy level),
* {{ic|config > storage > wopi > host}} reflects the actual hostname (or pattern) of the proxy server (e.g. {{ic|(?:.*\.)?example\.org}}),
* {{ic|config > admin_console > username}} and {{ic|config > admin_console > password}} are set to values of your choice.


Then:
Replace {{Pkg|php}} extensions by their corresponding {{Pkg|php-legacy}} counterparts. For example


* [[start]] and [[enable]] {{ic|loolwsd.service}};
{{bc|
* configure Nginx by creating a [[Nginx#Server_blocks|server block]] including {{ic|/etc/nginx/snippets/loolwsd.conf}}, and restart it. Example with SSL (change {{ic|office.example.com}} and {{ic|ssl_certificate}} to the right values):
$ 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
}}


{{hc|/etc/nginx/conf.d/example.conf|<nowiki>
The former extension ''php-intl'' is an exception as it has become an integral part of {{Pkg|php}} and {{Pkg|php-legacy}}. So there is no need to explicitly take care of this package here.
server {
    listen 443 ssl;
    server_name office.example.com;


    ssl_certificate /etc/letsencrypt/live/office.example.com/fullchain.pem;
The actual set of PHP extensions is subject to the database, the in-memory object cache, the application server and other factors. Of course, in case another application depends on the most recent PHP version the non-legacy module may still be needed. Same applies for {{Pkg|php}} itself.
    ssl_certificate_key /etc/letsencrypt/live/office.example.com/privkey.pem;


    include snippets/loolwsd.conf;
==== Nextcloud specific copy of {{ic|php.ini}} ====
}
</nowiki>}}


* in Nextcloud, install the "Collabora Online" app. In the admin panel select the Collabora Online tab and specify the server domain name you have just set up.
{{hc|1=/etc/webapps/nextcloud/php.ini|2=
open_basedir=...:/usr/lib/php-legacy/modules:...
extension_dir = "/usr/lib/php-legacy/modules/"
;extension=imap                                            <= to be deleted
}}


=== Disabling app recommendations ===
==== FPM configuration ====


By default, nextcloud reccomends apps to new clients, which can result in a lot of notifications. To disable this, disable the recommendation app using {{ic|occ}}.
(This only applies if the application server ''FPM'' is used.)


== Troubleshooting ==
{{bc|
{{Out of date|A lot of references to OwnCloud, are these still valid with Nextcloud?}}
$ 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
}}


By default, the logs of the web application are available in {{ic|/var/log/nextcloud/nextcloud.log}}.
Modify {{ic|/etc/php-legacy/php-fpm.ini}}


=== Issues with permissions and setup after upgrade to >= 21.0.0 ===
{{hc|1=/etc/php-legacy/php-fpm.ini|2=
extension_dir = "/usr/lib/php-legacy/modules/"
;extension=imap                                            <= to be deleted
}}


{{Note| Before nextcloud 21.0.0, the web application was run using the {{ic|http}} user. This is a security concern in regards to cross-application access of this user (it has access to all data of all web applications).}}
Modify {{ic|/etc/php-legacy/php-fpm.d/nextcloud.conf}}


Since version 21.0.0 nextcloud more closely follows the [[web application package guidelines]]. This introduces the separate user {{ic|nextcloud}}, as which the web application is run.
{{hc|1=/etc/php-legacy/php-fpm.d/nextcloud.conf|2=
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              <= to be deleted
; php_value[extension] = imap                              <= to be deleted
}}


After an upgrade from nextcloud < 21.0.0 make sure that
Optional, but recommended: Make {{ic|www.conf}} a no-op while still being able to track modifications of this file that might come in with future updates of {{Pkg|php-legacy-fpm}}


* neither the [[Nextcloud#Data_directory| data directory]] nor the [[Nextcloud#Writable_apps_directory| writable apps directory]] is located below {{ic|/usr/share/webapps/nextcloud/}}, as that directory is owned by {{ic|root}}
{{bc|1=
* both the [[Nextcloud#Data_directory|data directory]] and the [[Nextcloud#Writable_apps_directory|writable apps directory]], alongside all files beneath them are writable and owned by the {{ic|nextcloud}} user
$ mv /etc/php-legacy/php-fpm.d/www.conf /etc/php-legacy/php-fpm.d/www.conf.package
* the web application configuration file resides in {{ic|/etc/webapps/nextcloud/config/}} and that that directory and its contents are writable and owned by the {{ic|nextcloud}} user
$ echo "; just a no-op" > /etc/php-legacy/php-fpm.d/www.conf
* an application server, such as {{pkg|php-fpm}} or [[uwsgi]] is configured to run the web application as the {{ic|nextcloud}} user and not the {{ic|http}} user
}}
* update the cron job/systemd timer to run with the new user


=== Environment variables not available ===
[[Stop]] and [[disable]] the systemd service ''php-fpm.service''. Create a [[drop-in file]] for ''php-fpm-legacy.service'':


Uncomment the line in {{ic|/etc/php/php-fpm.d/www.conf}} as per [https://docs.nextcloud.com/server/latest/admin_manual/installation/source_installation.html#php-fpm-tips-label Nextcloud documentation]:
{{hc|/etc/systemd/system/php-fpm-legacy.service.d/override.conf|2=
  env[PATH] = /usr/local/bin:/usr/bin:/bin
[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
}}


=== Self-signed certificate not accepted ===
[[Enable]] and [[start]] the systemd service ''php-fpm-legacy.service''.


ownCloud uses [[Wikipedia:cURL]] and [[Wikipedia:SabreDAV]] to check if WebDAV is enabled.
==== uWSGI configuration ====
If you use SSL/TLS with a self-signed certificate, e.g. as shown in [[LAMP]], and access ownCloud's admin panel, you will see the following error message:


Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken.
(This only applies if the application server ''uWSGI'' is used.)


Assuming that you followed the [[LAMP]] tutorial, execute the following steps:
{{hc|1=/etc/uwsgi/nextcloud.ini|2=
php-set = open_basedir=...:/usr/lib/php-legacy/modules...
# uncomment if php-imap is installed and used              <= to be deleted
# php-set = extension=imap                                  <= to be deleted
}}


Create a local directory for non-distribution certificates and copy [[LAMP]]s certificate there. This will prevent {{ic|ca-certificates}}-updates from overwriting it.
==== Nginx configuration ====


# cp /etc/httpd/conf/server.crt /usr/share/ca-certificates/''WWW.EXAMPLE.COM.crt''
Modify the file where the forwarding of certain requests to the application server is configured. In case of ''FPM'' e.g.


Add ''WWW.EXAMPLE.COM.crt'' to {{ic|/etc/ca-certificates.conf}}:
{{hc|1=''cloud.mysite.com''.conf|2=
        fastcgi_pass unix:/run/php-fpm-legacy/nextcloud.sock;
}}


''WWW.EXAMPLE.COM.crt''
In case of ''uWSGI'' no adaptation is required.


Now, regenerate your certificate store:
==== Apache HTTP server configuration ====


# update-ca-certificates
In case you use Apache's HTTP server and ''FPM'' as application server adapt this line in your configuration


Restart the httpd service to activate your certificate.
{{bc|1=
SetHandler "proxy:unix:/run/php-fpm-legacy/nextcloud.sock{{!}}fcgi://nextcloud/"
}}


=== Self-signed certificate for Android devices ===
In case of ''uWSGI'' no adaptation is required.


Once you have followed the setup for SSL, as on [[Apache HTTP Server#TLS]] for example, early versions of DAVdroid will
==== Background jobs ====
reject the connection because the certificate is not trusted. A certificate can be made as follows on your server:


# openssl x509 -req -days 365 -in /etc/httpd/conf/server.csr -signkey /etc/httpd/conf/server.key -extfile android.txt -out CA.crt
Update the [[drop-in file]] for Nextcloud's scheduled background job:
# openssl x509 -inform PEM -outform DER -in CA.crt -out CA.der.crt


The file {{ic|android.txt}} should contain the following:
{{hc|/etc/systemd/system/nextcloud-cron.service.d/override.conf|2=
[Service]
ExecStart=
ExecStart=/usr/bin/php-legacy -c /etc/webapps/nextcloud/php.ini -f /usr/share/webapps/nextcloud/cron.php
}}


basicConstraints=CA:true
==== Pacman hook ====


Then import {{ic|CA.der.crt}} to your Android device:
The pacman hook {{ic|/etc/pacman.d/hooks/10-nextcloud.hook}} needs to be adapted as well. Change the line starting with {{ic|Exec}} to:


Put the {{ic|CA.der.crt}} file onto the sdcard of your Android device (usually to the internal one, e.g. save from a mail attachment).
{{hc|1=/etc/pacman.d/hooks/10-nextcloud.hook|2=
It should be in the root directory. Go to ''Settings > Security > Credential storage'' and select ''Install from device storage''.
Exec = /usr/bin/runuser -u nextcloud -- /usr/bin/php-legacy --php-ini /etc/webapps/nextcloud/php.ini /usr/share/webapps/nextcloud/occ upgrade
The {{ic|.crt}} file will be detected and you will be prompted to enter a certificate name. After importing the certificate,
}}
you will find it in ''Settings > Security > Credential storage > Trusted credentials > User''.


Thanks to: [https://web.archive.org/web/20150323082541/http://www.leftbrainthings.com/2013/10/13/creating-and-importing-self-signed-certificate-to-android-device/]
Otherwise during the next upgrade of Nextcloud pacman will complain about {{ic|/usr/bin/php}} not being found.


Another way is to import the certificate directly from your server via [https://play.google.com/store/apps/details?id=at.bitfire.cadroid CAdroid]{{Dead link|2020|04|01|status=404}} and follow the instructions there.
==== Cleanup ====


=== Cannot write into config directory! ===
Do not forget to cleanup files and directories that may have become obsolete. Potential candidates are:


If you have set {{ic|open_basedir}} in your PHP/web server configuration file (e.g. {{ic|/etc/httpd/conf/extra/nextcloud.conf}}), make sure that it includes {{ic|/etc/webapps}}.
{{bc|
/usr/lib/php
/etc/php
}}


Restart the web server to apply the change.
=== Weird behavior of one or more apps ===


If you are getting this error after an upgrade from Nextcloud 17 to Nextcloud 18, also see [[#Explicitly permit Nextcloud directories for php-fpm]].
There are two locations where folders with files of Nextcloud's apps can be found:


=== Cannot create data directory ===
* {{ic|/usr/share/webapps/nextcloud/apps}} (aka read-only apps directory). This is where the {{Pkg|nextcloud}} package and the app packages (e.g. {{Pkg|nextcloud-app-contacts}}) put the folders with files comprising Nextcloud apps.


If you have set {{ic|open_basedir}} in your PHP/web server configuration file (e.g. {{ic|/etc/httpd/conf/extra/nextcloud.conf}}), make sure that it includes the data directory.
* {{ic|/var/lib/nextcloud/apps}} (aka writeable apps directory). This is where you find folders with files of apps installed via GUI or via the {{ic|occ app:install}} command.


Restart the web server to apply the change.
When files of an app can be found in both directories (especially in different versions) all kind of strange things can happen. In a concrete [https://github.com/nextcloud/contacts/issues/2867 case] the ''contacts'' app could be found in both the read-only apps directory and the writeable apps directory. As a result the page with contacts in the GUI did not display. It remained blank white. The browser's Javascript console showed an error message:


=== CSync failed to find a specific file. ===
{{bc|Uncaught Error: Could not find initial state contactsinteraction of contacts}}


This is most likely a certificate issue. Recreate it, and do not leave the common name empty or you will see the error again.
Check for apps to be found in both locations. To find out whether to delete the app folder in the read-only directory or in the writeable directory determine whether the app is part of a package. Run


# openssl req -new -x509 -nodes -newkey rsa:4096 -keyout server.key -out server.crt
{{bc|
# cd /usr/share/webapps/nextcloud/apps
# pacman -Qo * >/dev/null
}}


=== Seeing white page after login ===
All folders reported with


The cause is probably a new app that you installed. To fix that, you can use the occ command as described
{{bc|
[https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/occ_command.html here]. So with
error: No package owns ....
}}


sudo -u http php /usr/share/webapps/nextcloud/occ app:list
(and that can also be found in the writeable apps directory) can be safely deleted from {{ic|/usr/share/webapps/nextcloud/apps}}. Other double installed apps (i.e. those belonging to a package) should be removed from {{ic|/var/lib/nextcloud/apps}}.


you can list all apps (if you installed nextcloud in the standard directory), and with  
=== InnoDB refuses to write tables with ROW_FORMAT=COMPRESSED ===


sudo -u http php /usr/share/webapps/nextcloud/occ app:disable <nameOfExtension>
MariaDB versions >= 10.6 and < 10.6.6 were not compatible with Nextcloud as the database enforced [https://mariadb.com/kb/en/innodb-compressed-row-format/#read-only read-only for compressed InnoDB tables] and Nextcloud has been (and still is) using these kind of tables:


you can disable the troubling app.
:From MariaDB 10.6.0 until MariaDB 10.6.5, tables that are of the COMPRESSED row format are read-only by default. This was intended to be the first step towards removing write support and deprecating the feature.
:
:This plan has been scrapped, and from MariaDB 10.6.6, COMPRESSED tables are no longer read-only by default.


Alternatively, you can either use [[phpMyAdmin]] to edit the {{ic|oc_appconfig}} table (if you got lucky and the table has an edit option), or do it by hand with mysql:
Additionally the issue has already been [https://github.com/nextcloud/server/pull/30129 addressed] by Nextcloud. Starting with Nextcloud v24 new installations of Nextcloud do not use row format COMPRESSED anymore. It has to be noted that existing (pre v24) installations are not migrated away from row format COMPRESSED automatically.


mysql -u root -p owncloud
Bottom line: Probably you are not affected since Arch Linux has been shipping MariaDB v10.6.6 or later since 2022-02-10.
MariaDB [owncloud]> '''delete from''' oc_appconfig '''where''' appid='<nameOfExtension>' '''and''' configkey='enabled' '''and''' configvalue='yes';
MariaDB [owncloud]> '''insert into''' oc_appconfig (appid,configkey,configvalue) '''values''' ('<nameOfExtension>','enabled','no');


This should delete the relevant configuration from the table and add it again.
In the unlikely case that you are affected by this issue there are several possible remedies:


=== GUI sync client fails to connect ===
* Adapt your MariaDB configuration:


If using HTTP basic authentication, make sure to exclude "status.php", which must be publicly accessible. [https://github.com/owncloud/mirall/issues/734]
  {{hc|/etc/my.cnf.d/server.cnf|2=
  [mariadb-10.6]
  innodb_read_only_compressed=OFF
  }}


=== GUI tray icon disappears, but client still running in the background ===
* Migrate your MariaDB tables from row format COMPRESSED to DYNAMIC as suggested by [https://github.com/nextcloud/server/issues/25436#issuecomment-1016785831 some] [https://github.com/nextcloud/server/issues/25436#issuecomment-1017462542 comments] for the corresponding [https://github.com/nextcloud/server/issues/25436 Nextcloud issue]. Mind that as long as you stay with Nextcloud < v24 new tables will again use row format COMPRESSED - so will need to be migrated in the same way.


After waking up from a suspended state, the Nextcloud client tray icon may disappear from the system tray. A workaround is to delay the startup of the client, as noted [https://github.com/nextcloud/desktop/issues/203#issuecomment-463957811 here]. This can be done with the .desktop file, for example:
* Replace MariaDB by PostgreSQL and migrate the data of your Nextcloud instance with {{ic|occ db:convert-type}}. See Nextcloud's [https://docs.nextcloud.com/server/latest/admin_manual/configuration_database/db_conversion.html documentation] for details.


{{hc|.local/share/applications/nextcloud.desktop|<nowiki>
=== Issues with permissions and setup after upgrade to >= 21.0.0 ===
...
Exec=bash -c 'sleep 5 && nextcloud'
...
</nowiki>}}


=== Some files upload, but give an error 'Integrity constraint violation...' ===
{{Note| Before nextcloud 21.0.0, the web application was run using the {{ic|http}} user. This is a security concern in regards to cross-application access of this user (it has access to all data of all web applications).}}


You may see the following error in the ownCloud sync client:
Since version 21.0.0 nextcloud more closely follows the [[web application package guidelines]]. This introduces the separate user {{ic|nextcloud}}, as which the web application is run.


    SQLSTATE[23000]: Integrity constraint violation: ... Duplicate entry '...' for key 'fs_storage_path_hash')...
After an upgrade from nextcloud < 21.0.0 make sure that


This is caused by an issue with the File Locking app, which is often not sufficient to keep conflicts from occurring on some webserver configurations.
* the data directory is located at {{ic|/var/lib/nextcloud/data}}
A more complete [https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/files_locking_transactional.html Transactional File Locking]
* the writable apps directory is located at {{ic|/var/lib/nextcloud/apps}}
is available that rids these errors, but you must be using the Redis php-caching method. Install {{Pkg|redis}} and {{Pkg|php-redis}}, comment out
* both the data directory and the writable apps directory, alongside all files beneath them are writable and owned by the {{ic|nextcloud}} user
your current php-cache mechanism, and then in {{ic|/etc/php/conf.d/redis.ini}} uncomment {{ic|1=extension=redis}}.
* the web application configuration file resides in {{ic|/etc/webapps/nextcloud/config/}} and that that directory and its contents are writable and owned by the {{ic|nextcloud}} user
Then in {{ic|config.php}} make the following changes:
* an application server, such as [[#FPM|FPM]] or [[#uWSGI|uWSGI]] is configured to run the web application as the {{ic|nextcloud}} user and not the {{ic|http}} user
* update the cron job/systemd timer to run with the new user
* Finally allow read access to the nextcloud installation {{ic|/usr/share/webapps/nextcloud}} to your web-server user {{ic|http}} by doing:


    'memcache.local' => '\OC\Memcache\Redis',
{{bc|
    'filelocking.enabled' => 'true',
# chown -R nextcloud:http /usr/share/webapps/nextcloud
    'memcache.locking' => '\OC\Memcache\Redis',
}}
    'redis' => array(
        'host' => 'localhost',
        'port' => 6379,
        'timeout' => 0.0,
          ),


and [[start/enable]] {{ic|redis.service}}.
=== Login loop without any clue in access.log, error.log, nor nextcloud.log ===


Finally, disable the File Locking App, as the Transational File Locking will take care of it (and would conflict).
As mentioned in a [https://bbs.archlinux.org/viewtopic.php?pid=1967719#p1967719 post in the forum], this issue can be fixed by setting correct permissions on the ''sessions'' directory. (See [https://docs.nextcloud.com/server/stable/admin_manual/installation/nginx.html#login-loop-without-any-clue-in-access-log-error-log-nor-nextcloud-log Nextcloud's documentation] for details.) It is also possible that the ''sessions'' directory is missing altogether. The creation of this directory is documented in [[#System and environment|System and environment]].


If everything is working, you should see 'Transactional File Locking Enabled' under Server Status on the Admin page, and syncs should no longer cause issues.
{{ic|/var/lib/nextcloud}} should look like this:


=== "Cannot write into apps directory" ===
{{bc|
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/
}}


As mentioned in the [https://docs.nextcloud.com/server/latest/admin_manual/apps_management.html official admin manual],
=== Environment variables not available ===
either you need an apps directory that is writable by the http user, or you need to set {{ic|appstoreenabled}} to {{ic|false}}.


If you have set {{ic|open_basedir}} in your PHP/web server configuration file (e.g. {{ic|/etc/httpd/conf/extra/nextcloud.conf}}), it may be necessary to add your ''/path/to/data'' directory to the string on the line starting with {{ic|php_admin_value open_basedir }}:
Depending on what application server you use custom environment variables can be provided to Nextcloud's PHP code.


{{hc|/etc/httpd/conf/extra/nextcloud.conf|2=
==== FPM ====
 
  php_admin_value open_basedir "''/path/to/data/'':/srv/http/:/dev/urandom:/tmp/:/usr/share/pear/:/usr/share/webapps/nextcloud/:/etc/webapps/nextcloud"
}}


=== Installed apps get blocked because of MIME type error ===
Add one or more lines in {{ic|/etc/php-legacy/php-fpm.d/nextcloud.conf}} as per [https://docs.nextcloud.com/server/latest/admin_manual/installation/source_installation.html#php-fpm-tips-label Nextcloud's documentation], e.g.:


If you are putting your apps folder outside of the nextcloud installation directory make sure your webserver serves it properly.
{{hc|1=/etc/php-legacy/php-fpm.d/nextcloud.conf|2=
env[PATH] = /usr/local/bin:/usr/bin:/bin
}}


In nginx this is accomplished by adding a location block to the nginx configuration as the folder will not be included in it by default.
==== uWSGI ====


location ~ /apps2/(.*)$ {
Add one or more lines in {{ic|/etc/uwsgi/nextcloud.ini}}, e.g.:
    alias /var/www/nextcloud/apps/$1;
}


=== CSS and JS resources blocked due to MIME type error ===
{{hc|1=/etc/uwsgi/nextcloud.ini|2=
env = PATH=/usr/local/bin:/usr/bin:/bin
}}


If you load your Nextcloud web gui and it's missing styles etc. check the browser's console logs for lines like:
Mind there must not be any blanks around the second {{ic|1==}}.


<nowiki>The resource from “https://example.com/core/css/guest.css?v=72c34c37-0” was blocked due to MIME type (“text/plain”) mismatch (X-Content-Type-Options: nosniff).</nowiki>
=== You are accessing your instance over a secure connection, however your instance is generating insecure URLs ===


There are a few possible reasons, possibly you have [https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html#javascript-js-or-css-css-files-not-served-properly not included any mime types] in your {{ic|nginx.conf}} add the following to {{ic|nginx.conf}}
If you get the following message in your administration settings:


types_hash_max_size 2048;
: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.
types_hash_bucket_size 128;
include mime.types;


Here we use the {{ic|mime.types}} provided by {{Pkg|mailcap}}, due to the large number of types included we increase the allowed size of the types hash.
Add the following in your configuration file: [https://help.nextcloud.com/t/instance-over-a-secure-connection-however-your-instance-is-generating-insecure-urls/134108]


Other possible reasons for these errors are missing permissions on the files. Make sure the files are owned by {{ic|http:http}} and can be read and written to by this user.
{{hc|/etc/webapps/nextcloud/config/config.php|2=
'trusted_proxies' => ['192.168.1.0'],
'overwriteprotocol' => 'https',
}}


=== Security warnings even though the recommended settings have been included in nginx.conf ===
Replace {{ic|192.168.1.0}} with your public IP.


At the top of the admin page there might be a warning to set the {{ic|Strict-Transport-Security}}, {{ic|X-Content-Type-Options}},
=== Nextcloud reports corrupted index (MariaDB) ===
{{ic|X-Frame-Options}}, {{ic|X-XSS-Protection}} and {{ic|X-Robots-Tag}} according to https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/harden_server.html{{Dead link|2020|04|01|status=404}}
even though they are already set like that.


A possible cause could be that because owncloud sets those settings, uwsgi passed them along and nginx added them again:
If Nextcloud reports corrupted indices (e.g. during {{ic|occ db:}} commands or in ''Administration > Logging'') you can repair your database by executing:


{{hc|$ curl -I https://domain.tld|<nowiki>
{{bc|
...
$ mysqlcheck --check --auto-repair nextcloud -u nextcloud -p
X-XSS-Protection: 1; mode=block
}}
X-Content-Type-Options: nosniff
X-Frame-Options: Sameorigin
X-Robots-Tag: none
Strict-Transport-Security: max-age=15768000; includeSubDomains; preload;
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Robots-Tag: none
</nowiki>}}


While the fast_cgi sample config has a parameter to avoid that ( {{ic|fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice}} ), when using uwsgi and nginx the following modification of the uwsgi part in nginx.conf could help:
If the command fails, it still will point out the table {{ic|TABLE}} containing a corrupted index. Repair it by logging into mariadb:


{{hc| /etc/nginx/nginx.conf|<nowiki>
{{bc|
...
$ mysql -u nextcloud -p
        # pass all .php or .php/path urls to uWSGI
mysql> use nextcloud;
        location ~ ^(.+\.php)(.*)$ {
mysql> check table ''TABLE'';
            include uwsgi_params;
mysql> optimize table ''TABLE'';
            uwsgi_modifier1 14;
mysql> exit;
            # hode following headers received from uwsgi, because otherwise we would send them twice since we already add them in nginx itself
}}
            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-Frame-Options;
            #Uncomment line below if you get connection refused error. Remember to commet out line with "uwsgi_pass 127.0.0.1:3001;" below
            uwsgi_pass unix:/run/uwsgi/owncloud.sock;
            #uwsgi_pass 127.0.0.1:3001;
        }
...
</nowiki>}}


=== "Reading from keychain failed with error: 'No keychain service available'" ===
Replace {{ic|''TABLE''}} to match your findings.


Can be fixed for Gnome by installing the following 2 packages, {{Pkg|libgnome-keyring}} and {{Pkg|gnome-keyring}}.
=== Failed to fetch the Collabora capabilities endpoint ===
Or the following for KDE, {{Pkg|libgnome-keyring}} and {{Pkg|qtkeychain}}{{Broken package link|replaced by {{Pkg|qtkeychain-qt5}}}}.


=== FolderSync: "Method Not Allowed" ===
In case you get responses with:  


FolderSync needs access to {{ic|/owncloud/remote.php/webdav}}, so you could create another alias for owncloud in your  {{ic|/etc/httpd/conf/extra/nextcloud.conf}}
: Failed to fetch the Collabora capabilities endpoint: Client error: `GET <nowiki>http://localhost/wapps/richdocumentscode/proxy.php?req=/hosting/capabilities</nowiki>` resulted in a `404 Not Found` response


  <IfModule mod_alias.c>
double-check your {{ic|config.php}} that entry {{ic|overwrite.cli.url}} has been set as described in section [[#Nextcloud|Configuration / Nextcloud]].
    Alias /nextcloud /usr/share/webapps/nextcloud/
    Alias /owncloud /usr/share/webapps/nextcloud/
  </IfModule>


== See also ==
== See also ==

Latest revision as of 17:35, 25 April 2024

Related articles

Nextcloud is a suite of client-server-software that (by means of so-called apps) allows all kinds of sharing, collaboration and communication, e.g.:

Nextcloud is open source and based on open standards. Data sovereignty is a big plus, i.e. with your own instance of Nextcloud, you break free from proprietary (and potentially untrustworthy) services like Dropbox, Office 365, or Google Drive.

Depending on your needs Nextcloud can be deployed from single-board computers (like e.g. a Raspberry Pi) all the way up to full scale data centers serving millions of users. With an elaborated authorization scheme and the option for federation (connecting discrete instances) Nextcloud is well suited for use in enterprise environments.

Nextcloud is a fork of ownCloud. See Wikipedia for the history.

Setup overview

A complete installation of Nextcloud comprises (at least) the following components:

A web server paired with an application server on which runs Nextcloud (i.e. the PHP code) using a database.

This article will cover MariaDB/MySQL and PostgreSQL as databases and the following combinations of web server and application server:

  • nginx → uWSGI (plus uwsgi-plugin-php)
  • nginx → FPM,
  • Apache HTTP server (using mod_proxy_uwsgi) → uWSGI (plus uwsgi-plugin-php)
  • Apache HTTP server (using mod_proxy_fcgi) → FPM

The Nextcloud package complies with the web application package guidelines. Among other things this mandates that the web application be run with a dedicated user - in this case nextcloud. This is one of the reasons why the application server comes into play here. For the very same reason it is not possible anymore to execute Nextcloud's PHP code directly in the Apache process by means of php-apache.

Installation

Note: The package nextcloud (by means of a dependency on meta package php-interpreter) offers the choice to build an installation of Nextcloud on top of either php or on top of package php-legacy. It is highly recommended to choose php-legacy to be on the safe side (and for your peace of mind). See Migrating to php-legacy for details. For the remainder of this article we assume an installation using php-legacy.

Install the nextcloud package. When asked choose php-legacy as your PHP version. This will pull in quite a few dependent packages. All required PHP extensions will be taken care of this way.

It is recommended to additionally install the packages php-legacy-sodium for the argon2 hashing algorithm and php-legacy-imagick and librsvg for preview generation (preferrably as dependent package with pacman option --asdeps). Other optional dependencies will be covered later depending on your concrete setup (e.g. which database you choose).

Configuration

PHP

This guide does not tamper with PHP's central configuration file /etc/php-legacy/php.ini but instead puts Nextcloud specific PHP configuration in places where it does not potentially interfere with settings for other PHP based applications. These places are:

  • A dedicated copy of php.ini in /etc/webapps/nextcloud (for the occ command line tool and the background job). This is literally a copy of the original php.ini as provided by the php-legacy package with some Nextcloud specific additions / modifications.
  • Corresponding settings in the configuration of the application server. These will be covered in the section about application servers.

Make a copy of /etc/php-legacy/php.ini to /etc/webapps/nextcloud. Although not strictly necessary, change ownership of the copy: 

# cp /etc/php-legacy/php.ini /etc/webapps/nextcloud
# chown nextcloud:nextcloud /etc/webapps/nextcloud/php.ini

Most of the prerequisites listed in Nextcloud's installation instructions are already enabled in the just copied bare PHP installation config file. Additionally enable the following extensions: 

/etc/webapps/nextcloud/php.ini
extension=bcmath
extension=bz2
extension=exif
extension=gd
extension=iconv
extension=intl
# sodium for the argon2 hashing algorithm
extension=sodium
extension=sysvsem
; in case you installed php-legacy-imagick (as recommended)
extension=imagick

Set date.timezone to your preferred timezone, e.g.: 

/etc/webapps/nextcloud/php.ini
date.timezone = Europe/Berlin

Raise PHP's memory limit to at least 512MiB: 

/etc/webapps/nextcloud/php.ini
memory_limit = 512M

Optional: For additional security configure open_basedir. This limits the locations where Nextcloud's PHP code can read and write files. Proven settings are 

/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

Depending on which additional extensions you configure you may need to extend this list, e.g. /run/redis in case you opt for Redis.

It is not necessary to configure opcache here as this php.ini is only used by the occ command line tool and the background job, i.e. by short running PHP processes.

Nextcloud

Add the following entries to Nextcloud's configuration file: 

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

Adapt the given example hostname cloud.mysite.com. In case your Nextcloud installation will be reachable via a subfolder (e.g. https://www.mysite.com/nextcloud) overwrite.cli.url and htaccess.RewriteBase have to be modified accordingly.

System and environment

To make sure the Nextcloud specific php.ini is used by the occ tool set the environment variable NEXTCLOUD_PHP_CONFIG: 

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

Also add this line to your .bashrc (or .bash_profile ) to make this setting permanent.

As a privacy and security precaution create the dedicated directory for session data: 

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

Database

MariaDB/MySQL is the canonical choice for Nextcloud.

The MySQL or MariaDB databases are the recommended database engines.[1]

Most information concerning databases with Nextcloud deals with MariaDB/MySQL. The Nextcloud developers admit to have less detailed expertise with other databases.

PostgreSQL is said to deliver better performance and overall has fewer quirks compared to MariaDB/MySQL. SQLite is mainly supported for test / development installations and not recommended for production. The list of supported databases also contains Oracle database. This product will not be covered here.

MariaDB / MySQL

Since MariaDB has been the default MySQL implementation in Arch Linux since 2013[2] this text only mentions MariaDB.

In case you want to run your database on the same host as Nextcloud install, configure and start mariadb (if you have not done so already). See the corresponding article for details. Do not forget to initialize MariaDB with mariadb-install-db. It is recommended for additional security to configure MariaDB to only listen on a local Unix socket: 

/etc/my.cnf.d/server.cnf
[mysqld]
skip_networking

Nextcloud's own documentation recommends to set the transaction isolation level to READ-COMMITTED. This is especially important when you expect high load with many concurrent transactions. 

/etc/my.cnf.d/server.cnf
[mysqld]
transaction_isolation=READ-COMMITTED

The other recommendation to set binlog_format=ROW is obsolete. The default MIXED in recent MariaDB versions is at least as good as the recommended ROW. In any case the setting is only relevant when replication is applied.

Start the CLI tool mysql with database user root. (Default password is empty, but hopefully you change it as soon as possible.) 

$ mysql -u root -p

Create the user and database for Nextcloud with 

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 is a placeholder for the actual password of DB user nextcloud you must choose.) Quit the tool with \q.

Note: MariaDB has a flawed understanding of what UTF8 means resulting in the inability to store any characters with codepoints 0x10000 and above (e.g. emojis). They 'fixed' this issue with version 5.5 by introducing a new encoding called utf8mb4. Bottom line: Never ever use MariaDB's utf8, always use utf8mb4. In case you need to migrate see [3].

So that you have decided to use MariaDB as the database of your Nextcloud installation you have to enable the corresponding PHP extension: 

/etc/webapps/nextcloud/php.ini
extension=pdo_mysql

Further configuration (related to MariaDB) is not required (contrary to the information given in Nextcloud's admin manual).

Now setup Nextcloud's database schema with: 

$ 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

Mind the placeholders (e.g. db-password) and replace them with appropriate values. This command assumes that you run your database on the same host as Nextcloud. Enter occ help maintenance:install and see Nextcloud's documentation for other options. See Using the "occ" command line tool for Arch-specific details about this tool.

PostgreSQL

Consult the corresponding article for detailed information about PostgreSQL. In case you want to run your database on the same host as Nextcloud install, configure and start postgresql (if you have not done so already). For additional security in this scenario it is recommended to configure PostgreSQL to only listen on a local UNIX socket: 

/var/lib/postgres/data/postgresql.conf
listen_addresses = ''

Especially do not forget to initialize your database with initdb. After having done so start PostgreSQL's CLI tool psql and create the database user nextcloud and the database of the same name 

[postgres]$ psql
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 is a placeholder for the password of database user nextcloud that you have to choose.)

Install the additional package php-legacy-pgsql as dependency (pacman option --asdeps) and enable the corresponding PHP extension in /etc/webapps/nextcloud/php.ini: 

/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

Mind the placeholders (e.g. db-password) and replace them with appropriate values. This command assumes that you run your database on the same host as Nextcloud. Enter occ help maintenance:install and see Nextcloud's documentation for other options. See Using the "occ" command line tool for Arch-specific details about this tool.

Application server

There are two prevalent application servers that can be used to process PHP code: uWSGI or FPM. FPM is specialized on PHP. The protocol used between the web server and FPM is fastcgi. The tool's documentation leaves room for improvement. uWSGI on the other hand can serve code written in a handful of languages by means of language specific plugins. The protocol used is uwsgi (lowercase). The tool is extensively documented - albeit the sheer amount of documentation can become confusing and unwieldy.

uWSGI

uWSGI has its own article. A lot of useful information can be found there. Install uwsgi and the plugin uwsgi-plugin-php-legacy - preferrably as dependencies, i.e. with --asdeps. To run Nextcloud's code with (or in) uWSGI you have to configure one uWSGI specific configuration file (nextcloud.ini) and define one systemd service.

Warning: It has to be mentioned that maintenance of uWSGI and especially of its PHP plugin has been sparse lately[4]. This has already caused issues that could only be solved by patching uWSGI code by the maintainers of Arch Linux packages, i.e. not upstream.

nextcloud.ini

The nextcloud package includes a sample configuration file already in the right place /etc/uwsgi/nextcloud.ini. In almost any case you will have to adapt this file to your requirements and setup. Find a version with lots of commented changes (compared to the package's version). It assumes a no-frills Nextcloud installation for private use (i.e. with moderate load).

In general keep the enabled extensions, extension specific settings and open_basedir in sync with /etc/webapps/nextcloud/php.ini (with the exception of opcache).

Tip: The changes to /etc/uwsgi/nextcloud.ini can become extensive. A file named nextcloud.ini.pacnew will be created during package update in case there are changes in the original file provided by the package nextcloud. In order to better track changes in this latter file and apply them to /etc/uwsgi/nextcloud.ini the following approach can be applied:
  • Make a copy of the file as provided by the package (e.g. by extracting from the package) and store it as nextcloud.ini.package.
  • In case an update of package nextcloud produces a nextcloud.ini.pacnew you can identify the changes with diff nextcloud.ini.package nextcloud.ini.pacnew.
  • Selectively apply the changes to your nextcloud.ini depending on whether they make sense with your version or not.
  • Move nextcloud.ini.pacnew over nextcloud.ini.package.

uWSGI service

The package uwsgi provides a template unit file (uwsgi@.service). The instance ID (here nextcloud) is used to pick up the right configuration file. Enable and start uwsgi@nextcloud.service.

In case you have more than a few (e.g. 2) services started like this and get the impression this is a waste of resource you might consider using emperor mode.

FPM

In case you opt to use FPM as your application server install php-legacy-fpm - preferrably as a dependent package (--asdeps).

Configuration consists of a copy of php.ini relevant for all applications served by FPM and a so-called pool file specific for the application (here Nextcloud). Finally you have to tweak the systemd service file.

php-fpm.ini

As stated earlier this article avoids modifications of PHP's central configuration in /etc/php-legacy/php.ini. Instead create a FPM specific copy. 

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

Make sure it is owned and only writeable by root (-rw-r--r-- 1 root root ... php-fpm.ini). Enable the op-cache, i.e. uncomment the line 

/etc/php-legacy/php-fpm.ini
;zend_extension=opcache

and put the following parameters below the existing line [opcache]: 

/etc/php-legacy/php-fpm.ini
opcache.enable = 1
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 10000
opcache.memory_consumption = 128
opcache.save_comments = 1
opcache.revalidate_freq = 1
Warning: Do not try to put these settings in the pool file by means of php_value[...] and php_flag[...]. Your FPM processes will consistently crash with the very first request.

nextcloud.conf

Next you have to create a so called pool file for FPM. It is responsible for spawning dedicated FPM processes for the Nextcloud application. Create a file /etc/php-legacy/php-fpm.d/nextcloud.conf - you may use this functional version as a starting point.

Again make sure this pool file is owned and only writeable by root (i.e. -rw-r--r-- 1 root root ... nextcloud.conf). Depending on whether access log is configured (it is with above sample nextcloud.conf) you may need to create the corresponding directory (here /var/log/php-fpm-legacy/access). Adapt or add settings (especially pm..., php_value[...] and php_flag[...]) to your liking. The settings php_value[...] and php_flag[..] must be consistent with the corresponding settings in /etc/webapps/nextcloud/php.ini (but not /etc/php-legacy/php-fpm.ini).

The settings done by means of php_value[...] and php_flag[...] could instead be specified in php-fpm.ini. But mind that settings in php-fpm.ini apply for all applications served by FPM.

Tip: The package php-legacy-fpm comes with its own pool file www.conf that is of little use here. A good approach to get rid of it is to rename it to www.conf.package and create a file www.conf with only comment lines (lines starting with a semicolon). This way www.conf becomes a no-op. It is also not overwritten during installation of a new version of php-legacy-fpm. Instead a file www.conf.pacnew is created. You can compare this against www.conf.package to see if anything significant has changed in the pool file that you may have to reproduce in nextcloud.conf. Do not forget to rename www.conf.pacnew to www.conf.package at the end of this procedure.

Systemd service

FPM is run as a systemd service. You have to modify the service configuration to be able to run Nextcloud. This is best achieved by means of a drop-in file: 

/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
  • It replaces the ExecStart line by a start command that uses the php-fpm.ini covered in the previous section.
  • The directories /var/lib/nextcloud and /etc/webapps/nextcloud/config (and everything below) are made writable. The ProtectSystem=full in the original service definition causes /usr, /boot and /etc to be mounted read-only for the FPM processes.

Do not forget to enable and start the service php-fpm-legacy.

Keep /etc tidy

The Nextcloud package unconditionally creates the uWSGI configuration file /etc/uwsgi/nextcloud.ini. Of course it is of no use when you run FPM instead of uWSGI (and it does no harm whatsoever). In case you nevertheless want to get rid of it just add the following lines to /etc/pacman.conf 

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

Web server

There is an abundance of web servers you can choose from. Whatever option you finally pick you have to keep in mind that the Nextcloud application needs to be run with its own system user nextcloud. So you will need to forward your requests to one of the above mentioned application servers.

nginx

Configuration of nginx is way beyond the scope of this article. See the relevant article for further information. Also consult Nextcloud's documentation for an elaborated configuration. It is up to you how to include this snippet into your nginx' configuration. One common approach is to use directories /etc/nginx/sites-available and /etc/nginx/sites-enabled to separate configurations for various servers (aka virtual hosts). See Nginx#Managing server entries for details.

If using the example nginx config from the Nextcloud documentation linked above, the root directory should be changed to: 

cloud.mysite.com.conf
  root /usr/share/webapps/nextcloud;

The usage of the block upstream php-handler { ... } is not necessary. Just specify fastcgi_pass unix:/run/php-fpm-legacy/nextcloud.sock; in the location block that deals with forwarding request with PHP URIs to the application server. When using uWSGI instead of FPM replace this location block with: 

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;
}

Things you might have to adapt (not exhaustive):

  • Your server name (server_name clauses 2x), i.e. the server part of the URL your Nextcloud installation will be reachable with.
  • The name of the certificate and key you use for SSL / TLS.
  • If and where you want an access log written to.
  • The location where Certbot (or any other ACME client) will put the domain verification challenges. Usage of alias instead of try_files is probably more adequate here.
  • The path used to reach your Nextcloud installation. (The part right to the server name & port section in the URL.)
  • What application server (uWSGI or FPM) you are using, i.e. how and where nginx will pass requests that need to trigger some PHP code. (See above.)
  • Configure OCSP stapling.

There is no need to install any additional modules since nginx natively supports both protocols FastCGI and uwsgi.

Apache HTTP server

Find lots of useful information in the article about the Apache HTTP Server. Nextcloud's documentation has some sample configuration that can also be found in /usr/share/doc/nextcloud/apache.example.conf. Both implicitly rely on mod_php that cannot be used anymore. mod_proxy_fcgi or mod_proxy_uwsgi need to be applied.

Information about how to integrate Apache with FPM can be found here in this wiki. uWSGI's documentation has some information about how to integrate Apache with PHP by means of uWSGI and mod_proxy_uwsgi. Mind that the Apache package comes with both modules mod_proxy_fcgi and mod_proxy_uwsgi. They need to be loaded as required.

The following Apache modules are required to run Nextcloud: 

/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 explicitly
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

Also uncomment the following directive to pull in TLS configuration parameters: 

/etc/httpd/conf/httpd.conf
Include conf/extra/httpd-ssl.conf

Consult Mozilla's SSL configurator for details about how to optimize your TLS configuration.

Refer to the following two sample configuration files depending on how you want to access your Nextcloud installation:

  • In case your Nextcloud installation is accessed via a dedicated host name (e.g. https://cloud.mysite.com/) put this fragment into /etc/httpd/conf/extra/httpd-vhosts.conf.
  • In case your Nextcloud installation is located in a subfolder of your web site (e.g. https://www.mysite.com/nextcloud/) put this fragment in your /etc/httpd/conf/httpd.conf.

Of course you must adapt these sample configuration files to your concrete setup. Replace the SetHandler directive by SetHandler "proxy:unix:/run/uwsgi/nextcloud.sock|uwsgi://nextcloud/" when you use uWSGI.

The Nextcloud package comes with a .htaccess that already takes care of a lot of rewriting and header stuff. Run occ maintenance:update:htaccess to adapt this file. Parameter htaccess.RewriteBase in /etc/webapps/nextcloud/config/config.php is vital for this.

Background jobs

Nextcloud requires certain tasks to be run on a scheduled basis. See Nextcloud's documentation for some details. The easiest (and most reliable) way to set up these background jobs is to use the systemd service and timer units that are already installed by nextcloud. The service unit needs some tweaking so that the job uses the correct PHP ini-file (and not the global php.ini). Create a drop-in file and add: 

/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

After that enable and start nextcloud-cron.timer (not the service).

As recommended by the documentation add the parameter 

/etc/webapps/nextcloud/config/config.php
....
'maintenance_window_start' => 0,
....

to Nextcloud's configuration file. The value is the hour of the day in UTC defining the start of a 4 hours window. Time consuming jobs that need to be run only once a day will be scheduled in this time frame, i.e. outside working hours.

Warning: Do not try to install and use nextcloud-systemd-timersAUR. It is outdated and unmaintained.

In-memory caching

Nextcloud's documentation recommends to apply some kind of in-memory object cache to significantly improve performance.

Note: Mind that push notify (the Nextcloud service that replaces client polling by notification by the server thus drastically reducing sync latency) depends on Redis.

APCu

Install php-legacy-apcu (as dependency --asdeps). Enable the extension in the relevant configuration files. These are

  • /etc/webapps/nextcloud/php.ini used by the occ command and the background jobs and
  • depending on the application server you use either
    • /etc/uwsgi/nextcloud.ini in case of uWSGI or
    • /etc/php-legacy/php-fpm.d/nextcloud.conf in case of FPM.

In /etc/webapps/nextcloud/php.ini add the lines 

/etc/webapps/nextcloud/php.ini
extension=apcu
apc.ttl=7200
apc.enable_cli = 1

(preferably somewhere below Module Settings).

For the other two files the setting to activate APCu is already in place and only needs to be uncommented. Two other configuration parameters related to APCu are also already there. No need to touch /etc/php-legacy/php.ini or /etc/php-legacy/conf.d/apcu.ini.

Restart your application server (not the web server as Nextcloud's documentation claims). Add the following line to your Nextcloud configuration file: 

/etc/webapps/nextcloud/config/config.php
'memcache.local' => '\OC\Memcache\APCu',

Redis

Install php-legacy-igbinary and php-legacy-redis (as dependency --asdeps) in case you run this component locally (i.e. on the same host as Nextcloud). Alternatively the Redis server can be run on a different machine. For more information see Nextcloud's documentation.

Note: Using Redis does not exclude using APCu in parallel as a local cache. In fact, Nextcloud's documentation recommends this setup.

Enable the required extensions igbinary and redis in the relevant configuration files. These are:

  • /etc/webapps/nextcloud/php.ini used by the occ command and the background jobs and
  • depending on the application server you use either
    • /etc/uwsgi/nextcloud.ini in case of uWSGI or
    • /etc/php-legacy/php-fpm.d/nextcloud.conf in case of FPM.

Locate the existing sections where other extensions are enabled and add two additional lines corresponding to igbinary and redis.

Note: It is important to load extension=igbinary before extension=redis. Otherwise occ will report an error (/usr/lib/php-legacy/modules/redis.so: undefined symbol: igbinary_serialize).

In case you have specified the open_basedir option in the above configuration files and use Redis locally with a local Unix socket, you have to extend the list of directories where PHP is allowed to read and write files. Locate the relevant lines in the files specified above and add the directory containing the local Unix socket created by Redis, e.g. /run/redis.

Note: The sample configuration files nextcloud.ini and nextcloud.conf mentionend in the #Application server section already have open_basedir enabled. So in case you use a copy of one of these files you have to adapt it.

Extend your Nextcloud configuration as follows: 

/etc/webapps/nextcloud/config/config.php
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
     'host'     => '/run/redis/redis.sock',
     'port'     => 0,
     'dbindex'  => 0,
     'password' => '',
     'timeout'  => 1.5,
],

Again, adapt /run/redis/redis.sock as required. dbindex, password and timeout are optional.

In case Redis runs on a different machine: 

/etc/webapps/nextcloud/config/config.php
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
     'host' => 'redis-host.mysite.com',
     'port' => 6379,
],

redis-host.mysite.com is just a placeholder. Adapt to your actual setup.

Security Hardening

See the Nextcloud documentation and Security. Nextcloud additionally provides a Security scanner.

Synchronization

Tip: It is recommended not to use your personal password but so-called app tokens for all software automatically authenticating against your Nextcloud server. This way in case you suspect credentials in one of the programs may have leaked you just need to revoke this one affected app token - instead of having to change your personal password and propagating this change to all places where it has been stored. You can generate a new app token in Nextcloud's web GUI in Settings > Security in the Devices & Sessions section.

Desktop

The official client can be installed with the nextcloud-client package. Alternative versions are available in the AUR: nextcloud-client-gitAUR. Please keep in mind that using owncloud-client with Nextcloud is not supported.

The desktop client basically syncs one or more directories of your desktop computer with corresponding folders in your Nextcloud's file service. It integrates nicely with your desktop's file manager (Dolphin in KDE Plasma, Nautilus in Gnome) displaying overlays representing synchronization and share status. The context menu of each file gets an additional entry Nextcloud to manage sharing of this file and getting the public or internal share link. Nextcloud's documentation has a volume exclusively about the desktop client.

In case the integration does not work as described consult the optional dependencies of package nextcloud-client (pacman -Qi nextcloud-client). E.g. Nautilus (Gnome) requires python-nautilus. Install as dependent package with pacman -S --asdeps).

Note: The desktop client provides a system tray icon that indicates sync status[5], but GNOME does not provide a system tray icon API out-of-the-box[6]. If this is a desired feature, one possible solution is to install and enable gnome-shell-extension-appindicator. See GNOME#Extensions for more info.

Thunderbird

Since version 102 Thunderbird fully supports CalDAV and CardDAV - even with auto detection (i.e. you do not have to provide long URLs to access your calendars and address books). See Nextcloud's documentation for details.

Mounting files with davfs2

If you want to mount your Nextcloud using WebDAV, install davfs2AUR (as described in davfs2).

To mount your Nextcloud, use: 

# mount -t davfs https://cloud.mysite.com/remote.php/dav/files/username/ /path/to/mount

You can also create an entry for this in /etc/fstab: 

/etc/fstab
https://cloud.mysite.com/remote.php/dav/files/username/ /path/to/mount davfs rw,user,noauto 0 0
Tip: In order to allow automount you can also store your username (and password if you like) in a file as described in davfs2#Storing credentials.
Note: If creating/copying files is not possible, while the same operations work on directories, see davfs2#Creating/copying files not possible and/or freezes.

Mounting files in GNOME Files (Nautilus)

You can access the files directly in Nautilus ('+ Other Locations') via the WebDAV protocol. Use the link as shown in your Nextcloud installation Web GUI (e.g. https://cloud.mysite.com/remote.php/webdav/) but replace the protocol name https by davs. Nautilus will ask for user name and password when trying to connect.

Android

Download the official Nextcloud app from Google Play or F-Droid.

To enable contacts and calendar sync (Android 4+):

  1. Download DAVx5 (Play Store, F-Droid).
  2. Create a new DAVdroid account in the Account settings and specify your server URL (e.g. https://cloud.mysite.com) and login / password pair.
Note: There is no need for the /remote.php/{carddav,webdav} part if you configured your web server with the proper redirections, as illustrated in the above section Web server. DAVdroid will find itself the right URLs.

iOS

Download the official Nextcloud app from the App Store.

Tips and tricks

Using the "occ" command line tool

A useful tool for server administration is occ. Refer to Nextcloud's documentation for details. You can perform many common server operations with occ, such as managing users and configuring apps.

A convenience wrapper around the original /usr/share/webapps/nextcloud/occ is provided with /usr/bin/occ which automatically runs as the default user (nextcloud), using the default PHP executable and PHP configuration file. The environment variables NEXTCLOUD_USER, NEXTCLOUD_PHP and NEXTCLOUD_PHP_CONFIG can be used to specify a non-default user, PHP executable and PHP configuration file (respectively). Especially the latter (using NEXTCLOUD_PHP_CONFIG) is necessary when Nextcloud was setup in a way as described in the sections Configuration and Application server, i.e. using a PHP configuration specific to Nextcloud. In this case put export NEXTCLOUD_PHP_CONFIG=/etc/webapps/nextcloud/php.ini in your .bashrc.

When using package php instead of the recommended package php-legacy you also have to set NEXTCLOUD_PHP, i.e. export NEXTCLOUD_PHP=/usr/bin/php.

Warning: When using php-legacy-apcu for caching, make sure to set apc.enable_cli=1 in /etc/webapps/nextcloud/php.ini. Otherwise the occ command will complain about APCu not being configured properly.

Pacman hook

The nextcloud package comes with a pacman hook that takes care of automatically upgrading the Nextcloud database after the package has been updated. Take a look /usr/share/doc/nextcloud/nextcloud.hook.

Unfortunately, this hook unconditionally uses the global php.ini when running occ upgrade, i.e. it does not take into account the value of environment variable NEXTCLOUD_PHP_CONFIG as mentioned above in Using the "occ" command line tool.

As a possible workaround make a copy of the delivered hook file in the appropriate location: 

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

and change the line starting with Exec to: 

/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

Running Nextcloud in a subdirectory

The instructions in section Web server will result in a setup where your Nextcloud installation is reachable via a dedicated server name, e.g. cloud.mysite.com. If you would like to have Nextcloud located in a subdirectory. e.g. www.mysite.com/nextcloud, then:

  • For nginx refer to the section in Nextcloud's documentation that explicitly covers this topic.
  • For apache edit the /etc/httpd/conf/extra/nextcloud.conf you included and comment out the <VirtualHost *:80> ... </VirtualHost> part of the include file.
Note: Do not forget to configure the .well-known URLs for service discovery. For more information please see Service discovery in Nextcloud's documentation.

Docker

See the Nextcloud repository on Docker Hub for running Nextcloud in Docker.

Office integration

There are currently three different solutions for office integration:

All three have in common that a dedicated server is required and your web server needs to be adapted to forward certain requests to the office service. The actual integration with Nextcloud is then accomplished by means of a Nextcloud app specific for one of the above products.

Mind that all three products are aimed at businesses, i.e. you will have to pay for the office service. Only Collabora offers a developers plan (CODE) for free. ONLYOFFICE offers a Home Server plan for a reasonable price.

For installation, setup instructions and integration with Nextcloud consult:

Disabling app recommendations

By default, Nextcloud recommends apps to new clients, which can result in a lot of notifications. To disable this, disable the recommendations app using occ app:disable recommendations.

Backup calendars and address books with calcardbackup

The calcardbackupAUR package can be installed and configured to provide regular backups of the calendar and/or address book databases. Edit /etc/calcardbackup/calcardbackup.conf to your liking and then start and enable calcardbackup.timer.

Troubleshooting

Reading the log

By default, the logs of the web application are available in /var/log/nextcloud/nextcloud.log. The entries (lines) are in JSON format and can be very long. Readability can be greatly improved by using jq: 

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

Work around "is_file(): open_basedir restriction in effect"

With Nextcloud v28.0.4 a regression was introduced that manifests in error messages containing 

is_file(): open_basedir restriction in effect

in the log file /var/log/nextcloud/nextcloud.log. The file path given after this messages is missing one slash at one position, whereas at another position there is one too many, e.g. 

File (/usr/share/webapps/nextcloudapps//dav/l10n/de.js)

This is a known bug that has already been fixed and backported to v28.0.5. For v28.0.4 you may apply the following work-around:

  • Add a symbolic link /usr/share/webapps/nextcloudapps pointing to /usr/share/webapps/nextcloud/apps
# cd /usr/share/webapps
# ln -sf nextcloud/apps nextcloudapps
  • Add the path of this symbolic link to the open_basedir settings relevant for your Nextcloud installation. These are:
/etc/webapps/nextcloud/php.ini
open_basedir=...:/usr/share/webapps/nextcloudapps:...

and depending on the application server you use either (FPM) 

/etc/php-legacy/php-fpm.d/nextcloud.conf
php_value[open_basedir] = ...:/usr/share/webapps/nextcloudapps:...

or (uWSGI) 

/etc/uwsgi/nextcloud.ini
php-set = open_basedir=...:/usr/share/webapps/nextcloudapps:...

With v28.0.5 you should be able to roll back this work-around again.

Upgrading v27 to v28

Upgrading a version 27 installation to version 28 requires the following steps:

Install and enable extension sodium

With version 28 it is recommended to install and enable PHP extension sodium that provides the argon2 hashing algorithm. Install the corresponding package php-legacy-sodium as a dependency (i.e. with --asdeps) and enable it in two places:

  • /etc/webapps/nextcloud/php.ini used by the occ command and the background jobs and
  • depending on the application server you use either
    • /etc/uwsgi/nextcloud.ini in case of uWSGI or
    • /etc/php-legacy/php-fpm.d/nextcloud.conf in case of FPM.

Just look for the existing sections where other extensions are enabled and add an additional line corresponding to sodium.

Add maintenance_window_start to configuration

It is recommended to add parameter maintenance_window_start to Nextcloud's configuration file /etc/webapps/nextcloud/config/config.php. See section #Background jobs and Nextcloud's documentation for details.

Work around "ResourceLocator can not find a web root"

Note: This issue has been resolved with version v28.0.4.

Up until version 28.0.3 Nextcloud suffers a regression that manifests in the log /var/log/nextcloud/nextcloud.log being flooded with messages like

ResourceLocator can not find a web root

See the corresponding GitHub ticket. Fortunately, the issue has no impact on Nextcloud's functionality, but real problems may become burried in this log noise. The work-around is to change Nextcloud's configuration file: 

/etc/webapps/nextcloud/config/config.php
'apps_paths' => 
  array (
    0 => 
    array (
      'path' => '/usr/share/webapps/nextcloud/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 => 
    array (
      'path' => '/usr/share/webapps/nextcloud/wapps',
      'url' => '/wapps',
      'writable' => true,
    ),
  ),

/usr/share/webapps/nextcloud/wapps is a symlink to /var/lib/nextcloud/apps. It is part of the nextcloud package - so usually is already present. If it does not exist for whatever reason create it with: 

# ln -sf /var/lib/nextcloud/apps /usr/share/webapps/nextcloud/wapps

When the issue has been resolved the path can be changed back to /var/lib/nextcloud/apps.

Migrating to php-legacy

In the past it had happened several times that the php package was updated to the latest PHP version in a timely manner (in line with Arch Linux' rolling release philosophy) but Nextcloud not being compatible with this brand new version - breaking existing installations and causing lots of efforts for maintainers and users of package nextcloud. When package php switched from version 8.1 to version 8.2 this was about to happen once again.

To avoid this frequent hassle a new set of php-legacy packages has been introduced by that time. These will follow the oldest but still actively supported PHP branch. Package nextcloud has been modified to depend on meta package php-interpreter which is provided by php and php-legacy. This way users of package nextcloud have the choice to build their Nextcloud installation either on top of php or on top of php-legacy.

It is highly recommended to go for php-legacy. With this only slightly aged version of PHP it will be very unlikely that a system upgrade renders an existing Nextcloud installation unusable.

Warning: Users choosing the latest and greatest version of PHP (i.e. php) have to be prepared for troubles when package php switches major or even minor versions. These troubles will mainly manifest in package nextcloud suddenly not offering php as dependency (because its version not being supported by Nextcloud at that point in time). This effectively will force users going for php to occasionally migrate to php-legacy temporarily, i.e. some time later they will have to migrate back to php.

Migrating to php-legacy requires some manual actions. Depending on your actual setup a subset of the following tasks must be applied:

Note: The following list of actions assumes that your Nextcloud installation has been set up according to this wiki article. In case your setup deviates from this approach please be extra careful and adapt the steps appropriately.

PHP extensions

Replace php extensions by their corresponding php-legacy counterparts. For example 

$ 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

The former extension php-intl is an exception as it has become an integral part of php and php-legacy. So there is no need to explicitly take care of this package here.

The actual set of PHP extensions is subject to the database, the in-memory object cache, the application server and other factors. Of course, in case another application depends on the most recent PHP version the non-legacy module may still be needed. Same applies for php itself.

Nextcloud specific copy of php.ini

/etc/webapps/nextcloud/php.ini
open_basedir=...:/usr/lib/php-legacy/modules:...
extension_dir = "/usr/lib/php-legacy/modules/"
;extension=imap                                            <= to be deleted

FPM configuration

(This only applies if the application server FPM is used.) 

$ 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

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

/etc/php-legacy/php-fpm.ini
extension_dir = "/usr/lib/php-legacy/modules/"
;extension=imap                                            <= to be deleted

Modify /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              <= to be deleted
; php_value[extension] = imap                              <= to be deleted

Optional, but recommended: Make www.conf a no-op while still being able to track modifications of this file that might come in with future updates of 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

Stop and disable the systemd service php-fpm.service. Create a drop-in file for 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

Enable and start the systemd service php-fpm-legacy.service.

uWSGI configuration

(This only applies if the application server uWSGI is used.) 

/etc/uwsgi/nextcloud.ini
php-set = open_basedir=...:/usr/lib/php-legacy/modules...
# uncomment if php-imap is installed and used               <= to be deleted
# php-set = extension=imap                                  <= to be deleted

Nginx configuration

Modify the file where the forwarding of certain requests to the application server is configured. In case of FPM e.g. 

cloud.mysite.com.conf
fastcgi_pass unix:/run/php-fpm-legacy/nextcloud.sock;

In case of uWSGI no adaptation is required.

Apache HTTP server configuration

In case you use Apache's HTTP server and FPM as application server adapt this line in your configuration 

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

In case of uWSGI no adaptation is required.

Background jobs

Update the drop-in file for Nextcloud's scheduled background job: 

/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 hook

The pacman hook /etc/pacman.d/hooks/10-nextcloud.hook needs to be adapted as well. Change the line starting with Exec to: 

/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

Otherwise during the next upgrade of Nextcloud pacman will complain about /usr/bin/php not being found.

Cleanup

Do not forget to cleanup files and directories that may have become obsolete. Potential candidates are: 

/usr/lib/php
/etc/php

Weird behavior of one or more apps

There are two locations where folders with files of Nextcloud's apps can be found:

  • /usr/share/webapps/nextcloud/apps (aka read-only apps directory). This is where the nextcloud package and the app packages (e.g. nextcloud-app-contacts) put the folders with files comprising Nextcloud apps.
  • /var/lib/nextcloud/apps (aka writeable apps directory). This is where you find folders with files of apps installed via GUI or via the occ app:install command.

When files of an app can be found in both directories (especially in different versions) all kind of strange things can happen. In a concrete case the contacts app could be found in both the read-only apps directory and the writeable apps directory. As a result the page with contacts in the GUI did not display. It remained blank white. The browser's Javascript console showed an error message: 

Uncaught Error: Could not find initial state contactsinteraction of contacts

Check for apps to be found in both locations. To find out whether to delete the app folder in the read-only directory or in the writeable directory determine whether the app is part of a package. Run 

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

All folders reported with 

error: No package owns ....

(and that can also be found in the writeable apps directory) can be safely deleted from /usr/share/webapps/nextcloud/apps. Other double installed apps (i.e. those belonging to a package) should be removed from /var/lib/nextcloud/apps.

InnoDB refuses to write tables with ROW_FORMAT=COMPRESSED

MariaDB versions >= 10.6 and < 10.6.6 were not compatible with Nextcloud as the database enforced read-only for compressed InnoDB tables and Nextcloud has been (and still is) using these kind of tables:

From MariaDB 10.6.0 until MariaDB 10.6.5, tables that are of the COMPRESSED row format are read-only by default. This was intended to be the first step towards removing write support and deprecating the feature.
This plan has been scrapped, and from MariaDB 10.6.6, COMPRESSED tables are no longer read-only by default.

Additionally the issue has already been addressed by Nextcloud. Starting with Nextcloud v24 new installations of Nextcloud do not use row format COMPRESSED anymore. It has to be noted that existing (pre v24) installations are not migrated away from row format COMPRESSED automatically.

Bottom line: Probably you are not affected since Arch Linux has been shipping MariaDB v10.6.6 or later since 2022-02-10.

In the unlikely case that you are affected by this issue there are several possible remedies:

  • Adapt your MariaDB configuration:
/etc/my.cnf.d/server.cnf
[mariadb-10.6]
  innodb_read_only_compressed=OFF
  • Migrate your MariaDB tables from row format COMPRESSED to DYNAMIC as suggested by some comments for the corresponding Nextcloud issue. Mind that as long as you stay with Nextcloud < v24 new tables will again use row format COMPRESSED - so will need to be migrated in the same way.
  • Replace MariaDB by PostgreSQL and migrate the data of your Nextcloud instance with occ db:convert-type. See Nextcloud's documentation for details.

Issues with permissions and setup after upgrade to >= 21.0.0

Note: Before nextcloud 21.0.0, the web application was run using the http user. This is a security concern in regards to cross-application access of this user (it has access to all data of all web applications).

Since version 21.0.0 nextcloud more closely follows the web application package guidelines. This introduces the separate user nextcloud, as which the web application is run.

After an upgrade from nextcloud < 21.0.0 make sure that

  • the data directory is located at /var/lib/nextcloud/data
  • the writable apps directory is located at /var/lib/nextcloud/apps
  • both the data directory and the writable apps directory, alongside all files beneath them are writable and owned by the nextcloud user
  • the web application configuration file resides in /etc/webapps/nextcloud/config/ and that that directory and its contents are writable and owned by the nextcloud user
  • an application server, such as FPM or uWSGI is configured to run the web application as the nextcloud user and not the http user
  • update the cron job/systemd timer to run with the new user
  • Finally allow read access to the nextcloud installation /usr/share/webapps/nextcloud to your web-server user http by doing:
 # chown -R nextcloud:http /usr/share/webapps/nextcloud

Login loop without any clue in access.log, error.log, nor nextcloud.log

As mentioned in a post in the forum, this issue can be fixed by setting correct permissions on the sessions directory. (See Nextcloud's documentation for details.) It is also possible that the sessions directory is missing altogether. The creation of this directory is documented in System and environment.

/var/lib/nextcloud should look like this: 

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/

Environment variables not available

Depending on what application server you use custom environment variables can be provided to Nextcloud's PHP code.

FPM

Add one or more lines in /etc/php-legacy/php-fpm.d/nextcloud.conf as per Nextcloud's documentation, e.g.: 

/etc/php-legacy/php-fpm.d/nextcloud.conf
env[PATH] = /usr/local/bin:/usr/bin:/bin

uWSGI

Add one or more lines in /etc/uwsgi/nextcloud.ini, e.g.: 

/etc/uwsgi/nextcloud.ini
env = PATH=/usr/local/bin:/usr/bin:/bin

Mind there must not be any blanks around the second =.

You are accessing your instance over a secure connection, however your instance is generating insecure URLs

If you get the following message in your administration settings:

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.

Add the following in your configuration file: [7] 

/etc/webapps/nextcloud/config/config.php
'trusted_proxies' => ['192.168.1.0'],
'overwriteprotocol' => 'https',

Replace 192.168.1.0 with your public IP.

Nextcloud reports corrupted index (MariaDB)

If Nextcloud reports corrupted indices (e.g. during occ db: commands or in Administration > Logging) you can repair your database by executing: 

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

If the command fails, it still will point out the table TABLE containing a corrupted index. Repair it by logging into mariadb: 

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

Replace TABLE to match your findings.

Failed to fetch the Collabora capabilities endpoint

In case you get responses with:

Failed to fetch the Collabora capabilities endpoint: Client error: `GET http://localhost/wapps/richdocumentscode/proxy.php?req=/hosting/capabilities` resulted in a `404 Not Found` response

double-check your config.php that entry overwrite.cli.url has been set as described in section Configuration / Nextcloud.

See also

Retrieved from "https://wiki.archlinux.org/index.php?title=Nextcloud&oldid=806805"