From ArchWiki
Latest comment: 16 February by Wolegis in topic nextcloud on apache doesn't require php-fmp

Issues with Redis setup procedure

Apparently, it is not enough to set extension=igbinary extension=redis in both /etc/webapps/nextcloud/php.ini and /etc/php-legacy/php-fpm.d/nextcloud.conf (albeit with php_value[extension]...), since nginx will consistently return 500.

Following steps provided in PHP#Redis mitigate this. Weirdly enough, the provided igbinary.ini template coming with php-legacy-igbinary uses instead of extension=igbinary. However, changing this in both the pool file as well as nextcloud's php.ini does not resolve this.

Sir-Photch (talk) 17:29, 13 March 2023 (UTC)Reply[reply]

I'm pretty sure it is sufficient to set
php_value[extension] = igbinary
php_value[extension] = redis
Please double-check your setup.
It's difficult to guess what might be the root cause of your issue. In the first place: Was your Nextcloud instance setup in line with the wiki article, i.e. avoiding any modifications in /etc/php-legacy/php.ini? If so: Is your FPM started correctly with --php-ini /etc/php-legacy/php-fpm.ini specified in a drop-in file?
(Actually /etc/webapps/nextcloud/php.ini is not relevant for processing HTTP(S) requests. So focus on /etc/php-legacy/php-fpm.d/nextcloud.conf and your general FPM setup.)
As with your second issue: is the legacy format how to specify a PHP extension. Since PHP 7.2 it is recommended to strip the .so (or .dll on Windows). I'm not aware of any significant differences between the two variants, except the latter is more portable.
Wolegis (talk) 20:30, 13 March 2023 (UTC)Reply[reply]
I had the same issue as Sir-Photch and I now used the files in /etc/php-legacy/conf.d for igbinary and redis to activate those extensions. Having them only enabled via the FPM conf file, a phpinfo() revealed that both extensions were not enabled and Nextcloud itself would only return an Internal Server Error when trying to view it in the browser.
Makikatze (talk) 12:44, 1 May 2023 (UTC)Reply[reply]
Just coming back to this; Since I'm migrating my instance, I have followed the guide again (and made sure I've done it precisely) and setting up Redis still fails because of this. Sir-Photch (talk) 17:24, 25 September 2023 (UTC)Reply[reply]
I had the same problem. I could solve it by changing the order of the extensions to:
php_value[extension] = redis
php_value[extension] = igbinary

MhhhxX (talk) 13:36, 2 December 2023 (UTC)Reply[reply]

This also worked for me. Does the file get read from bottom to top or something? Aetherherne (talk) 16:44, 13 February 2024 (UTC)Reply[reply]

MhhhxX solution worked, flipping the igbinary to after redis Thechitowncubs (talk) 01:20, 3 January 2024 (UTC)Reply[reply]

Nextcloud reports corrupted index

The new troubleshooting section Nextcloud reports corrupted index is actually not Nextcloud related. It's about a MariaDB topic. So I recommend to move it to the troubleshooting section of MariaDB. Maybe extend the existing subsection MariaDB#Check_and_repair_all_tables. --Wolegis (talk) 20:01, 29 May 2023 (UTC)Reply[reply]

Thunderbird configuration

Its seems now nextclouds own documentation is ahead again :) manual/en/groupware/sync thunderbird.html

It mentions Thunderbird 102 versus 91 here. should we simply link there for the now?

—This unsigned comment is by Heugerd (talk) 11:04, 12 August 2023. Please sign your posts with ~~~~!

Thanks for the hint. I've adapted (shortened) the Thunderbird section accordingly. Wolegis (talk) 16:22, 12 August 2023 (UTC)Reply[reply]

Running Nextcloud in a subdirectory - well-known/xxx links

Section 11 refers users to the Nextcloud documentation to configure links for well-known DAV and discovery services. The Nextcloud documentation is incorrect or does not exist. The only documentation that actually solves the warnings issue is in German Ihr Webserver ist nicht richtig konfiguriert um “/.well-known/irgendwas aufzulösen. and it is only available if you ask a question on their forum and are lucky enough to be referred to the German document. See New Install 27.0.2 on PHP8.1 Archlinux, APCu fails, .well-known warnings

The correct resolution for the well-known warnings for installs in the /nextcloud directory is to edit /etc/httpd/conf/extra/httpd-ssl.conf and add at the end before the close of the </VirtualHost> tag:

 # Nextcloud well-known links
 <IfModule mod_headers.c>
   Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains; strict-origin; preload"
   Redirect 301 /.well-known/carddav /nextcloud/remote.php/dav
   Redirect 301 /.well-known/caldav /nextcloud/remote.php/dav
   Redirect 301 /.well-known/webfinger /nextcloud/index.php/.well-known/webfinger
   Redirect 301 /.well-known/nodeinfo /nextcloud/index.php/.well-known/nodeinfo

This resolves the warning where including the redirects in the Nextcloud file does not. This also applies to the entire site, so the Arch packager may need to figure a way to apply this ssl config on the webapp basis. No idea how to do that. David C. Rankin, J.D.,P.E. -- Rankin Law Firm, PLLC (talk) 05:11, 8 September 2023 (UTC)Reply[reply]

Description nginx is outdated.

