"initMountPoints() called with wrong user casing." in Nextcloud log

Nextcloud version (eg, 20.0.5): 21.0.2
Operating system and version (eg, Ubuntu 20.04): Linux 4.15.0-144-generic x86_64 (no more information - hosted environment)
Apache or nginx version (eg, Apache 2.4.25): no more information - hosted environment
PHP version (eg, 7.4): 7.4.19 (no more information - hosted environment)

The issue you are facing:
Another admin created a user with capital letters, which didn´t fit in our standard. Because it is not possible to change a username i deleted the user and created it with only lower-case letters.
David@Mail.Com was deleted
david@mail.com was created
Since then we get an error in our nextcloud log from the cron.php

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

Steps to replicate it:

  1. create a user with capital letters
  2. delete the user
  3. create the same user without capital letters

The output of your Nextcloud log in Admin > Logging:

[files] Warning: initMountPoints() called with wrong user casing. This could be a bug. Expected: "david@mail.com" got "David@Mail.Com". 
Stack: [

GET /cron.php
at 2021-06-18T11:25:01+00:00

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

$CONFIG = array (
  'instanceid' => 'instanceid',
  'passwordsalt' => 'passwordsalt',
  'secret' => 'secret',
  'trusted_domains' => 
  array (
    0 => 'cloud.domain.com',
    1 => 'www.cloud.domain.com',
  'datadirectory' => '/www/htdocs/nextcloud20/data',
  'dbtype' => 'mysql',
  'version' => '',
  'overwrite.cli.url' => 'https://cloud.domain.com/',
  'dbname' => 'dbname',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'dbtableprefix',
  'mysql.utf8mb4' => true,
  'dbuser' => 'dbuser',
  'dbpassword' => 'dbpassword',
  'installed' => true,
  'tempdirectory' => '/www/htdocs/nextcloud20/tmp/',
  'mail_smtpmode' => 'sendmail',
  'mail_sendmailmode' => 'pipe',
  'mail_from_address' => 'mail',
  'mail_domain' => 'mail.com',
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 2,
  'htaccess.RewriteBase' => '/',
  'simpleSignUpLink.shown' => false,
  'default_language' => 'de',
  'default_locale' => 'de_DE',
  'skeletondirectory' => '',
  'trashbin_retention_obligation' => 'auto, 30',
  'updater.release.channel' => 'stable',
  'app_install_overwrite' => 
  array (
    0 => 'files_3d',

The output of your Apache/nginx/system log in /var/log/____: no access (hosted environment)

Hey everyone!
Does anyone has an idea how i could fix that problem?
I would also be fine with deleting the user again if there is a clean way to do that.
Do i maybe have to run some occ commands, which usually would be done by cron but i was just too fast the last time when i recreated the user?

Thanks a lot!

Hey everyone!
I still have the same problem and no idea how to fix that.
Does anyone has an idea what i can try?

Thanks a lot!

Hey everyone!
We still have the same problem.
Can anyone tell me how to delete a user very clean, so that i can just recreate the user?

Thanks a lot!

It says it is about the mount points and that it could be a potential bug.

Here is the part in the code: server/Filesystem.php at master · nextcloud/server · GitHub

Perhaps there was still the old mount-point or something else around in your system, that creates the problems. I am not sure if everything on the username side is 100% case-sensitive. You can submit a bug report and hope for a quick solution.

If you want to go quick & dirty: Check out the tables in the database a bit, especially oc_storages, and to the correpsonding storages, there can be files in the oc_filecache linked to it (and these entries can be linked in shares). If you find the old and the new entry, you can try to clean out the old entry. Or if there is just one with the capital letters, you can try to change the casing. If it’s not obvious, you can delete the user again, then delete all the traces in the tables and then try to create this user again.

However, manipulating the database isn’t a real feature and things can go wrong, so please backup all your data and database BEFORE. If you submit a bug report and look a bit into the data, the developers can give you better hints in case they don’t come with a direct fix.