Nextcloud randomly logs out in browsers

Nextcloud version (eg, 20.0.5): 27.0.0
Operating system and version (eg, Ubuntu 20.04): Ubuntu Server 22.04.2 LTS
Apache or nginx version (eg, Apache 2.4.25): 2.4.52
PHP version (eg, 7.4): 8.1

The issue you are facing:
Nextcloud logs me out seemingly at random in browsers. There doesn’t appear to be any connection in the timing at all. I’ve observed it happen days apart, and sometimes minutes apart.

Is this the first time you’ve seen this error? (Y/N): Yes

Steps to replicate it:

It occurs seemingly at random, but only in a browser. Desktop clients do not have this issue, though I’ve confirmed it happening in both Firefox and Chrome.

The output of your Nextcloud log in Admin > Logging:

The latest log entries occur more than a week ago. I will provide them if needed, but I don’t see how they could be relevant because this has been happening constantly since.

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'instanceid' => 'censored',
  'passwordsalt' => 'censored',
  'secret' => 'censored',
  'trusted_domains' =>
  array (
    0 => 'cloud.censored',
  ),
  'trusted_proxies' =>
  array (
    0 => '127.0.0.1',
    1 => '192.168.1.3',
  ),
  'bulkupload.enabled' => false,
  'datadirectory' => '/mnt/cloud_data',
  'dbtype' => 'pgsql',
  'version' => '27.0.0.8',
  'overwrite.cli.url' => 'https://cloud.censored',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'nextcloud',
  'dbpassword' => 'censored',
  'installed' => true,
  'memcache.local' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'filelocking.enabled' => 'true',
  'redis' =>
  array (
    'host' => '/var/run/redis/redis.sock',
    'port' => 0,
    'timeout' => 0.0,
  ),
  'enforce_theme' => '',
  'mail_from_address' => 'censored',
  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_domain' => 'censored',
  'mail_smtpsecure' => 'ssl',
  'mail_smtphost' => 'censored',
  'mail_smtpport' => '465',
  'mail_smtpauth' => 1,
  'mail_smtpname' => 'censored',
  'mail_smtppassword' =>'censored',
  'default_locale' => 'en_US',
  'default_phone_region' => 'US',
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 2,
);

The output of your Apache/nginx/system log in /var/log/____:

The apache error log for the cloud virtualhost is empty, and the access log doesn’t seem to contain anything useful. Once again, I can provide it if needed.

This issue only occurs through the web browser. the desktop client doesn’t seem to have any issues. I do have a somewhat non-typical setup because the data drive for Nextcloud isn’t on the same drive as the operating system, though I’ve run this configuration in the past without issue. I do have modsecurity installed on this system, but it is disabled for the Nextcloud virtualhost via SecRuleEngine Off. I’ve also disabled every app except for those that come with Nextcloud, but to no avail. I’ve checked cookie settings in the browser, but seeing how this occurs even when I switch browsers, I found this unlikely. I also don’t have this issue with any other website that I log into.

Any help or suggestions would be greatly appreciated!

1 Like

Bump, anyone have any ideas?

Bumping again in hopes that someone has an idea. I’m still experiencing this with little to go off of.

Anyone at all? I’ve been looking through logs for almost a month now, but I barely have a place to start.

You have a few settings regarding session lifetimes:

Not sure if it is related, you could check if the logout is at the time the old session data is clean (php garbage collector). Not sure if it can clean valid data as well (not enough memory?). Other idea, I don’t know how it works if the ip address changes, which can happen for ipv6 (but normally you are still reachable under the old one and it should probably update the session).

I’ve gone ahead and set both remember_login_cookie_lifetime and session_lifetime explicitly just to see if I can notice a change. You mentioned I could see when old session data is cleaned, but where would I check that?

I don’t think it could have anything to do with an IP change because while my IP address does change once in a blue moon, it’s very infrequent, and when it does happen, I wind up knowing about it really fast for other unrelated reasons.

I’ve also gone ahead and raised the PHP memory limit. It was set to the recommended 512M, but I have RAM to go around, so I figure its worth a try.

Since I have to “prove” the non-existence of something, it might take a while for me to figure out if this is gone, but either way, I’ll report back here. Thank you for your time!

