New Install 27.0.2 on PHP8.1 Archlinux, APCu fails, .well-known warnings

Setup:

New Nextcloud 27.0.2 install on Archlinux: 6.4.12-arch1-1 Apache/2.4.57
(Unix) OpenSSL/3.1.2 mod_fcgid/2.3.9 PHP/8.1.23

This is a single server, home install in effort to migrate from eGroupware. The install is in the /nextcloud directory off the document root.

The issue you are facing:

  1. APCu cache causes internal server error;
  2. .well-known/xxx warnings do not resolve with recommendations from Nextcloud - Service Discovery.

The server works fine (but slow) without the cache and the warnings on Admin-Overview are informational, but the cache is greatly needed as Nextcloud will bring this small server to its knees.

APCu cache issue, the module is installed and the extension is enable

  1. in config.php I added 'memcache.local' => '\OC\Memcache\APCu',
  2. in /etc/php-legacy/php-fpm.d/nextcloud.conf I enabled
php_value[extension] = apcu
php_admin_value[apc.ttl] = 7200
  1. in /etc/webapps/nextcloud/php.ini I enabled:
; APCu cache for nextcloud
;
extension=apcu
apc.ttl=7200
apc.enable_cli = 1

Upon reloading the server with the cache enabled, nextcloud crashes:

The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.

The nextcloud log doesn’t contain anything informative:

{"reqId":"TuFO7ny6RratByEvEg14","level":3,"time":"2023-09-07T03:18:48+00:00","remoteAddr":"XXX.XXX.X.XXX","user":"david","app":"PHP","method":"REPORT","url":"/nextcloud/remote.php/dav/calendars/david/tasks/","message":"Module \"bcmath\" is already loaded at Unknown#0","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0","version":"27.0.2.1","data":{"app":"PHP"}}

But the Apache log is hepful

[proxy_fcgi:error] [pid 152023] [client XXX.XXX.X.XXX:54312] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught OCP\\HintException: [0]: Memcache \\OC\\Memcache\\APCu not available for local cache (Is the matching PHP module installed and enabled?)\n\n  thrown in /usr/share/webapps/nextcloud/lib/private/Memcache/Factory.php on line 90'

Though it doesn’t really say much more than it can’t find the module and doesn’t think it’s working. I’ve followed the manual and the Archlinux wiki - Nextcloud but as soon as the cache is enable, nextcloud goes tits-up. (all other PHP apps continue working fine)

2 .well-known not configured

Per the nextcloud docs, with my install in /nextcloud, I should edit/create the .htaccess file in the document root and include:

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteRule ^\.well-known/carddav /nextcloud/remote.php/dav [R=301,L]
  RewriteRule ^\.well-known/caldav /nextcloud/remote.php/dav [R=301,L]
  RewriteRule ^\.well-known/webfinger /nextcloud/index.php/.well-known/webfinger [R=301,L]
  RewriteRule ^\.well-known/nodeinfo /nextcloud/index.php/.well-known/nodeinfo [R=301,L]
</IfModule>

I do, and nothing changes. When I access the Admin Overview, the same errors are shown (showing full warnings as they relate to both issues, the cache and the .well-known/xxx entries):

  Your web server is not properly set up to resolve "/.well-known/webfinger". Further information can be found in the documentation ↗.
  Your web server is not properly set up to resolve "/.well-known/nodeinfo". Further information can be found in the documentation ↗.
  Your web server is not properly set up to resolve "/.well-known/caldav". Further information can be found in the documentation ↗.
  Your web server is not properly set up to resolve "/.well-known/carddav". Further information can be found in the documentation ↗.
  The database is used for transactional file locking. To enhance performance, please configure memcache, if available. See the documentation ↗ for more information.
  No memory cache has been configured. To enhance performance, please configure a memcache, if available. Further information can be found in the documentation ↗.
  The PHP OPcache module is not properly configured. See the documentation ↗ for more information.
      The OPcache interned strings buffer is nearly full. To assure that repeating strings can be effectively cached, it is recommended to apply opcache.interned_strings_buffer to your PHP configuration with a value higher than 8.

My current config is:

<?php
$CONFIG = array (
  'datadirectory' => '/var/lib/nextcloud/data',
  'logfile' => '/var/log/nextcloud/nextcloud.log',
  'default_locale' => 'en_US',
  'default_phone_region' => 'US',
  'knowledgebaseenabled' => true,
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/usr/share/webapps/nextcloud/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => '/var/lib/nextcloud/apps',
      'url' => '/wapps',
      'writable' => true,
    ),
  ),
  'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => 'my.site.com',
    2 => 'XXX.XXX.X.XXX',
  ),
  'overwrite.cli.url' => 'https://my.site.com/nextcloud',
  'htaccess.RewriteBase' => '/nextcloud',
<credentials snipped>
  'dbtype' => 'mysql',
  'version' => '27.0.2.1',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost:/run/mysqld/mysqld.sock',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud',
