Problem with mass session files

I have a problem with my Nextcloud 17 which is running at a webhoster.
There are a lot of session files written in the directory /tmp.

Example:
sess_06vfs7ku5b7f8rl0nq7081me8t
sess_07aghecluqbl68nvb87o3904v0

Hundreds of such files are created within a few minutes. The space consumption on the webspace is then quickly exhausted.

Does anyone know the problem and how to deal with it?

Nextcloud version: 17.0.1
Operating system and version: Linux
nginx: 1.16.1
PHP version: 7.3.11

1 Like

I don’t know how many files you’re speaking about, but it is normal that php session files are created in that directory. Your server usually makes sure that older files are deleted automatically. On my server e.g. I find around 1200 session files with a total size of 1MB!!
I cannot believe that these files are exhausting your web space.

Yesterday almost 5000 files were created in one hour, currently there are 140000 sess_* files with 1 KB each in the folder /tmp.
When I first noticed the problem, I had to ask my webhoster to delete the files, because I couldn’t change to the directory because of the many files.
My webhoster told me that he deleted 50 GB (Gigabyte!) session files.

Wow, that are many files. Maybe this helps you to adjust your php configuration:


According to phpinfo() the following values are set:

session.gc_divisor 1000
session.gc_maxlifetime 1440
session.gc_probability 0

If I understand it correctly, the files should be deleted after 24 minutes. But this is not the case.

I also wonder if it is correct that Nextcloud creates 2000 session files within 15 minutes.

I also wonder if it is correct that Nextcloud creates 2000 session files within 15 minutes.

Probably if some of your users are not using app passwords for sync.

session.gc_divisor 1000
session.gc_probability 0

Please have a look at https://www.php.net/manual/en/session.configuration.php. gc_probability / gc_divisor is the probability that the garbage collector routine is started. 0 / 1000 is still 0. So no garbage collector. Probably your hoster needs to setup some routine to cleanup the temp directory after a while or fix this weird configuration.

I had a similar discussion at GitHub. Yes nextcloud should not create session files for api or webdav requests. But it’s also the providers job to keep /tmp clear.

I think it isn’t of relevance that session files are created by Nextcloud and how many these are. More important is, that the underlying php configuration is correct. Based on the following guide, the usual php defaults are:

session.gc_divisor 100
session.gc_maxlifetime 1440
session.gc_probability 1

https://www.php.net/manual/de/session.configuration.php#ini.session.gc-probability

Also check the comment section on that page in which is stated:

On debian (based) systems, changing session.gc_maxlifetime at runtime has no real effect. Debian disables PHP's own garbage collector by setting session.gc_probability=0. Instead it has a cronjob running every 30 minutes (see /etc/cron.d/php5) that cleans up old sessions. This cronjob basically looks into your php.ini and uses the value of session.gc_maxlifetime there to decide which sessions to clean (see /usr/lib/php5/maxlifetime).

I have now found the source for creating the many session files.
I have set up a cloudsync to the nextcloud on a Synology NAS. A folder on the NAS is synchronized to the Nextcloud via WebDAV. I use an app token as my password.
As soon as the synchronization starts, masses of session files are created immediately.

Hey @MartinK,
Did you found a solution for this problem?
I have a working Nextcloud 20 self-hosted instance. When a Synology NAS connects for WebDAV Sync, the server creates tons of php session files.
Same behaviour.

I need a fix for this and maybe someone can help here?

Kind regards
Skyscraper

I asked my provider if he can set up a garbage collector for the temp directory. The answer was that I should set the path for temp files to the default path of the webhoster, then the files will be deleted automatically. I did that and since then no more problems.