Home storage for user not writable


I have one problem with one user.

If run command sudo -u www-data php /var/www/nextcloud/occ files:scan user
i have : Home storage for user … not writable
Just for only user
In the web client he have this message (you do not have permission…)

I look in my folder /var/www/nextcloud/apps/files_sharing/lib/ this file SharedStorage.php and i have the patch.
I delete this user and recreate but i have the same problem.
I delete this folder but i have the same problem.

For other user he don’t have a problem, just for one.

I use a connection with LDAP for my user.

Can you give me a piste for find a solution?


Nextcloud version (eg, 11.0.2):
Operating system and version (eg, debian 8):
Apache or nginx version (eg, Apache 2.4.10-10)
PHP version (eg, 5.6.26):
Is this the first time you’ve seen this error?:
No I have the same error with nexcloud 10.0.1, 10.0.3

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

<?php $CONFIG = array ( 'instanceid' => 'ocphkhzawzsi', 'passwordsalt' => '', 'secret' => '', 'trusted_domains' => array ( 0 => 'ip', 1 => 'name 1', 2 => 'name 2, ), 'datadirectory' => '/nextcloud-data/', 'overwrite.cli.url' => 'url', 'dbtype' => 'mysql', 'version' => '', 'dbname' => 'nextcloud', 'dbhost' => 'sql', 'dbport' => '', 'dbtableprefix' => 'oc_', 'dbuser' => ', 'dbpassword' => '', 'logtimezone' => 'UTC', 'installed' => true, 'ldapIgnoreNamingRules' => false, 'ldapProviderFactory' => '\\OCA\\User_LDAP\\LDAPProviderFactory', 'mail_smtpmode' => 'smtp', 'mail_smtphost' => '', 'mail_smtpport' => '', 'mail_from_address' => ', 'mail_domain' => '', 'memcache.local' => '\\OC\\Memcache\\APCu', 'maintenance' => false, 'loglevel' => 3, 'trashbin_retention_obligation' => 'auto', 'updater.secret' => '', );


After modify the numeric_id entry on oc_storage table.
This ok

best regards


I have the same problem with a similar configuration (LDAP Users) with my nextcloud installation. I read that you found a solution modifying the numeric_id on the oc_storage table… Can you be more detailed please? Have you simply changed the id of users with unused ones or you have aligned them accordind to another table?

Thank you in advance for your reply


had the same problem today.
I had deleted files in the data-directory and had forgotten to deactivate the cron-job. In the end there are probably some references to files or folders that do not match in the database.

I had to remove the ldap-users (change the ldap-search string so that the user was not found anymore)

  • occ ldap:check-user “culprit”
  • occ user:delete “culprit”
  • then execute the cron-script and move the files
  • then reactivate the user

I also tried deleting various rows in the database which seem to stay in the database even after deletion, but they are not connected to the problem.
I have to admit: after the procedure i still have 7 out of 50 users where the problem persists. I am trying again.


I re-did the steps.
What was definitely necessary was a “delete:user”, which needs a ldap:check-user first, which needs the username first to be gone from the search string.
So, executing the cron-script was not necessary.

So once more:

  • using !(uid=culprit) make it disappear for the system
  • occ ldap:check-user “culprit”
  • occ user:delete “culprit”
  • let the culprit appear in the system again
  • then as cloudadmin browse to “users” and search for it, which makes it show again
  • now files:scan “culprit” works.

Think some things are wrong somewhere. This is very annoying.

For me, the problem was that the files directory in the data directory of the user was missing. I previously deleted it assuming Nextcloud would automatically recreate missing directories. So I did it manually.


Had exactly the same issue and solution as @steinbach - easily resolved by adding the files folder back into the users data dir - would be good however if NC picked this up and tried to recreate where it did not exist as part of occ files:scan

This is also how I solved my “Home storage for user not writable”.

In this case the error message is a bit misleading and should be “files subdir not found.”

Thanks for the hint.

I just found that running occ filesystem:scan --all throws that error on my installation, only for one user, no LDAP used here. I checked that this user’s home folder is empty, so I deleted the user from web page, made sure, the folder is gone and re-created with the same name just to find out it throws the same error.
Nextcloud 20.0.0
PHP 7.4.11
PostgreSQL 12.4
Everything on one PC - Ubuntu x64

Hi there,

I noticed this error on my instnce as well. It looks interesting when it comes from LDAP users who haven’t logged in yet.
=> They have an account but no target home dir if not created.

This is a prompt bug then. It should look for HOME dir, if ENOENT then it should be another error prompt.


In my case, occ files:scan --all would return such errors for certain users, which may have never logged in (therefore?) have nothing in their home folder (even no cache/ files/ … etc). I wonder if it is the correct behavior or the correct error messages to show…