Just posting back to say that the setting changes had no effect. The issue still occurs, sometimes only hours apart from the last login. Still searching for the source of the problem.

1 Like

I have the same issue with random logouts since i upgraded from NC 26.0.4 to NC 27.0.1.
I’m using Brave browser by default, haven’t tried with others yet.

OS: Ubuntu 22.04.2 LTS
Nginx: 1.18.0
PHP: 8.2.8

2 Likes

Bump, still having this issue. Should I open a bug report at this point? It seems no one has any idea why this happens, and I’m not the only one.

1 Like

What you can try:

Go into the developer tools of your browser, in Firefox you have the tab Storage. On the left you can check the cookies. I have a single cookie there with nc_session id and a few more settings. In one of the columns you see an expiry/max-age column.

For you, is that much shorter?
If you delete all website data (including cookies) on closing you webbrowser, it won’t remember the session after restart of the browser. Also make sure there is no plugin cleaning the browser session cache.

In Chrome:

In Firefox:

Those times are consistent with the lifetimes I set a few weeks back, I believe. I’ve observed this issue happening in both browsers. The odd thing here is that the exact timing with which this happens appears random to me. I’ve gone multiple days before I’ve been logged out, and I’ve also had it happen inside of an hour. The time seems completely random, and I can’t pin down any specific event that takes place to trigger it. That’s why I’m so lost here: I have no logs and effectively no trail to follow since I don’t even know where to begin looking.

Now is the question who kills the session. Did you check the php settings:
https://www.php.net/manual/en/session.configuration.php

On debian, there is a cron.log where you can see when the session was cleaned lately:


CRON[416671]: (root) CMD (  [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)

I’m not sure how often it runs in your place, but if the failures often happen after these times, it’s likely that they were cleaned and you need to adjust your php settings.

Just guessing:

Are all time related settings on your server runing corectly?

Is the time on your server corect:

date

Have you configured the timeservers:

timedatectl show-timesync --all

Status of timesyncd:

systemctl status systemd-timesyncd

Timezone correct (daylight saving time etc)
Did you run

sudo dpkg-reconfigure tzdata

… to rule that out?

Hope that helps,
much luck!

Alright, it’s been quite some time since I last said anything, but life got a bit busy for me. Plus, as this issue appears randomly, I needed to make sure it truly was gone.

However, after reviewing the CRON log, I can confirm that what you said appears to be correct. Toying around with the session configuration, I decided to alter the variable that made the most sense, and changed session.gc_maxlifetime to 100 times what the default is, and the problem has not occurred since.

Still, questions remain for me. I’ve been running Nextcloud for many years now though versions going all the way back to 19 if memory serves. I’m curious as to why this problem has come up only now. Further, I’m sure that setting that option so high has consequences, and granted, my installation is a personal fixture, so it doesn’t get much traffic at all. However, I’d still like to know if the change I made is even appropriate, and if not, what should be done instead?

Strike all of that, it still logs out at random. At this point, I’m considering this something that I’ll just have to live with I guess.

I dunno if you’re still having issues here or not but I was facing something similar for a while. I couldn’t figure it out but just decided to live with it but recently it started to seem like it was happening every time I closed Chrome, and it didn’t seem to happen in other browsers.

Staring at logs, I noticed that when I hovered my mouse over my shortcut for my instance, or typed the domain in, I’d immediately start seeing requests (stuff like “Tried to log in but could not verify token” in the logs), and a message about my IP address being throttled for too many requests.

I had Preloading pages enabled in Chrome. I’ve turned that off and have since not had to log back in after closing Chrome. Do you have page preloading enabled in your browsers by chance, if you’re still experiencing this?

Note that I’ve only been testing this for an hour or so, but I got excited because, honestly, as much as I’d just decided to live with it, it has been bugging the absolute hell outta me.

2 Likes

I have this option (which I didn’t know) unset but still suffering this problem a lot.

This is getting really anoying.

What proxy are you using? If it happens to be NPM, disable Asset Caching.

Thanks a lot jtr, but i’m not using proxy. I do use reverse proxy (traefik), should I check?

It only happens to the web instance, desktop app and mobile app seems to stay logged in.