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.
open_basedir was intentionally not enabled in any of my php.ini/php-fpm.ini files on this TEST server. However, it turns out that open_basedir is enabled by default in the Archlinux package in nextcloud.conf. It is located well up above and away from where you are instructed to add or uncomment the igbinary and redis extensions so not something you will be drawn to. It was not something I was even looking for as I had made the decision not to enable open_basedir on this test box that is not accessible from the outside world.
After grepping around through all the various config files (made a bit more complex given how Arch isolates Nextcloud per the webapp std), it was the stray grep of nextcloud.conf dumping it without comments that disclosed open_basedir being set as part of the webapp isolation.
BINGO! Once that was discovered, simply adding /run/redis (the runtime directory on Arch) to the open_basedir path allowed full caching and the MySQL transactional locking to work like clockwork.
So if faced with a similar issue on a distro that isn’t given as example in the Nextcloud documentation, double check ALL config files for open_basedir.
