How many entries should oc_file_locks keep?

Nextcloud version (eg, 10.0.2): 12.0.0
Operating system and version (eg, Ubuntu 16.04): Ubuntu 16.04.2 LTS
Apache or nginx version (eg, Apache 2.4.25): Apache/2.4.18 (Ubuntu)
PHP version (eg, 5.6): 7.0
Is this the first time you’ve seen this error?: No

Can you reliably replicate it? (If so, please outline steps):
SELECT * FROM oc_file_locks

The issue you are facing:

How many (aprox) entries should oc_file_locks maintain (given a number of existing files and users) and what does the ‘lock’ field (numeric) mean?

I have about 760000 files, and locks use to reach and overpass that amount in matter of hours (after cleaning, because we’re having some problems when syncing locked files)

The output of your Nextcloud log in Admin > Logging:
No matter here for now. I don’t know what I’m looking for yet.

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

<?php $CONFIG = array ( 'instanceid' => 'ocd51dc248e3', 'passwordsalt' => '*****************************************', 'trusted_domains' => array ( 0 => 'owncloud.*******.**', 1 => '**********.******.**', ), 'datadirectory' => '/mnt/ocdata', 'dbtype' => 'mysql', 'version' => '', 'dbname' => 'cloud', 'dbhost' => 'localhost', 'dbtableprefix' => 'oc_', 'dbuser' => 'cloud', 'dbpassword' => '***********', 'installed' => true, 'theme' => '', 'mail_smtpmode' => 'smtp', 'mail_smtphost' => '*****.*****.**', 'mail_smtpport' => '465', 'mail_smtpsecure' => 'ssl', 'mail_smtpauth' => 1, 'mail_smtpname' => 'owncloud', 'mail_smtppassword' => '***********', 'maintenance' => false, 'mail_from_address' => '************', 'mail_domain' => '*******.**', 'loglevel' => 2, 'secret' => '*****************************************', 'trashbin_retention_obligation' => '90', 'mail_smtpauthtype' => 'LOGIN', 'preview_libreoffice_path' => '/usr/bin/soffice', 'appstore.experimental.enabled' => true, 'ldapIgnoreNamingRules' => false, 'singleuser' => false, 'overwrite.cli.url' => 'http://*******************.**********.**', 'memcache.local' => '\\OC\\Memcache\\APCu', ); The output of your Apache/nginx/system log in `/var/log/____`: _No matter here, for now._ --- Remember, this information may be requested if it isn't supplied; for fastest response please provide as much as you can :heart: Feel free to use a pastebin service, otherwise log files can be indented with 4 spaces on each line to present them in a friendlier way on the forum.

If you have several thousands of users, this could be normal. You can much better performance, if you use redis as filelocking cache.

Make sure your cronjobs are running regularly, failing cronjobs could explain not properly cleaned tables (on the admin page it shows you when the cron was run for the last time). Use system cron if possible and avoid web-cron or ajax, they are only for hosted environments when you have no other choice.

I changed from AJAX to system cron yesterday, but had some trouble on getting it to start. I think it will be any bad setting from mine, for sure easy to solve.
About redis, I’m reading about it and will tell you if I have any doubt.

Did you set the cron job for the webserver user? Read admin manual in case on how to do that:

Same about Redis:

I would generally advice to read through the admin manual, as it answers many questions and gives good recommendations about security and performance settings.

Thanks MichaIng.
The problem with cron was a stupidity of mine (bad use of php in command line at crontab file), but it’s now fixed and it works.

Still going on reading about Redis. Better to have clear concepts and then start changes.

About tflidd’s previous comment on the number of users and locks: We have about 100 users registered in our nextcloud server, so having as many file_locks as files in the storage folders, sounds kind of enormous, isn’t it?

If you have no experience with setting up cron jobs on servers or don’t have access to do it, you can use a webcron solution like who will call your URL at a specific time.

On a server of this scale, you really should use system cronjobs. The others are only a workaround on systems where you don’t have enough control and the setup is small. If you manage a server for 100 users, cronjobs can be useful for other tasks.

It certainly depends on the usage. But with 7600 locks per user in average seems very high. You can also run the cronjob from terminal as well, this way you also see the potential error messages directly:
sudo -u www-data php -f /var/www/nextcloud/cron.php