The NGINX description suggests using sites-available and sites-enabled but this is no longer possible by default, the user would then have to edit their nginx.conf and manually add the line; include /etc/nginx/sites-enabled/*;

Not sure what the best way to adjust the wiki here is to make that work, I'm hoping that other apps have solved this and we can borrow such an approach. TomCat (talk) 18:30, 3 December 2023 (UTC)Reply[reply]

The nginx section is not outdated as (to my knowledge) the nginx package never contained any (sample) configuration using sites-available and sites-enabled (contrary to some other non-Arch-based distributions). As far as I see, the sample configuration files in this package are just taken from upstream.
Organizing your various virtual hosts (or servers in Nginx speak) with sites-available and sites-enabled is nevertheless quite common. Especially, the nginx article describes in depth how to accomplish this. (Unfortunately the article about Apache HTTP Server does not contain such information. Maybe someone volunteers to amend the Apache HTTPD server article in this regard.)
The section about web servers as a whole quite intentionally does not try to give comprehensive step-by-step installation descriptions. The possible usage scenarios and setups are too diverse. Instead, this section just gives hints, pointers (and sample configuration fragments as a starting point).
I'm contemplating about rephrasing the sentence
Most likely you will have to copy it into a file with an appropriate name (here as an example below /etc/nginx/sites-available and create the corresponding symbolic link in /etc/nginx/sites-enabled.
Apart from that, this is not a topic for the Nextcloud article.Wolegis (talk) 09:07, 5 December 2023 (UTC)Reply[reply]
The point here is that the page specifically talks about sites-available. It doesn't have to do that, and there is no reason to do that since nginx doesn't actually have those dirs and doesn't use them if you create them.
Comprehensive or not, depending on a setup that nginx on arch doesn't have is not something that I think is the best approach. Either you are comprehensive and specify the user needs to include it with a specific include line, or you are not comprehensive and then there is no point in mentioning the 'sites-*' dirs. TomCat (talk) 12:52, 5 December 2023 (UTC)Reply[reply]
The Nextcloud#nginx section explicitly says "It is up to you how to include this snippet into your nginx' configuration." and provides a link to Nginx#Managing server entries for details how to set up the "common" case with sites-available and sites-enabled. The following code snippets are introduced with "If using the example nginx config from the Nextcloud documentation linked above", making it clear that they need adaptations when nginx is set up differently. — Lahwaacz (talk) 13:41, 9 December 2023 (UTC)Reply[reply]

occ can't run because of curl and zip

Following the steps perfectly doesn't work. The php.ini specifically for nextcloud are required to have two extensions added for occ to actually start the install.

I added those two to the wiki page, but they got reverted. Probably by someone that didn't actually try it :shrug:.

If people run into it too; to make the steps work you need to add these two lines to your /etc/webapps/nextcloud/php.ini


extension=curl TomCat (talk) 20:45, 4 December 2023 (UTC)Reply[reply]

In /etc/php-legacy/php.ini from the php-legacy package, both extension=zip and extension=curl are enabled by default. There is no need to add lines that are already added. — andreymal (talk) 22:29, 4 December 2023 (UTC)Reply[reply]
Just to complement andreymal's statement, the article says:
Make a copy of /etc/php-legacy/php.ini in /etc/webapps/nextcloud. [...] Additionally enable the following extensions:
The original /etc/php-legacy/php.ini as provided by the php-legacy package already has the extensions curl and zip enabled. No need to mention those again in the list of extensions to be enabled for Nextcloud. Wolegis (talk) 09:19, 5 December 2023 (UTC)Reply[reply]
the 3 words to copy were less than clear and easy to read over. I changed the language a little to avoid others falling into the same trap. Now it makes much more clear that you're supposed to copy and extend.
For the record, nextcloud runs fine with just the bare 14 line php.ini (which includes the two extensions I pasted above) since I never copied the original php.ini TomCat (talk) 12:48, 5 December 2023 (UTC)Reply[reply]
@TomCat Thanks for your contribution. This is definitively an improvement. However, I took the liberty to refine your addition as it left the following sentence with a "dangling reference" These places are:
Regarding the extensions actually required: The list of extensions given in the article actually needs some reevaluation. At least intl and iconv are not required anymore. Will work on that soon. Wolegis (talk) 13:23, 5 December 2023 (UTC)Reply[reply]
That makes this topic here on the talk page resolved as far as I am concerned. TomCat (talk) 13:27, 5 December 2023 (UTC)Reply[reply]

nextcloud on apache doesn't require php-fmp

In chapter 1 it is stated that

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.

I guess that's not correct.

Before I installed the Archlinux package, I tried the web installer.
It was installing and working without any complaints, although mpm_prefork_module and php_module were active.
Also, nextcloud documentation documents proxy_fcgi_module as an alternative to php_module.

Can anyone confirm that, and should that statement be corrected?

SoftICE (talk) 23:38, 8 January 2024 (UTC)Reply[reply]

You have to read the whole paragraph containing your quotation. It starts with:
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.
The installation via web installer very likely runs the PHP code within the Apache HTTPD processes, i.e. with user httpd. Something that is not desired on Arch Linux for security reasons.
In the second last sentence you are apparently messing up mod_fcgi and mod_proxy_fcgi. You write about the latter, while the Nextcloud documentation mentions the first. mod_fcgi may be an alternative for mod_php, but both are neither necessary, nor recommended for a Nextcloud setup the Arch Linux way.
To answer your question: You are free to install Nextcloud in any way you like. This includes setups where the PHP code is run in the process context of Apache HTTPD. But since this is discouraged I see no necessity to change anything in the mentioned paragraph. Wolegis (talk) 20:16, 16 February 2024 (UTC)Reply[reply]