<snipped password and mail>
  'maintenance' => false,
  /* 'memcache.local' => '\\OC\\Memcache\\APCu', */
  /* 'memcache.local' => '\OC\Memcache\Redis',
  'memcache.distributed' => '\OC\Memcache\Redis',
  'memcache.locking' => '\OC\Memcache\Redis',
  'redis' => [
     'host'     => '/run/redis/redis.sock',
     'port'     => 0,
     'dbindex'  => 0,
     'password' => '',
     'timeout'  => 1.5,
  ], */
);

The cache config for both APCu and Redis are commented out to restore nextcloud operation.

I’ve pulled my hair out over these two issue and just need a bit of help.

Where am I going wrong?

Security and Setup Alerts NextCloud • Schächner (xn–schchner-2za.de)

I see you have the same problems we once had. But we have instructions for that, which hopefully describe everything in detail. If you still have questions, please get in touch!
The instructions are in German, but you can easily have them translated into English.
Best regards,
schBenedikt

We will follow the link and give the translation a go. Are you sure you’re not just sending me on a wild linguistic “goose-chase”? Will report back if I have problems…

This guide has helped both us and others multiple times:

PS: Since all IP addresses are now public in your config file, everyone can see them.
Maybe you want to remove them?

Yes, I’ve seen the different approaches in several posts, but couldn’t discern which was the correct path to take. The German link is easy enough to understand, and other than the ssl-config, I’ve done most of it. The Strict Transport-Security I resolved without any issue, it just the APCu cache and the well-known links that was giving me trouble.

I’ll work though this in the morning and report back when done. Thank you for your help.

This is an internal test-server – it’s not reachable from the internet. But I’ll remove the IPs just the same.

How to install APCu for Nextcloud?
I created this guide for you - hopefully it will work for you too. It worked for us, but every server is different.

Wow, thank you for taking the time to put that together. Literally, that is exactly what I was doing. In summary, following the instructions in your link, which are the same except for the addition of apc.ttl=7200 in Archwiki - Nextcloud 8.1 APCu. Here is exactly what I have been doing for APCu:

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

...
'memcache.local' => '\OC\Memcache\APCu',

/etc/webapps/nextcloud/php.ini

...
; APCu cache for nextcloud
;
extension=apcu
apc.ttl=7200
apc.enable_cli = 1

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

...
; uncomment if php-apcu is installed and used
php_value[extension] = apcu
php_admin_value[apc.ttl] = 7200
...

But still, as soon as the webserver is restarted, nextcloud crashes:

The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.

And the logs:

# tail -n 2 /var/log/php-fpm-legacy/access/nextcloud.log
2023-09-07T13:53:33-0500 -: "POST /nextcloud/index.php" 500 //usr/share/webapps/nextcloud/index.php 13.493 4096 74.11%
2023-09-07T14:01:57-0500 -: "POST /nextcloud/index.php" 500 //usr/share/webapps/nextcloud/index.php 13.176 4096 75.90%

and

# tail -n2 /var/log/nextcloud/nextcloud.log
{"reqId":"mH1konEWsRgMQtuvwio8","level":3,"time":"2023-09-07T10:03:49+00:00","remoteAddr":"XXX.XXX.X.XXX","user":"david","app":"PHP","method":"PROPFIND","url":"/nextcloud/remote.php/dav/calendars/david/","message":"Module \"bcmath\" is already loaded at Unknown#0","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0","version":"27.0.2.1","data":{"app":"PHP"}}
{"reqId":"lgffQIN6PeE3Fe2OWmQR","level":3,"time":"2023-09-07T10:04:00+00:00","remoteAddr":"XXX.XXX.X.XXX","user":"--","app":"PHP","method":"GET","url":"/nextcloud/js/core/merged-template-prepend.js?v=b8353225-5","message":"Module \"bcmath\" is already loaded at Unknown#0","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0","version":"27.0.2.1","data":{"app":"PHP"}}

(note: there is nothing in the nextcloud.log, those are just old entries complaining about bcmath)

After removal of APCu, everything words fine, just slow… Any other ideas? This is php 8.1.

Unfortunately, I’m almost out of ideas now…
The most you could do is try reinstalling PHP - but that’s a bigger task…
You could try uninstalling the plugin with “sudo apt-get --purge-remove php-bcmath” and then reinstalling it with “sudo apt install php-bcmath”.
What does the error log say with “sudo service apache2 status”?

I feel your pain… I’ll give the bcmath issue a try. I’m working this from both ends. I have an Arch forum question open as well Nextcloud new install. works w/o cache, breaks w/APCu or Redis or both in case this is a weird Arch issue. I’ll report back either way and I’ll report back on the ssl config effect on .well-known warnings.

