Frequent session-related errors

[pravussum]

See at the end of the post for an update - TLDR: this only occurs on PHP 7.4...

I recently upgrade my NC version 18.x to 19.0.4 and then to 20.0.1.
It's a manual installation on a Plesk-driven vServer running Ubuntu 18.04
In the course of the update I had to upgrade PHP as well and due to some PHP modules being not available for the Plesk provided PHP, I'm running Ubuntus
PHP version 7.4.12.
Apache version: 2.4.29-1ubuntu4.14

Since the update I'm constantly logged out, XHR calls result in HTTP 412 or HTTP 500 whith a stacktrace pointing to method calls with user parameter = null

All in all it looks like the session is invalidated or recreated frequently.
The time in between session invalidations is not fix/deterministic, so I don't think its PHPs session cleanup (although I checked that, too: session.gc_maxlifetime is set to 1440 per phpinfo).

Steps to replicate it:

1. open Nextcloud dashboard and navigate to mail app
2. look at the debugger console
3. after some 50-100 successful requests all calls result either in

• HTTP 412 with content message "CSRF check failed"
• HTTP 401 with content message "Current user is not logged in"
• HTTP 500 with the usual internal server error page. The corresponding log entry reads

    TypeError: Argument 7 passed to OCA\Mail\Controller\MessagesController::__construct() must be of the type string, null given

I observe a similar behavior in the News app: after a while (takes a little longer, bit after very few minutes the latest) I get the 412

The Files app shows 401s (with above mentioned error) for a couple of XHR requests and then redirects to the login page.

I moved the PHP session directory to a separate one for this instance (since Plesk manages multiple in parallel) to eliminate the possibility that another PHP session cleanup affects this PHP instance.

For the sake of completeness here's my config.php, although I had to anonymize quite a some entries:

<?php
$CONFIG = array (
  'session_lifetime' => 86400,
  'remember_login_cookie_lifetime' => 1296000,
  'instanceid' => 'XXXXX',
  'passwordsalt' => 'XXXXX',
  'secret' => 'XXXXX',
  'trusted_domains' => 
  array (
    0 => 'XXXXX',
    1 => 'XXXXX',
  ),
  'datadirectory' => 'XXXXX',
  'overwrite.cli.url' => 'XXXXX',
  'dbtype' => 'mysql',
  'version' => '20.0.1.1',
  'dbname' => 'owncloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'owncloud',
  'dbpassword' => 'XXXXX',
  'installed' => true,
  'maintenance' => false,
  'auth.bruteforce.protection.enabled' => false,
  'loglevel' => 2,
  'theme' => '',
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'ssl',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'mail',
  'mail_domain' => 'XXXXX',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpauth' => 1,
  'mail_smtphost' => 'XXXXX',
  'mail_smtpport' => '465',
  'mail_smtpname' => 'XXXXX',
  'mail_smtppassword' => 'XXXXX',
  'app.mail.verify-tls-peer' => false,
  'memcache.local' => '\\OC\\Memcache\\APCu',
);

Any help would be appreciated. I'm able to debug the PHP instance, but since I don't know the whole session handling infrastructure and how the apps play together, it's kind of hard for me to investigate further.

Originally posted here https://help.nextcloud.com/t/constant-logouts-after-nc-php-update/98671

Update
After reading that (although the Warnings in the Settings page state differently) NC 20.0.2 IS compatible with PHP 7.3, I switched to 7.3 and everything works as expected.
I tried two different PHP 7.3 versions, both worked.

• one Plesk version (fast-cgi)
• one OS vendor version (FPM)

Further info:
Database: MySQL

Results from http://example.com/index.php/settings/integrity/failed

No errors have been found.

List of activated apps:

App list

app:list result

  - accessibility: 1.6.0
  - activity: 2.13.3
  - bookmarks: 4.0.5
  - calendar: 2.1.2
  - camerarawpreviews: 0.7.9
  - cloud_federation_api: 1.3.0
  - comments: 1.10.0
  - contacts: 3.4.2
  - contactsinteraction: 1.1.0
  - dashboard: 7.0.0
  - dav: 1.16.1
  - deck: 1.2.1
  - extract: 1.2.5
  - federatedfilesharing: 1.10.1
  - federation: 1.10.1
  - files: 1.15.0
  - files_markdown: 2.3.1
  - files_pdfviewer: 2.0.1
  - files_rightclick: 0.17.0
  - files_sharing: 1.12.0
  - files_trashbin: 1.10.1
  - files_versions: 1.13.0
  - files_videoplayer: 1.9.0
  - firstrunwizard: 2.9.0
  - gpxpod: 4.2.3
  - logreader: 2.5.0
  - lookup_server_connector: 1.8.0
  - mail: 1.7.0
  - maps: 0.1.8
  - news: 15.0.6
  - nextcloud_announcements: 1.9.0
  - notifications: 2.8.0
  - oauth2: 1.8.0
  - password_policy: 1.10.1
  - photos: 1.2.0
  - privacy: 1.4.0
  - provisioning_api: 1.10.0
  - quota_warning: 1.9.1
  - recommendations: 0.8.0
  - serverinfo: 1.10.0
  - settings: 1.2.0
  - sharebymail: 1.10.0
  - spreed: 10.0.3
  - support: 1.3.0
  - systemtags: 1.10.0
  - text: 3.1.0
  - theming: 1.11.0
  - twofactor_backupcodes: 1.9.0
  - unsplash: 1.1.7
  - updatenotification: 1.10.0
  - user_status: 1.0.1
  - viewer: 1.4.0
  - weather_status: 1.0.0
  - workflowengine: 2.2.0
