File locked by server, unresolvable with regular approaches

Nextcloud version: 11.0.3
Operating system and version: Ubuntu 16.04.3 LTS
Apache or nginx version: Apache/2.4.18
PHP version: 7.0.22-0ubuntu0.16.04.1

The issue you are facing:

A LDAP user has a bunch of files which he can’t modify anymore due to the files being locked by the server. In the past I was able to resolve this issue with “occ files:cleanup/scan”,deleting the user from nextcloud (“occ ldap:check-user/show-remnants”, “user:delete”) or by droping rows in “oc_file_locked” with “locked=1”.

In this case I’m not able to resolve the issues by doing the above:

  1. Rescaning files doesn’t do anything.

  2. Deleting the user and then adding him back to nextcloud doesn’t help either. After deleting the user I made sure, that corresponding database entrys in “oc_ldap_user_mapping” and “oc_preferences” and the files subfolder of the user were deleted, which was the case. After adding the user back to the system and letting him try to resync the local files with the nextcloud client, the same “file lock” error occurs. Rescaning the file system of the user delivers 8 folders, eventhough there aren’t any folders on the actual path in the file system. Also the users preferences are stil prevalent, eventhough the “oc_preferences” entry was deleted.

  3. There are no “oc_file_locked” entry with “locked=1”.

I also ran a filesystem check of the ext4 filesystem via e2fsck.

Is this the first time you’ve seen this error? (Y/N): In this severity, yes.

Steps to replicate it:

  1. User tries to sync, “file locked”
  2. Delete user, make sure the users files and database entrys are deleted.
  3. Add the user back to nextcloud.
  4. Try to Sync, “file locked”, phantom folders are found by occ files:scan, users preferences are still there.

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

<?php
$CONFIG = array (
  'instanceid' => 'value',
  'passwordsalt' => 'value',
  'secret' => 'value',
  'trusted_domains' => 
  array (
    0 => 'domain.example.org',
    1 => 'foo.bar',
  ),
  'theme' => 'theme',
  'datadirectory' => '/var/nc-data/data',
  'overwritewebroot' => '/',
  'overwrite.cli.url' => '/',
  'overwriteprotocol' => 'https',
  'overwritehost' => 'domain.example.org',
  'mail_domain' => 'example.org',
  'mail_smtpmode' => 'smtp',
  'mail_smtphost' => 'localhost',
  'mail_from_address' => 'nextcloud',
  'mail_smtpport' => '25',
  'dbtype' => 'pgsql',
  'version' => '11.0.3.2',
  'dbname' => 'owncloud',
  'dbhost' => 'db.example.org',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'owncloud',
  'dbpassword' => 'password',
  'logtimezone' => 'Europe/Berlin',
  'logdateformat' => 'd.m.Y H:i:s',
  'loglevel' => 0,
  'logfile' => '/var/log/nextcloud/nextcloud.log',
  'log_rotate_size' => 104857600,
  'trashbin_retention_obligation' => 'auto',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'installed' => true,
  'ldapIgnoreNamingRules' => false,
  'skeletondirectory' => '/var/nc-data/skeleton',
  'maintenance' => false,
  'ldapProviderFactory' => '\\OCA\\User_LDAP\\LDAPProviderFactory',
);

The best is to use redis as file-locking cache, especially on muli-user setups:

Normally cleaning the oc_file_locked-table should help, however make sure the user is not logged in (webdav connection, open browser etc.) and locks the file again. After you emptied the table, is the file back in the locking-list?