The .well-known/xxx warnings were fixed by adding to the ssl-config virtualhost. Now the only warnings left are:

    The database is used for transactional file locking. To enhance performance, please configure memcache, if available. See the documentation ↗ for more information.
    No memory cache has been configured. To enhance performance, please configure a memcache, if available. Further information can be found in the documentation ↗.
    The PHP OPcache module is not properly configured. See the documentation ↗ for more information.
        The OPcache interned strings buffer is nearly full. To assure that repeating strings can be effectively cached, it is recommended to apply opcache.interned_strings_buffer to your PHP configuration with a value higher than 8.

Most related to the APCu issue. This is a true bug or some new config for occ needed in version 27.0.2. I enabled apcu in the global php.ini and confirmed the APCu module was loaded with php_info();. and it was.

Even with APCu enabled globally and verified that it was active, nextcloud failed to see that it was available. I have a screenshot of the php_info(); output if interested:

So I don’t know what is broken with APCu in the nextcloud config or how to fix it?

On the bcmath log issue, the Archlinux php package provides bcmath, and there is no separate package to purge. The install there follows the webapp standard isolating nextcloud so that it runs under it own user and not under the normal web users to prevent other applications from potentially reading from nextcloud files. (or any of the other web applications files. I have a forum post open with Archlinux on that issue Nextcloud log - “Module "bcmath" is already loaded at Unknown#0”. The Arch specific details of the php/FPM and nextcloud setup are available there.

NextCloud Memcache with Redis • Schächner (xn–schchner-2za.de)

I linked two links for you up here; Someone had the same problem and then installed Redis - I don’t know if that helped. But we had the same error again and the codes in our other instructions helped us.
[This only applies to the first error message; There will be another message for PHP-OPcache soon]

For the OPcache error you have to add the following code in your PHP.ini:
opcache.interned_strings_buffer=512

Thank you. I’ll try Redis, even though my install is just on one box. I’m interested if I can make it work. I’ll let you know how it goes. I tried Redis alone following the Arch wiki install. I’ll see if there is a fix in your links.

To enhance performance, please configure a memcache

We need to install Redis first in order to then configure Memcache.

I doubled the opcache.interned_strings_buffer=16 in my setup and I still get the warning (default: 8) I’ll play with it, that wasn’t a huge issue and I was waiting until I figured out what size opcache I was setting (figured MB or MiB, but I wanted to make sure)

I had a thought (may be way off), but Archlinux runs php from the binary named php-legacy instead of just php (php 8.2 is current, but Arch packages php-legacy specifically for nextcloud to prevent breakage with upstream updates to php) Could occ be falling over due to the name php-legacy instead of php when looking for the APCu module? (doesn’t seem likely since the rest works, but I’m very new to occ and have not made complete friends with what all it does and how it works - can only digest so much in 3 days…)

php and php-legacy executable naming makes no difference. I symlinked php -> php-legacy and no change. No word back on the Arch list, though there have been over 150 people stop by and view the issue.

For APCU did you modify /etc/php/8.1/apache2/php.ini and /etc/php/8.1/cli/php.ini to have the statement:

apc.enable_cli=1

?

if you use mod-fpm and have /etc/php/8.1/fpm/php.ini you need to add it there too.

NB: The above is for Debian, don’t know what the equivalent on Arch is.

Yes, as posted in #8 of this thread. Even though nextcloud read settings from the nextcloud/php.ini I’ve tried the settings in both the pool and nextcloud specific php.ini and it makes no difference. Thank you for the idea through.

In fact I can have APCu, Redis and Igbinary fully configured as shown in the wiki except for adding any information to nextcloud/config/config.php. As soon as I add either or a combination of both (APCu for local and Redis for locking) the internal server error occurs in nextcloud. The Admin manual and the Archlinux wiki use the following additions in config.php:


  /* for APCu alone */
  'memcache.local' => '\OC\Memcache\APCu', 

Or

  /* for Redis alone */
  'memcache.local' => '\OC\Memcache\Redis',
  'memcache.distributed' => '\OC\Memcache\Redis',
  'memcache.locking' => '\OC\Memcache\Redis',
  'redis' => [
       'host'     => '/run/redis/redis.sock',
       'port'     => 0,
       'dbindex'  => 0,
       'password' => '',
       'timeout'  => 1.5,
  ],

The effect is immediate. Adding any entry above to config.php results in the immediate error shown in the browser window of:

The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.

Removing the entries from config.php and refreshing the browser window and nextcloud immediately comes back to life.

The only log entry generated in php-fpm-legacy/access/nextcloud.log is

023-09-14T03:22:03-0500 -: "GET /nextcloud/index.php" 500 //usr/share/webapps/nextcloud/index.php 12.976 2048 77.07%

No other log entries are generated in either the server log or in the nextcloud log.

Any other idea?

UPDATE

After install of 27.1.1, APCu cache works, but Redis is still dead in the water. Adding any of the suggested config for Redis to config.php still results in the Immediate Internal Server Error on next attempted page display.