Disabled:
  - admin_audit
  - encryption
  - files_external
  - survey_client
  - user_ldap

Are you using external storage, if yes which one: NO

Are you using encryption: NO

Are you using an external user-backend, if yes which one: NO

Client configuration

Browser: Firefox & Chrome tested

Operating system: Ubuntu 20.10

[EricKerby]

I am seeing this same issue on a shared host (IONOS) running PHP 7.4.12. We are encountering the issue most prominently in the Text app when editing a document.

[EricKerby]

I just switched my IONOS account to PHP 7.3.24 and am still encountering the issue.

[pravussum]

Most interesting. I conducted another experiment and added an additional PHP handler to Plesk with PHP version 7.4 and configured it the same way I did with the (working) PHP 7.3 handler.
Then it also worked using this PHP 7.4 handler.
I thereby saw that the PHP handler added by Plesk (when installing the OS vendor PHP 7.4 via Plesk GUI) was somehow misconfigured.
@EricKerby could you share some details about your PHP installation?

• Are you using CGI/FastCGI/FPM
• how did you install it
• are you using Plesk
• if so, what does the output of /usr/local/psa/bin/php_handler --list look like?

[pravussum]

I did another experiment and added a FastCGI handler for the same PHP 7.4 installation and that worked as well. Then I had a closer look at the "misconfigured" PHP handler automatically added by Plesk via GUI (the one showing the issue). I realized it referenced a non-existing php.ini from a (formerly installed) PHP 7.2 installation.

So if you are using Plesk, check the settings of the PHP handler using the above mentioned output. At least for me the issue is solved (or rather a Plesk issue than a Nextcloud issue).

[EricKerby]

I believe I tracked down the cause of the issue on my instance. As recommended by Nextcloud, I had used a php.ini to enable the opcache. My settings were as follows:

zend_extension=opcache.so;
opcache.enable=1;
opcache.interned_strings_buffer=8;
opcache.max_accelerated_files=10000;
opcache.memory_consumption=128;
opcache.save_comments=1;
opcache.revalidate_freq=1;

It turns out on my particular shared web host (IONOS / 1&1), I must also need to override opcache to use a file cache only. With the above configuration in place, the described problem occurs. With the addition of the following two lines, I have yet to be able to reproduce the problem. If I remove these 2 lines, the problem is easily reproducible.

opcache.file_cache=/path/to/home/folder/htdocs/.opcache;
opcache.file_cache_only=1;

[DSoko2]

I have the same issues as described in this issue with a Nextcloud instance on Ionos webhosting with php 7.4. However, the two lines @EricKerby added to the opcache config I had already in place; for me they do not solve the issue.

For reference, this is my php.ini of the NC 20.0.2 instance:

zend_extension=opcache.so;
opcache.enable=1;
opcache.memory_consumption=128;
opcache.interned_strings_buffer=8;
opcache.max_accelerated_files=10000;
opcache.revalidate_freq=180;
opcache.fast_shutdown=0;
opcache.enable_cli=0;
opcache.revalidate_path=0;
opcache.validate_timestamps=1;
opcache.max_file_size=0;
opcache.file_cache=[path to home]/.opcache;
opcache.file_cache_only=1;

upload_max_filesize=512M
post_max_size=512M
memory_limit=512M
max_input_vars=1000
file_uploads=On
max_execution_time=180

[DSoko2]

I found a solution for the problem in my case. This is not an issue with the Nextcloud implementation, this issue can be closed from my side.

--

For other Ionos users, some background to my investigation: the session issue occured as soon as I had a custom php.ini for the nextcloud installation in place, even if it was just empty. This forum post (sorry, it's in German :/) seemed to point out the problem and solution: https://help.nextcloud.com/t/problems-with-web-interface-on-the-administrative-sites-apps-and-users/45370/10

In short, creating a directory .phpsessions in your webhosting root and adding the following line to the NC php.ini that I posted in the previous comment solved the issue for me:

session.save_path=[path to home]/.phpsessions;

[EricKerby]

Thanks, @DSoko2. I commented out the file_cache lines and added the session.save_path setting you described. I can confirm that also alleviates my issue. Since my last post, I did encounter the described issue a couple times, so I'm hopeful this session.save_path setting will be the complete fix.

Since IONOS and Nextcloud evidently have some partnerships, it seems they might want to collaborate on detecting/resolving this issue for clients.

[pravussum]

OK, I'll close this one, since it's obviously related to PHP session configuration and not a Nextcloud issue.