Talk:Nextcloud

Migrating to php-legacy

I've added a new subsection under Troubleshooting Migrating to php-legacy.

I've written this section a bit in a hurry (wanted to get my Nextcloud installation up and running again). Additionally the VMs I've been using while preparing the big overhaul in Feb 2022 have long gone. So I was not able to test the instructions completely for all combinations of web servers and application servers.

Therefore, I would appreciate any review of this section - preferably by applying the steps to an existing setup that is some other combination than Nginx and PHP-FPM. Many thanks in advance. Wolegis (talk) 13:03, 15 January 2023 (UTC)

I'm not sure, so I'll ask here instead of editing the article directly: in section "FPM configuration" the file naming may not be entirely correct. There it says: "Modify /etc/php-legacy/php-fpm.d/nextcloud.conf" followed by "/etc/php-legacy/php-fpm.d/nextcloud.ini". I think it should be called "nextcloud.conf" in both cases. Or am I wrong here?

Also, I have some problems with my Nextcloud (Nginx and PHP-FPM on a RPi4B) after switching to php-legacy as described ("Internal Server Error" without error messages in a any log file). Tonight I'll start again from scratch after restoring a backup - I think it's just a typo in one of my configuration files. UomoInvisibile (talk) 06:52, 27 January 2023 (UTC)

Thanks for the hint. I've corrected the filename. It should have been 'nextcloud.conf' consistently. Wolegis (talk) 07:38, 27 January 2023 (UTC)

We should also add a note to the migrating section about php-legacy using /srv/http/fcgid-bin instead of the usual /srv/http/cgi-bin. The myriad of config files associated with the php-legacy package do not provide access to that directory. It is incumbent on the user to set that access in /etc/httpd/conf/httpd.conf or in their local config in extra/. This provided great frustration in my preparing for a nextcloud install. PHP stopped working after downgrade to php-legacy authz_core:errorDavid C. Rankin, J.D.,P.E. -- Rankin Law Firm, PLLC (talk) 19:59, 20 August 2023 (UTC)

Needed additions were:

   ## fcgid-bin
   
   <Directory "/srv/http/fcgid-bin">
     AllowOverride All
     Require all granted
   </Directory>

Be consistent with the php-legacy-fpm name

I think that given the new php-fpm module for php-legacy was named as php-legacy-fpm, I think all paths should use the word php-legacy-fpm rather than php-fpm-legacy. In my view that would make all paths and settings consistent with the name of the new module. Alternatively, the new module should be renamed as php-fpm-legacy and keep all paths as they are. Either or but be consistent. Thoughts? Musikolo (talk) 17:01, 21 January 2023 (UTC)

Good catch. I have replaced php-fpm-legacy by php-legacy-fpm wherever possible. One exception being the name of the executable /usr/bin/php-fpm-legacy (referenced by some drop-in files). You may get in touch with the maintainer(s) of pgp-legacy-fpm and point out the inconsistency. But I strongly doubt that the executable will be renamed as probably too many people have already adapted to the new (inconsistent) name. Wolegis (talk) 17:10, 21 January 2023 (UTC)

Leads to FS#77232 AndyRTR (talk) 17:14, 22 January 2023 (UTC)

As this is right now described with /run/php-legacy-fpm/nextcloud.socket being used, this leads to a 503-Error when accessing the servers web-page after server-reboot because of the php-fpm-legacy.service (yes, that's the name of the service although enableing php-legacy-fpm according to the wiki) failing to start because the directory /run/php-legacy-fpm/ isn't persistent on reboot (while /run/php-fpm-legacy/ is).

Also, this directory /run/php-legacy-fpm/ and /var/log/php-legacy-fpm/ and /var/lib/nextcloud/sessions/ have to be generated manually in order to Nextcloud being able to start - at least for me. --NextUser (talk) 10:59, 13 February 2023 (UTC)

I've created a new sub-section below Application / FPM covering /run/php-legacy-fpm/ by copying the very same statement from the Troubleshooting section. I regarded this as a temporary hack to work around inconsistencies in php-legacy-fpm. But as it looks, there probably won't be any significant changes to php-legacy-fpm. So maybe I will rollback some changes (and become more inconsistent again) in the near future. The mentioned hack will then not be necessary anymore.

/var/lib/nextcloud/sessions/ has already been covered in the section Configuration / System and Environment.

I'm still contemplating how and where to cover /var/log/php-legacy-fpm/ Wolegis (talk) 11:35, 13 February 2023 (UTC)

OK, thanks! IMHO it's really useful it's not only mentioned in troubleshooting/migration from php-pfm to php-legacy-fpm because this also appears in an initial fpm-installation. --NextUser (talk) 16:12, 13 February 2023 (UTC)

According to FS#77232 some naming inconsistencies in php-legacy-fpm will remain. I have adapted the article accordingly. Wolegis (talk) 11:05, 19 February 2023 (UTC)

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 extension=igbinary.so 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)

I'm pretty sure it is sufficient to set

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

php_value[extension] = igbinary
php_value[extension] = redis

and

/etc/webapps/nextcloud/php.ini

extension=igbinary
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: extension=igbinary.so 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)

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)

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)

Thunderbird configuration

Its seems now nextclouds own documentation is ahead again :)
https://docs.nextcloud.com/server/latest/user 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)

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

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)